microsoft / wdkmetadata Goto Github PK
View Code? Open in Web Editor NEWTooling to generate metadata for Win32 APIs in the Windows Driver Kit (WDK).
License: Other
Tooling to generate metadata for Win32 APIs in the Windows Driver Kit (WDK).
License: Other
Any update on this? I would love to use [`FltCreateCommunicationPort`](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/fltkernel/nf-fltkernel-fltcreatecommunicationport) in a project.
Originally posted by @sn99 in #1 (comment)
NtCreateFile
's CreateOptions
parameter should be typed as an enum with several existing constants gathered within it. The list of constants are in the docs, but as that's long, and I found a definition in System.Private.CoreLib, here it is for reference:
public enum CreateOptions : uint
{
FILE_DIRECTORY_FILE = 1u,
FILE_WRITE_THROUGH = 2u,
FILE_SEQUENTIAL_ONLY = 4u,
FILE_NO_INTERMEDIATE_BUFFERING = 8u,
FILE_SYNCHRONOUS_IO_ALERT = 0x10u,
FILE_SYNCHRONOUS_IO_NONALERT = 0x20u,
FILE_NON_DIRECTORY_FILE = 0x40u,
FILE_CREATE_TREE_CONNECTION = 0x80u,
FILE_COMPLETE_IF_OPLOCKED = 0x100u,
FILE_NO_EA_KNOWLEDGE = 0x200u,
FILE_RANDOM_ACCESS = 0x800u,
FILE_DELETE_ON_CLOSE = 0x1000u,
FILE_OPEN_BY_FILE_ID = 0x2000u,
FILE_OPEN_FOR_BACKUP_INTENT = 0x4000u,
FILE_NO_COMPRESSION = 0x8000u,
FILE_OPEN_REQUIRING_OPLOCK = 0x10000u,
FILE_DISALLOW_EXCLUSIVE = 0x20000u,
FILE_SESSION_AWARE = 0x40000u,
FILE_RESERVE_OPFILTER = 0x100000u,
FILE_OPEN_REPARSE_POINT = 0x200000u,
FILE_OPEN_NO_RECALL = 0x400000u
}
in ntifs.h a structure called REPARSE_DATA_BUFFER
exists. I would expect windows
or windows_sys
to provide a Rust definition for REPARSE_DATA_BUFFER
.
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntddk/
It has some core functions used in the WDM model.
I can't find Windows Filtering Platform apis in this project, such as FwpmBfeStateSubscribeChanges0, FWPM_LAYER_IPSEC_V4, FWPM_LAYER_IKEEXT_V4 and so on ; The official website is https://docs.microsoft.com/en-us/windows/win32/fwp/about-windows-filtering-platform
https://gist.github.com/kennykerr/3d332f03a4b64a6a1f21e81743e99f5f contains a list of GUID constants but should scan for all constants.
There are some CONTEXT_* implementation in ntddk.h.
#define CONTEXT_i386 0x00010000L // this assumes that i386 and
#define CONTEXT_i486 0x00010000L // i486 have identical context records
#define CONTEXT_CONTROL (CONTEXT_i386 | 0x00000001L) // SS:SP, CS:IP, FLAGS, BP
#define CONTEXT_INTEGER (CONTEXT_i386 | 0x00000002L) // AX, BX, CX, DX, SI, DI
#define CONTEXT_SEGMENTS (CONTEXT_i386 | 0x00000004L) // DS, ES, FS, GS
#define CONTEXT_FLOATING_POINT (CONTEXT_i386 | 0x00000008L) // 387 state
#define CONTEXT_DEBUG_REGISTERS (CONTEXT_i386 | 0x00000010L) // DB 0-3,6,7
#define CONTEXT_EXTENDED_REGISTERS (CONTEXT_i386 | 0x00000020L) // cpu specific extensions
#define CONTEXT_FULL (CONTEXT_CONTROL | CONTEXT_INTEGER |\
CONTEXT_SEGMENTS)
#define CONTEXT_ALL (CONTEXT_CONTROL | CONTEXT_INTEGER | CONTEXT_SEGMENTS | \
CONTEXT_FLOATING_POINT | CONTEXT_DEBUG_REGISTERS | \
CONTEXT_EXTENDED_REGISTERS)
#define CONTEXT_XSTATE (CONTEXT_i386 | 0x00000040L)
#define CONTEXT_EXCEPTION_ACTIVE 0x08000000L
#define CONTEXT_SERVICE_ACTIVE 0x10000000L
#define CONTEXT_EXCEPTION_REQUEST 0x40000000L
#define CONTEXT_EXCEPTION_REPORTING 0x80000000L
This will be great if there will be rust const implementation for convenience.
No response
No response
No response
KeBugCheckEx doesn't use the already available BUGCHECK_ERROR enumeration.
The function is documented here:
https://learn.microsoft.com/en-us/windows/win32/devnotes/nt-cancel-io-file-ex
It seems like this should be included as it is clearly for desktop use and the Win32 metadata includes various other functions exported from ntdll.dll
. I'm just not sure where to find the header.
Originally posted by @Thomasdezeeuw in tokio-rs/mio#1632 (comment)
Some types include invalid field types that I can't parse. They're considered nested types but the names are invalid since "@void*" is not a valid/existing nested type name.
.field public valuetype [Windows.Wdk.winmd]Windows.Wdk.System.SystemServices.IO_DRIVER_CREATE_CONTEXT/@void* pSystemMem
See microsoft/win32metadata#1400 for the SDK changes.
Currently trying to follow the ndisprot_kmdf example in my ndisprot-rs project, and ndis.h
is particularly annoying to generate bindings for due to depending on msvc-specific behaviour (see the code for the workaround I do), so it'd be nice for wdkmetadata to support it instead. π
I technically generate bindings for NDIS 6.82, but am technically registering as an NDIS 6.0 protocol driver so generating metadata for the latest NDIS version would be fine with me.
Thanks!
I would expect windows
or windows_sys
to provide a Rust definition for this type
Error : PInvoke007 - The API "LsaFreeReturnBuffer" is ambiguous. Please specify one of: or "Windows.Win32.Security.Authentication.Identity.LsaFreeReturnBuffer" or "Windows.Wdk.Storage.FileSystem.LsaFreeReturnBuffer".
New to all of this in c#. Was playing around with this library. I see 2 g.cs files, "Windows.Wdk.PInvoke.SECUR32.dll.g.cs" and "Windows.Win32.PInvoke.SECUR32.dll.g.cs" with the LsaFreeReturnBuffer function.
NativeMethods.txt
content:
LsaFreeReturnBuffer
Any of your own code that should be shared?
Windows.Win32.PInvoke.LsaFreeReturnBuffer(temp);
LangVersion
(if explicitly set by project): [e.g. 9
]Having the struct declared twice may be problematic to consumers and projections alike.
CsWin32 in particular happens to have a test for generating this struct and ran into the issue when two structs were generated.
But the two structs are not equivalent today. The declaration in the SDK has an extra PartitionId
field in the middle of the list. So either there's a bug in one of them, or they are in fact two distinct structs.
If this is truly by design, I'll try to fix up CsWin32 to not fail.
FILE_DISPOSITION_DO_NOT_DELETE | 0x00000000
FILE_DISPOSITION_DELETE | 0x00000001
FILE_DISPOSITION_POSIX_SEMANTICS | 0x00000002
FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK | 0x00000004
FILE_DISPOSITION_ON_CLOSE | 0x00000008
FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE | 0x00000010
FileDispositionInfoEx is defined, just not the constants for it.
I use the D3DKMT* APIs a lot to test WDDM drivers. I currently use bindgen for these APIs since they're neither in winapi-rs, windows, or windows-sys, but I'd love to see them officially supported here π.
Documentation:
I was looking for a way to use these flags when using FILE_RENAME_INFO's Flags parameter but they aren't specified today.
I am currently writing up a tool for my own software suite which uses process hollowing on Windows.
For that I need to do some WinAPI calls:
I have searched to the best of my abilities, but I was not able to find ZwUnmapViewOfSection in the windows crate, not even with a slight typo or such.
There is no drawback - it's just a missing function which would be added to get closer to the statement "lets you call any Windows API past, present, and future"
There isn't really any alternative other than not using Rust - I found another crate named "ntapi" which apparently provides this function, but lacks in all other points.
The impact if you don't do it: I would be very sad :'(
Starting on page 43 is pseudo code showcasing the process:
https://www.blackhat.com/presentations/bh-usa-07/Harbour/Presentation/bh-usa-07-harbour.pdf
Documentation on the Microsoft website:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-zwunmapviewofsection
The NtCreateFile
method parameters could use some enum love:
DesiredAccess
parameter is currently declared as uint, but it ought to be as this FILE_ACCESS_FLAGS
enum.FileAttributes
parameter should be declared as a FILE_ATTRIBUTES enum. Previously suggested to be FILE_FLAGS_AND_ATTRIBUTES
but @KalleOlaviNiemitalo made a good comment in microsoft/win32metadata#1440 (comment) to consider.CreateOptions
(#1441)NtCreateFile
from the SDK metadata as part of this changeSee also discussion in microsoft/win32metadata#1440.
If NtCreateFile
is in the WDK, it's already in the win32metadata, so... do we remove it, or fix the enums?
See microsoft/win32metadata#1528 for equivalent SDK metadata changes.
It would be fantastic to be able to use this crate for kernel mode development (e.g., drivers), but it seems so far the metadata is limited to user-mode bindings. Is Kernel mode development in scope for this metadata?
It would allow access to the KS API which gives access to some low level device control which can be quite useful.
More code to maintain, not sure how much is "automatic" once it's been implemented but I leave that up to a maintainer to evaluate:)
Some functions can be worked around by accessing alternatives,
say DeviceIoControl
can be used instead of KsSynchronousDeviceControl
etc.
But not sure if all functionality can have alternatives though.
Thanks for your time:)
The SDK package contains a build folder that allows CsWin32 to consume the winmd via the nupkg directly. But the WDK package is missing that.
Here's what the SDK package has:
C:\.TOOLS\.NUGET\PACKAGES\MICROSOFT.WINDOWS.SDK.WIN32METADATA\52.0.65-PREVIEW\BUILD
β Microsoft.Windows.SDK.Win32Metadata.props
β
ββββnet20
β Microsoft.Windows.SDK.Win32Metadata.props
β
ββββnetstandard1.0
Microsoft.Windows.SDK.Win32Metadata.props
Can the WDK package be enhanced to include that?
The below were temporarily excluded with d4d6095#diff-a02962413f2cd0360613fa6a55753e08d3c32eebf64ecb27951a9a91f7aa4214 since the build couldn't resolve the types with multiple definitions per architecture.
_GENERAL_LOOKASIDE
_GENERAL_LOOKASIDE_POOL
_LOOKASIDE_LIST_EX
_NPAGED_LOOKASIDE_LIST
_PAGED_LOOKASIDE_LIST
ALLOCATE_FUNCTION_EX
ExDeleteLookasideListEx
ExDeleteNPagedLookasideList
ExDeletePagedLookasideList
ExFlushLookasideListEx
ExInitializeLookasideListEx
ExInitializeNPagedLookasideList
ExInitializePagedLookasideList
FirstEntrySList
FREE_FUNCTION_EX
InterlockedPushListSList
_NET_BUFFER
_NET_BUFFER_HEADER
_NET_BUFFER_LIST
_NET_BUFFER_LIST_HEADER
Example error message:
error CS0433: The type 'SLIST_HEADER' exists in both 'Windows.Win32.winmd, Version=47.0.26.58549, Culture=neutral, PublicKeyToken=null' and 'Windows.Win32.winmd, Version=47.0.26.58549, Culture=neutral, PublicKeyToken=null' [C:\wdkmetadata\generation\WDK\Windows.Wdk.proj]
The Offline Registry Library is a super helpful user-mode library used to manipulate registry hives. It ships with Windows 10 in-box. Curiously, the header/library only ships with the Windows Driver Kit (WDK) making it incredibly difficult to consume normally.
Tested Not Generating:
NtDuplicateObject
RtlZeroMemory
LdrGetProcedureAddress
LdrLoadDll
NtMapViewOfSection
NtUnmapViewOfSection
NtProtectVirtualMemory
RtlCreateUserThread
NtCreateThreadEx
NtQueueApcThread
NtOpenThread
NtSuspendProcess
NtResumeProcess
These Should Be Generating,
Ive Generated Other Imports With 100% Successrate,
But The Above List Doesnt Generate Anything!
NativeMethods.txt
content://Working
NtOpenProcess
NtOpenFile
RtlGetVersion
NtCreateSection
NtQueryObject
NtQueryVirtualMemory
NtQuerySystemInformation
NtQueryInformationProcess
NtWaitForSingleObject
RtlInitUnicodeString
RtlUnicodeStringToAnsiString
//Not Working
NtDuplicateObject
RtlZeroMemory
LdrGetProcedureAddress
LdrLoadDll
NtMapViewOfSection
NtUnmapViewOfSection
NtProtectVirtualMemory
RtlCreateUserThread
NtCreateThreadEx
NtQueueApcThread
NtOpenThread
NtSuspendProcess
NtResumeProcess
defined in ntifs.h
#define SYMLINK_FLAG_RELATIVE 1
In Rust I would expect
pub const SYMLINK_FLAG_RELATIVE: u32 = 1
https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntstrsafe/nf-ntstrsafe-rtlunicodestringinitex this API is missing. I think it's pretty easy to add but I'm not sure.
Further testing revealed some invalid handle types that make certain APIs inexpressible. I'm not too familiar with the WDK but it seems that all or some of these underscore-prefixed structs should be handles:
For example: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/nf-wdm-ioinitializeworkitem
Here the parameter is named PIO_WORKITEM
and this typedef should be a pointer to an opaque structure defined by the driver. I would expect it to be defined something like this:
[NativeTypedef]
public struct PIO_WORKITEM
{
public IntPtr Value;
}
And then the empty _IO_WORKITEM
struct should be removed. I assume many of the other underscore-prefixed structs fall into the same category, but again I'm not that familiar with the WDK.
Apparently `NdisRegisterProtocolDriver` or `PNDIS_BIND_PARAMETERS` (which are both gated behind `NDIS_SUPPORT_NDIS6`) aren't showing up in the metadata, which seems to be caused by the defines made in `ndis/version.h` not being visible inside of `ndis.h`.
There are a bunch of "ndis" headers other than just ndis.h so you'll have to tell me if I got the full closure of what's needed.
It seems like the only header that's missing is netpnp.h
, though once NET_PNP_EVENT_NOTIFICATION
(gated behind NDIS_SUPPORT_NDIS6
) is scraped it'd be needed anyways.
Originally posted by @DropDemBits in #50 (comment)
https://github.com/microsoft/wdkmetadata/blob/main/generation/WDK/IdlHeaders/km/fltKernel.h#L239
Looks like IRP_MJ_OPERATION_END metadata is not being automatically generated in the windows crate.
This IRP is needed to make a minifilter driver, the docs say that the last element of FLT_REGISTRATION must be {IRP_MJ_OPERATION_END}.
@riverar instructed me to file a bug here.
Thank you for helping!
cc: @mikebattista
A bit of background for my request, (specifically, I'm using iddcx 1.9
)
So, I went ahead and followed the official idd sample driver and manually created bindings to the entire WDK and Idd for my driver project. And I got a working umdf driver now,
To that end, the specific functions I used since I couldn't find them in the generated bindings (and please correct me if I am wrong anywhere), are:
Idd:
IddCxDeviceInitConfig
, IddCxDeviceInitialize
, IddCxAdapterInitAsync
, IddCxMonitorCreate
, IddCxMonitorArrival
, IddCxSwapChainSetDevice
, IddCxSwapChainReleaseAndAcquireBuffer
, IddCxSwapChainFinishedProcessingFrame
Wdf:
WdfDriverCreate
, WdfDeviceCreate
, WdfDeviceInitSetPnpPowerEventCallbacks
, WdfObjectGetTypedContextWorker
(this is internal, but I needed to recreate the WDF_DECLARE_CONTEXT_TYPE!()
macro), WdfObjectDelete
Also had to manually export FxDriverEntryUm
entry point to get the ball rolling.
Thanks for all your guys effort! I would absolutely love to throw away all my bindings π
Would like to be present important values, for example, in the form of constants (or similar):
ntstrsafe.h
NTSTRSAFE_UNICODE_STRING_MAX_CCH
NTSTRSAFE_MAX_LENGTH
NTSTRSAFE_MAX_CCH
and other
> If you have specific WDK headers or scenarios you'd like to see supported, please provide the details here to help us prioritize.
On my end I'd love to have access to vhf.h
for creating software HID devices.
Originally posted by @Progdrasil in #1 (comment)
I'd like https://github.com/microsoft/wdkmetadata/releases/tag/v0.2.22-experimental to be included in the next sys
release.
It would be nice to have access to `ntifs.h` headers like [NtReadFile](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/nf-ntifs-ntreadfile) given that shims for NtCreateFile et. al already exist, but are basically impossible to work with within the `windows` crate.
Originally posted by @chyyran in #1 (comment)
This header was excluded from the SDK metadata since it covers kernel mode display driver scenarios.
As earlier was stated here: microsoft/windows-rs#2612, there are no arguments in callack definitions like PDRIVER_UNLOAD in the Foundation module of WDK.
pub type PDRIVER_UNLOAD = ::core::option::Option<unsafe extern "system" fn() -> ()>;
But in C++ WDK we have this:
//
// Define driver unload routine type.
//
_Function_class_(DRIVER_UNLOAD)
_IRQL_requires_(PASSIVE_LEVEL)
_IRQL_requires_same_
typedef
VOID
DRIVER_UNLOAD (
_In_ struct _DRIVER_OBJECT *DriverObject
);
So, the Rust callback should be:
pub type PDRIVER_UNLOAD = ::core::option::Option<unsafe extern "system" fn(driver_object: *mut DRIVER_OBJECT) -> ()>;
The latest build appears to include invalid function imports. Functions like:
[DllImport("CLFS", ExactSpelling = true, PreserveSig = false)]
public static extern void ClfsFinalize();
And also:
[DllImport("ksecdd", ExactSpelling = true, PreserveSig = false)]
public unsafe static extern SspiAsyncContext* SspiCreateAsyncContext();
To begin with, they lack a file extension so it's unclear how to link them.
Note that some of these may not even be DLLs to begin with (they may be .sys files) but I'm not sure how you determine that when generating the metadata.
Also, I though all library names should be lowercase but that doesn't appear to be enforced consistently across the Win32 and WDK metadata.
Somehow, I don't think the WDK depends on DirectDraw.
I did not find it
can give an example
https://docs.microsoft.com/en-us/windows/win32/devnotes/rtlgetversion
Also missing assocaited structs:
GetVersionExW/GetVersionExA exist in Win32Metadata
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversionexw
Winforms does not use them because:
// We use RtlGetVersion as it isn't subject to version lie. GetVersion
// won't tell you the real version unless the launching exe is manifested
// with the latest OS version.
Winforms Tracking:
dotnet/winforms#7468
The following APIs appear in the WDK and SDK metadata files:
RtlConvertSidToUnicodeString
RtlCrc64
Hello,
While utilizing CsWin32 to generate P/Invoke signatures, I've discovered that several essential WDF device functions are absent from the available metadata:
WdfDeviceSetPnpCapabilities
WdfDeviceSetPowerCapabilities
WdfDeviceAssignMofResourceName
WdfDeviceSetFailed
WdfDeviceSetDeviceState
The lack of these functions is constraining the capabilities of the generated projects, impacting the development of varied and dependable drivers.
Could you please review the metadata and consider incorporating these missing functions, along with any other absent ones, to address this limitation?
Hello,
I know you are not porting low level NTAPI to Rust in this project, but IMO this one is a bit special. The NtLoadDriver
call is easy to call from C/C++, but is really hard not to mess in Rust due to the pointer to UNICODE_STRING as parameter.
Source: https://docs.rs/ntapi/latest/ntapi/ntioapi/fn.NtLoadDriver.html
Could you consider supporting this very specific NTAPI function in windows-rs ?
All the best !
Main drawback:
No response
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.