# windows-drivers-rs: Windows Driver Development in Rust

> windows-drivers-rs is a Rust crate platform for WDM, KMDF, UMDF, and Win32 Service projects built with the WDK. Its safe bindings and build integration are useful for experimentation, but the README explicitly says the project is not ready for production use.

**microsoft/windows-drivers-rs** — Platform that enables Windows driver development in Rust

- Repository: https://github.com/microsoft/windows-drivers-rs
- Stars: 1,934 · Forks: 136
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-windows-drivers-rs

## Where windows-drivers-rs Fits in Windows Driver Development

windows-drivers-rs addresses the problem of writing Windows drivers with Rust while continuing to use the interfaces and build model supplied by the Windows Driver Kit. The repository describes support for WDM, KMDF, UMDF, and Win32 Services. Its intended users are Rust developers who need access to WDK APIs and driver entry points without building the entire driver package from raw FFI declarations.

The project is a collection of crates rather than a complete driver template. It supplies generated bindings, safer wrappers, build configuration, panic support, allocator support, and macros. The repository also contains minimal examples for WDM, KMDF, and UMDF drivers. Developers still need to define driver behavior and packaging, and the README directs readers to the separate Windows-rust-driver-samples repository for complete usage examples.

This boundary matters. windows-drivers-rs is infrastructure for a Rust Cargo package that becomes a Windows driver, not a generic Rust runtime for writing Windows applications. The repository explicitly states that the project remains in an early development stage and is not recommended for production use.

## The Crate Stack from Cargo Metadata to WDK APIs

The documented dependency flow begins with `wdk-build`, which configures a Cargo build script for binding generation and downstream linking with the WDK. `wdk-sys` contains direct FFI bindings to WDK APIs. Some bindings are generated with `bindgen`, while manual macro reimplementations cover cases where `bindgen` cannot generate the required binding.

Above that layer, `wdk` provides safe, idiomatic Rust bindings. This separation lets a driver choose between the broad low-level `wdk-sys` surface and higher-level interfaces. `wdk-macros` is also part of the repository, although the README says it is re-exported through `wdk-sys` and that downstream crates should normally depend on `wdk-sys` rather than adding `wdk-macros` directly.

Several mode-specific crates complete the package. `wdk-panic` provides panic handler implementations for programs built with the WDK. `wdk-alloc` provides allocation support, and the README specifically associates it with Rust `alloc` modules in kernel-mode binaries. This architecture means that a kernel driver needs more than its core dependency. Its Cargo metadata, build script, binary type, panic strategy, allocator, and exported `DriverEntry` function all participate in producing the final driver.

## Published Crates and the KMDF v1.33 Boundary

Published support is narrower than the repository's intended coverage. The README says the crates on crates.io currently support KMDF v1.33 only. It also states that bindings for other configurations can be generated by cloning the repository and changing the configuration in the `build.rs` file of `wdk-sys`.

The core limitation is Cargo workspace behavior. The repository root manifest says that only one WDK configuration is supported per build graph, so the workspace-level examples and tests are explicitly excluded from the root Cargo workspace. That design avoids combining examples and tests built for different WDK configurations in one graph. It also means a developer cannot treat every directory under `examples` or `tests` as an ordinary member of the root workspace.

The README describes broader support for all WDF versions included in WDK 22H2 and newer, but it also distinguishes intention from tested configurations. For `wdk-build`, the documented testing covers NI eWDK, KMDF 1.33, UMDF 2.33, and WDM drivers, with a warning that older DDKs may require missing linker options. These statements do not amount to a blanket compatibility guarantee. The published KMDF v1.33 boundary is the clearest fact for a new Cargo project.

## Creating a First Rust KMDF Package

Start by installing LLVM 17.0.6 through `winget`. The README requires `libclang` for binding generation and warns against LLVM 18 for ARM64 because of a documented binding-generation bug.

The following command installs the README's pinned LLVM package. Select the GUI option that adds LLVM to `PATH`.

```pwsh
winget install -i LLVM.LLVM --version 17.0.6 --force
```

The project also requires a valid WDK environment. Its recommendation is to enter an eWDK developer prompt. Post-build tasks use `cargo-make`, which the README installs with this command.

```pwsh
cargo install --locked cargo-make --no-default-features --features tls-native
```

Create a library package, enter its directory, and add the documented driver dependencies.

```pwsh
cargo new <driver_name> --lib
cd <driver_name>
cargo add --build wdk-build
cargo add wdk wdk-sys wdk-alloc wdk-panic
```

Set the library output type in `Cargo.toml`.

```toml
[lib]
crate-type = ["cdylib"]
```

For a UMDF driver, add the metadata shown below. This metadata identifies the driver model and informs the Cargo Make tasks that driver packaging steps are required.

