# Windows-driver-samples: Microsoft's catalogue of kernel and UMDF device drivers

> This repository is the reference implementation for writing Windows drivers, organised by hardware bus rather than by feature, and shipped under the Microsoft Public License. Here is how the tree is laid out, how to build it, and what Microsoft itself says you must change before shipping.

**microsoft/Windows-driver-samples** — This repo contains driver samples prepared for use with Microsoft Visual Studio and the Windows Driver Kit (WDK). It contains both Universal Windows Driver and desktop-only driver samples.

- Repository: https://github.com/microsoft/Windows-driver-samples
- Stars: 7,880 · Forks: 5,035
- Language: C
- License: MS-PL
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-windows-driver-samples

## A tree organised by hardware bus

The first thing to understand about this repository is that it is a catalogue, not an application. There is nothing to run. The top level is a set of directories named after the hardware interfaces a Windows driver can attach to, and each one contains working samples for that class of device.

The list is long enough to be the most useful thing in the repository: `usb/`, `storage/`, `serial/`, `hid/`, `audio/`, `avstream/`, `video/`, `bluetooth/`, `nfc/`, `nfp/` for near field communications, `gnss/`, `gpio/`, `sd/`, `spb/` for the serial peripheral bus, `thermal/`, `powerlimit/`, `sensors/`, `filesys/` for file systems, `print/`, `wia/` for image acquisition, `pofx/` for audio effects, `pos/` for point of sale, `input/`, `smartcrd/` for smart cards, `security/`, `prm/` for power management, `simbatt/`, `network/`, and `wmi/`.

Three more directories are infrastructure rather than device classes. `general/` holds samples that are not tied to one bus, `wil/` is the Windows Implementation Library that the samples themselves use, and `setup/` contains the INF and installation pieces a driver needs to land on a machine.

That organisation is the reason to use the repository. When you are writing a USB driver you read `usb/` and you do not have to decide which of thirty folders is relevant. When you are looking for how a file system filter should be structured you read `filesys/`. Search engines are bad at this and the `ListAllSamples.ps1` script at the repository root exists for the same reason.

## Building with the scripts rather than opening a project

The README's toolchain requirement is specific: Visual Studio 2022 and Windows Driver Kit 11. It also notes that with Windows 11 the driver development environment is integrated into Visual Studio, so the WDK installs as an extension rather than as a separate toolchain to configure.

The repository does not expect you to open a solution by hand and press build. There is a small set of PowerShell scripts at the root for driving the whole thing, and these are the ones you invoke if you want to compile a sample rather than read one:

```powershell
ListAllSamples.ps1
Build-Samples.ps1
BuildEnvironment.ps1
Get-NtTargetVersions.ps1
UpdateNuGet.ps1
```

`BuildEnvironment.ps1` sets up the build environment, `Get-NtTargetVersions.ps1` reports which target Windows versions are available to build against, and `UpdateNuGet.ps1` handles package updates. `Directory.Build.props` at the root carries shared MSBuild properties, and `packages.config` shows that at least some samples still use the older NuGet package format rather than PackageReference.

There is a `TrEE/` directory and a `_wdk_utils/` directory whose purpose the README does not explain, and a `tools/` directory as well. Treat them as places to look when a build fails rather than as things to read first.

For continuous integration there is a documented path: the README links to a `.github/Build-with-GitHub.md` document for using GitHub Actions to build a simple driver project. That is the piece worth reading if you intend to compile drivers on every commit, since it is the only part of the repository that talks about automated builds.

The library dependencies arrive as submodules, given the `.gitmodules` file at the root, and `exclusions.csv` suggests some samples are held out of bulk builds, which is worth knowing before you assume a build script covers the whole tree.

## Universal drivers, WDF, and the KMDF and UMDF split

