**********************************************************************
** Visual Studio 2022 Developer Command Prompt v17.7.4
** Copyright (c) 2022 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'

C:\Program Files\Microsoft Visual Studio\2022\Enterprise>cd /d D:\code\rust\code\windows\windows-drivers-rs

D:\code\rust\code\windows\windows-drivers-rs>cargo build
   Compiling wdk-sys v0.1.0 (D:\code\rust\code\windows\windows-drivers-rs\crates\wdk-sys)
error: failed to run custom build command for `wdk-sys v0.1.0 (D:\code\rust\code\windows\windows-drivers-rs\crates\wdk-sys)`

Caused by:
  process didn't exit successfully: `D:\code\rust\code\windows\windows-drivers-rs\target\debug\build\wdk-sys-bd0a85a523038361\build-script-build` (exit code: 101)
  --- stderr
  thread 'main' panicked at 'WDKContentRoot should be able to be detected. Ensure that the WDK is installed, or that the environment setup scripts in the eWDK have been run.', crates\wdk-build\src\lib.rs:111:64
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

D:\code\rust\code\windows\windows-drivers-rs>

Hi! Thanks for your awesome work, but I have a question: windows-rs has bindings for WDK based on wdkmetadata, your crate uses bindgen. So... which crate should I use for a long-term project? Which crate is "official" WDK port that Microsoft recommends to use for drivers? And which approach is better (wdkmetadata vs bindgen) in terms of accuracy and completeness?

This commit is a simple change to make the build script work if the target directory is on another drive than the project (for example, a RAMdisk or an NVMe).

https://github.com/microsoft/windows-drivers-rs/blob/79d09bbc2f42a8cc0f2f1b47f2bb3839e232e3b0/crates/wdk-alloc/src/lib.rs#L25-L33

Is there a reason this uses lazy_static instead of just a const and a byte string literal (of type &[u8;4])? u32::from_ne_bytes is const stable since 1.44.

C.f. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2be24215859c818308542b6893f36ca2

"Panic" in the Windows Kernel (or "bugchecking" the system KeBugCheckEx) is a last resort and should be reserved only for cases where the kernel is in a corrupted and unrecoverable state. It is usually never acceptable to bugcheck the system. I find it unlikely that any Rust crate would ever need to bugcheck the kernel.

Today this library notes a "TODO" on this topic: https://github.com/microsoft/windows-drivers-rs/blob/cd1fd23f000c64ea244b5cbfc33d64acb1104b8b/crates/wdk-panic/src/lib.rs#L29-L33

Ultimately the kernel should handle errors cleanly and, by all means necessary, prevent itself from getting into a corrupted or unrecoverable state. I worry that the introduction of a panic handler and the interactions between other crates written for the Windows Kernel could degrade the overall reliability of the kernel.

I'm not certain the best way to approach this problem. My initial reaction is disallow panic handlers when developing against the Windows Kernel and reserve "panics" (bugchecks) for the rare and extreme cases. To achieve this the crates used in the kernel would need to always communicate errors rather than giving up with a panic. Thankfully, Rust has robust and capable error handling patterns with things like match and Result. I'd like to raise this as an open topic to the community to discuss strategies for panic handling for the Windows Kernel.

Development in the Windows Kernel requires allocations from different pools and the capability to tag allocations is an invaluable tool for debugging/triage.

Today this repository looks to recommend a global allocator and one that allocates exclusively from non-paged pool with a hard-coded pool tag.

https://github.com/microsoft/windows-drivers-rs/blob/cd1fd23f000c64ea244b5cbfc33d64acb1104b8b/crates/wdk-alloc/src/lib.rs#L35-L45

Rust crates for the Windows Kernel probably shouldn't provide a global kernel allocator. Else everyone using these crates may subtly end up allocating memory using identical tags. This will make debugging and triage a nightmare in the long term. Additionally I'll note, the non-paged pools are far more limited resource that the paged pools. I recognize that the safer option when implementing a global allocator is to force it into non-paged memory, since not doing so has the potential to introduce other issues. However resource exhaustion is far more likely when forcing all allocations into non-paged pools.

For Rust to be a first-class citizen in the Windows Kernel. The language must support generic fail-able allocators. And the crates for the Windows Kernel should expose and support appropriate allocators that are capable of specifying pool types and tags.