```toml
[package.metadata.wdk.driver-model]
driver-type = "UMDF"
umdf-version-major = 1
target-umdf-version-minor = 33
```

Create `build.rs` with the configuration call required to prepare the WDK build.

```rust
fn main() -> Result<(), wdk_build::ConfigError> {
   wdk_build::configure_wdk_binary_build()
}
```

For KMDF or WDM, configure aborting panics for development and release profiles.

```toml
[profile.dev]
panic = "abort"

[profile.release]
panic = "abort"
```

## Kernel Mode Setup for DriverEntry and Rust Runtime Support

Kernel-mode packages need additional declarations in `lib.rs`. Mark the crate as `no_std`, include `wdk_panic` outside tests, and install `WdkAllocator` when the driver needs Rust `alloc` modules. The allocator is optional according to the README, so adding it to every kernel driver would exceed the documented requirement.

The panic and allocator setup is shown here.

```rust
#![no_std]

#[cfg(not(test))]
extern crate wdk_panic;

#[cfg(not(test))]
use wdk_alloc::WdkAllocator;

#[cfg(not(test))]
#[global_allocator]
static GLOBAL_ALLOCATOR: WdkAllocator = WdkAllocator;
```

A WDK driver must expose the required entry point. The README's example uses the name `DriverEntry` through `#[unsafe(export_name = "DriverEntry")]` and returns `NTSTATUS`.

```rust
use wdk_sys::{
   PDRIVER_OBJECT,
   NTSTATUS,
   PCUNICODE_STRING,
};

#[unsafe(export_name = "DriverEntry")]
pub unsafe extern "system" fn driver_entry(
   driver: PDRIVER_OBJECT,
   registry_path: PCUNICODE_STRING,
) -> NTSTATUS {
   0
}
```

The example returns zero and does not implement initialization or cleanup. Its value is structural: it shows the ABI shape and symbol export that the WDK build expects. Real driver behavior remains the package author's responsibility.

## Maintenance, License, and Upgrade Boundaries

The repository is not archived, and its last push was on 2026-10-16. Recent release entries include `wdk-v0.4.1`, `wdk-sys-v0.5.1`, and `wdk-panic-v0.4.1`, all dated 2025-11-14. These dates indicate recent repository activity and published crate releases, but they do not override the README's warning that the project is not recommended for production use.

The root `Cargo.toml` declares the workspace package license as `MIT OR Apache-2.0`, and the repository contains both `LICENSE-MIT` and `LICENSE-APACHE`. This is a dual-license statement rather than an Apache-2.0-only declaration. License selection and compliance remain matters for the adopting project, but the repository files alone do not provide legal guidance.

Upgrade planning has two concrete layers. First, `wdk-sys` and `wdk-macros` use exact, lockstep versions in the workspace because the procedural macro crate is consumed through `wdk-sys` re-exports and the two crates share a coupled API. Second, changing the WDK configuration may require editing `crates/wdk-sys/build.rs`. A Cargo update is therefore not the only upgrade step when the target WDK or driver model changes.

## Conclusion

Engineers experimenting with Windows drivers in Rust should start with the KMDF v1.33 configuration documented by the project, while teams requiring production support or another WDK configuration should verify compatibility first. Kernel-mode projects must also confirm panic, allocator, LLVM, and WDK environment requirements before adoption.

## FAQ

### Which Windows driver models does windows-drivers-rs support?

The repository is designed for WDM, KMDF, UMDF, and Win32 Services. Its examples include minimal WDM, KMDF, and UMDF drivers.

### Which KMDF configuration is available from crates.io for windows-drivers-rs?

The README states that crates published on crates.io currently support KMDF v1.33. Other configurations require cloning the repository and modifying the configuration in `crates/wdk-sys/build.rs`.

### What does a kernel-mode windows-drivers-rs package need in Cargo.toml and lib.rs?

The package needs `crate-type = ["cdylib"]`, aborting panics for development and release profiles, a `wdk_build::configure_wdk_binary_build()` call in `build.rs`, and `#![no_std]` plus a `wdk_panic` handler in `lib.rs`. `WdkAllocator` is additionally required when the driver uses Rust `alloc` modules.

## Sources

- [Issues](https://github.com/microsoft/windows-drivers-rs/issues)
- [License: Apache-2.0](https://github.com/microsoft/windows-drivers-rs/blob/main/LICENSE)
- [microsoft/windows-drivers-rs on GitHub](https://github.com/microsoft/windows-drivers-rs)
- [README](https://github.com/microsoft/windows-drivers-rs/blob/main/README.md)
- [Releases](https://github.com/microsoft/windows-drivers-rs/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-windows-drivers-rs