Windows has two driver models and the choice matters more than anything else you will read in these samples. UMDF, the User Mode Driver Framework, runs your code in a user mode process. KMDF, the Kernel Mode Driver Framework, runs it in kernel mode. The Windows Driver Frameworks are the libraries that make both practical, and the repository description states that it contains both Universal Windows Driver samples and desktop-only samples, while the README's own emphasis is on writing one driver that runs on Windows 11 for desktop editions as well as other editions that share a common set of interfaces.

Both of those descriptions are in the project and they are not quite the same emphasis. The README is framed around Universal drivers and portability across form factors from phones to desktop PCs, which is the forward-looking story. The description is blunter about scope and admits that some samples are desktop-only, which is the practical one. Read both and you get the true picture: a repository that is mostly aimed at portable drivers, with a set of samples that cannot be portable because the hardware they drive cannot be.

The README's build-your-first-driver section is the gentlest on-ramp, and it is worth following in order even if you skip it. Each exercise is independent, and it offers a UMDF driver from a template, a very small KMDF hello world driver, and a KMDF driver from a template. Starting from hello world rather than a real bus sample is deliberate advice: the KMDF samples in particular share a lot of infrastructure, and reading one before you understand the framework's lifecycle model is a poor use of time.

For the framework documentation itself, the README links a WDF driver development guide and a getting started page for Universal drivers on docs.microsoft.com, which is where the model differences are documented properly.

## Microsoft says the samples are not production code

The most important sentence in this README is easy to skim past. It points to a document titled From Sample Code to Production Driver, What to Change in the Samples, and describes it as covering the important changes that need to be made in the WDK sample drivers before releasing device drivers based on the sample code.

Read that as the vendor stating that these samples are demonstrations. Whatever a sample omits, it omits on purpose, because the sample is there to show the shape of an interface rather than to satisfy the requirements that Windows imposes on a shipping driver. The repository is honest about this, which is more than most sample code gets you.

That makes the samples a poor starting point for a shortcut. If you copy a sample, find the minimal delta that compiles, and stop, you have a driver that shows the mechanism and skips the hardening. The changes Microsoft calls out are the ones between those two states, and the document is the list to work through before you ship.

The same applies to security. A `security/` directory exists in the tree, and there is a `SECURITY.md` at the root, but a sample driver that registers a device, accepts I/O requests and runs with elevated privileges is a much more attractive target than a hardened one. Nothing in the README suggests the samples are hardened for adversarial input, and the samples are teaching code.

Where the README is genuinely good is scope. It says the samples guide development whether you are getting started or porting an older driver to the newest version of Windows. For a port, they are close to ideal, because the differences between Windows versions in the driver model are exactly the kind of detail that is tedious to look up and reliable to copy from an official example.

## Release tags that stopped in 2022 while commits did not

Here the repository's own records disagree with each other, and it is better to lay both out than to pick one. The releases are `win11-22h2` published on 2022-05-26, `253337` published on 2020-12-16, and `243329` published on 2020-12-03. The README, meanwhile, is titled for Windows 11 and asks you to use Visual Studio 2022 with Windows Driver Kit 11, which is a later generation of the toolchain than the one that shipped alongside a 22H2 tag. The last push was on 2026-09-18 and the repository is not archived.

So the newest tag describes Windows 11 22H2 from 2022, while the working tree has been updated for years after that and the README now references WDK 11. Both are true. The likeliest reading is that these tags are not the project's release mechanism: they look like periodic snapshot or servicing tags rather than versioned releases, and the numbering of the two older ones, `253337` and `243329`, is a Windows build number rather than a package version, which fits that reading. Microsoft does not version this repository the way an open source project does.

What this means for you is concrete. Do not select a sample by checking out the newest tag and assume you are reading the current code, because the newest tag is about four years older than the branch. Work from `main`, and identify your target by directory and by toolchain version rather than by tag. If you need a sample that corresponds to a specific Windows release, the tag names hint that such snapshots exist, and searching the history for the tag matching your version is the way to find one.

The other metadata worth noting is thin. The repository has no topics recorded and no homepage set, and GitHub reports C as the primary language, which is accurate for a codebase that is mostly kernel mode C. There is a Code of Conduct in the README, adopting the Microsoft Open Source Code of Conduct, with a contact address for questions.

## The Microsoft Public License and who should use this

GitHub records the license as MS-PL, the Microsoft Public License. That is worth pausing on if you are choosing a repository by license, because MS-PL is a permissive, file-level copyleft license written by Microsoft, and it is not the MIT or Apache-2.0 that most projects in this space use. What it obliges you to do depends on whether you modify the files and whether you redistribute, and that is a question to answer from the LICENSE text and your own circumstances rather than from this article.

Practically, most people reading this repository are not choosing it as a dependency. You cannot link a driver sample into an application the way you would a library, because the output is a `.sys` file that has to be signed, installed and attested to run on Windows. The realistic uses are narrower.

If you are writing a driver for the first time, the per bus sample is the best available description of what Microsoft expects, and the getting started exercises are the sensible order. If you are porting a driver to a newer Windows version, the samples are close to ideal for the same reason. If you are looking for something to install on your own machine, this is the wrong repository entirely, because driver samples are development artifacts and the drivers you actually want are distributed by the hardware vendors.

That last point is the one the SERP data for this project keeps showing, since people searching for these samples are usually looking for a driver to install rather than code to read. The repository does not contain production drivers for any consumer device. It contains examples of how to write one.

## Conclusion

Treat this repository as a reference implementation rather than as code to drop into a product. It earns its keep when you are learning how a Windows bus expects a driver to behave, when you are porting a driver from an older Windows version, or when you need the exact structure Microsoft expects for a device class. Two things to check before relying on it. First, the release tags stopped at `win11-22h2` in May 2022 even though the README now describes WDK 11, so identify your target Windows version and confirm the sample directory you plan to read matches it rather than trusting the newest tag. Second, read the `From Sample Code to Production Driver` document that the README links, because Microsoft states plainly that the samples need changes before release, and the ones it lists are the difference between a demonstration and something that passes attestation and signing.

## FAQ

### What does the microsoft Windows-driver-samples repository contain?

It contains the official Windows Driver Kit driver code samples, organised by hardware bus, including usb, storage, serial, hid, audio, bluetooth, nfc, gnss and file system directories. GitHub records the primary language as C and the license as MS-PL.

### What tools do I need to build a Windows driver sample?

The README asks for Visual Studio 2022 with Windows Driver Kit 11, and notes the driver environment is integrated into Visual Studio on Windows 11. Repository scripts including BuildEnvironment.ps1, Get-NtTargetVersions.ps1 and Build-Samples.ps1 handle the build, and there is a GitHub Actions guide for building a project in CI.

### Can I use these Windows driver samples in a product I ship?

Not without changes. The README links a document titled From Sample Code to Production Driver, What to Change in the Samples, and describes it as covering the changes needed in the WDK samples before releasing drivers based on them. The samples are demonstrations of an interface rather than hardened drivers.

### What is the difference between KMDF and UMDF in these samples?

KMDF is the kernel mode driver framework, where your code runs in kernel mode, and UMDF is the user mode driver framework, where it runs in a user mode process. The README's getting started exercises cover a UMDF driver from a template, a small KMDF hello world driver, and a KMDF driver from a template.

### Which Windows version do these driver samples target?

The README is titled for Windows 11 and asks for WDK 11 with Visual Studio 2022. The newest release tag is win11-22h2 from 2022-05-26 while the branch has been pushed to since, so tags lag the working tree and you should identify a sample by directory and toolchain rather than by tag.

## Sources

- [Issues](https://github.com/microsoft/Windows-driver-samples/issues)
- [License: MS-PL](https://github.com/microsoft/Windows-driver-samples/blob/main/LICENSE)
- [microsoft/Windows-driver-samples on GitHub](https://github.com/microsoft/Windows-driver-samples)
- [README](https://github.com/microsoft/Windows-driver-samples/blob/main/README.md)
- [Releases](https://github.com/microsoft/Windows-driver-samples/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-driver-samples