Windows Driver Developer Blog articles

Announcing Preview WDK with VS2026

prashantchahar — Fri, 10 Apr 2026 18:41:56 GMT

We're excited to announce a preview release of the Windows Driver Kit (WDK) that, for the first time, is compatible with Visual Studio 2026 (18.4 and later). This continues our ongoing effort to modernize the driver development experience while giving hardware partners and driver developers early access to the latest toolchains.

What's New in This Preview

Visual Studio 2026 Support

This preview WDK is the first release to support Visual Studio 2026. Developers can take advantage of the newest Visual Studio platform to build, test, and package Windows drivers using familiar WDK workflows. Visual Studio 2026 brings improvements across performance, C++ tooling, diagnostics, and overall IDE reliability—all of which directly benefit large driver solutions and complex build pipelines. For more on this, see Visual Studio 2026 Release Notes

WDK Delivery and Availability

The WDK ships in three packaging formats, all of which now support Visual Studio 2026 in this preview:

Format	Where to Get It
SDK MSI	Windows Insider Program
WDK NuGet	Nuget.org
WDK MSI	Windows Insider Program
Enterprise WDK (EWDK) ISO	Windows Insider Program

The NuGet-based WDK is the recommended approach for modern and automated workflows. For developers who need traditional layouts or offline/self-contained build environments, the WDK MSI and EWDK ISO are available through the Windows Insider Program.

Build Tools Support with WDK and SDK MSIs

A common request has been better alignment between Visual Studio Build Tools and driver builds. In this preview, that experience is improved.

What's Supported

Visual Studio Build Tools can now be used alongside installed Windows SDK and Windows Driver Kit MSIs.
Installing the "Windows Driver Kit" individual component via the Visual Studio Installer enables:

Headless build machines
CI agents without the full Visual Studio IDE
Cleaner separation between development and build environments

Setup Guide

Download and Install Visual Studio Build Tools for VS 2026.
- In the installer, select:
  - Individual Components → Windows Driver Kit
Open NuGet Package Manager and search for Microsoft.Windows.WDK and select
10.0.28000.1761-preview
Or if you wan to use MSIs proceed further.
Install the Windows SDK MSI.
Install the Windows Driver Kit MSI (preview).
Proceed with building drivers using MSBuild as usual.

This setup works well for CI/CD pipelines and enterprise build environments where the full IDE is unnecessary.

Preview Notes

This is a preview release intended for evaluation and early adoption.
APIs, tooling behavior, and compatibility details may evolve.

We're looking forward to your feedback as you try this preview and bring your driver development workflows onto Visual Studio 2026.

HLK Testing Updates for Software and Filter Drivers

Paul_Eze — Wed, 08 Apr 2026 21:04:32 GMT

All drivers that participate in the Windows Hardware Compatibility Program (WHCP) are expected to meet Microsoft’s baseline quality, reliability, and security requirements before they are signed and distributed. These requirements are enforced through Hardware Lab Kit (HLK) testing and certification workflows.

Historically, HLK testing coverage was most consistently applied to hardware device drivers. As a result, software drivers and filter drivers did not always receive the same level of automated test coverage, even though they operate in equally privileged and security‑sensitive areas of the operating system.

This gap has now been addressed.

What Changed

To improve validation of file system mini‑filters and other Filter Manager (fltmgr) clients, new test capabilities were added that allow HLK and Windows Driver Test Framework (WDTF)–based scenarios to reason explicitly about filter drivers. These changes are available in 26H1 HLK and the upcoming 2026.03 WDK release under ERT.

These updates include:

Enhanced Driver Verifier

Filter Verifier is now enabled for File System MiniFilter and software drivers. Filter Verifier validates correct usage of Filter Manager APIs, enforces object-lifetime rules and integrates with Driver Verifier (DV) to surface violation during runtime testing.

See File System Filter Verification , Storport Verification and I/O Verification

What this enables

When Filter Verifier is enabled and exercised through DV/WDTF testing, additional Driver Verifier checks are applied across the active device stack. These checks may surface violations such as:

Execution‑context violations
Reported via Driver Verifier (for example, VRF_ExecutionContext!PollWorkerEntry) when a driver executes at an invalid IRQL or in an inappropriate threading context.
Leaked pool allocations
Reported when verified drivers fail to release memory during unload or stress scenarios (for example, VRF_LEAKED_POOL_IMAGE_*).
Security‑isolation and object‑lifetime violations
Reported when kernel objects such as FLT_CALLBACK_DATA or FILE_OBJECT are not correctly released.

WDTF/DEVFUND Improvements

Expanded Test Coverage

Windows Device Testing Framework (WDTF) is used to support the verification of Filesystem MiniFilters drivers. As part of this work, HLK coverage for software and filter drivers was significantly expanded, increasing the number of applicable HLK tests from 22 to 41. This expansion enables a broader set of existing DevFund scenarios to run against filesystem filter drivers, substantially improving validation coverage for correctness, reliability, and OS contract compliance.

WDTF Action Plugins

New WDTF action plugins were introduced and integrated into FIlter Manager (Fltmgr) API based tests into DevFund in the HLK to enable more targeted validation of File System MiniFilter drivers. These tests leverage Filter Manager User-Mode Library.

The WDTF volume plugin has been updated with this new functionality. The new coverage will apply to the following filters

FSFilter Activity Monitor
FSFilter Anti‑Virus
FSFilter Bottom
FSFilter Cluster File System
FSFilter Compression
FSFilter Content Screener
FSFilter Continuous Backup
FSFilter Copy Protection
FSFilter Encryption
FSFilter HSM
FSFilter Imaging
FSFilter Open File
FSFilter Physical Quota Management
FSFilter Quota Management
FSFilter Replication
FSFilter Security Enhancer
FSFilter System Recovery
FSFilter Top
FSFilter Undelete
FSFilter Virtualization

These plugins allow tests to observe I/O behavior, apply Driver Verifier dynamically, and generate concurrent I/O patterns under stress conditions.

WDTF Datagathers updates

WDTF datagathers were enhanced to enumerate active File System MiniFilter drivers on a per‑volume basis using Filter Manager APIs. This allows tests to accurately detect loaded filters, their attachment state, and associated filter communication ports, enabling DevFund and HLK tests to correctly target and validate filesystem filter drivers

WDTF IO Plugin Updates

Several WDTF I/O plugins were updated to improve Filesystem MiniFilter validation:

The Volume WDTF plugin was updated to leverage Filter Manager (FltMgr) APIs when exercising File System MiniFilter functionality.
Support was added for validating filter communication ports.
FSCTL‑based I/O was introduced to better exercise filesystem‑specific control paths.
The WDTF Driver Verifier plugin was enhanced to enable targeted verification during DevFund and HLK test execution, including:
- WDM I/O verification,
- Filter Verifier for filesystem filters,
- SCSI and Storport verifiers for disk and storage drivers.

This work ensures that filter drivers—especially those operating in security‑sensitive paths—are exercised and validated using the same framework rigor as other kernel‑mode drivers.

Previously, some tests did not enumerate for these driver classes due to tooling limitations. Those limitations have been removed, and HLK now applies the appropriate tests to these drivers where applicable.

Why This Matters

Software and filter drivers play a critical role in system stability and security. Ensuring they are validated consistently helps improve ecosystem reliability and reduces the risk of system‑wide impact from driver failures.

No new certification bar has been introduced. Instead, this change closes a gap where HLK behavior did not fully reflect the security and quality intent that already applied to kernel‑mode drivers.

The goal is consistency:

Software drivers
Filter drivers
Hardware device drivers

are all held to the same baseline expectations when they participate in WHCP.

Call to Action

If you develop:

Kernel‑mode software drivers
File system mini‑filters
Security‑sensitive filter drivers

you may now see additional HLK tests enumerate where they previously did not. This reflects corrected tooling behavior, not a policy change.

If you encounter unexpected results or believe a test is being applied incorrectly, please engage through the standard driver support channels.

Announcing Device IOCTL/WMI Record and Playback Platform (DRPP)

prashantchahar — Wed, 28 Jan 2026 01:38:49 GMT

The Device IOCTL/WMI Record and Playback platform (DRPP) records the Device I/O Control Codes (IOCTLs, kernel model IRP_MJ_DEVICE_CONTROL) and WMI I/O Request Packets (IRPs, kernel mode IRP_MJ_SYSTEM_CONTROL) that are successfully processed by the devnode for one or more Device(s) Under Test (DUTs). The purpose of this security extension to the WDTF platform is to discover which Device I/O Control Codes and WMI IRPs cause the driver and/or device to perform a specific action as opposed to simply return an error. These IOCTLs, IRPs are recorded to a file which can be written to when executing any WDTF based test such as Devfund". A new test can be written to replay this IO back to the Device under test thus saving time and machine cycles (since only ‘meaningful’ IOCTLs and WMI IRPs will be executed rather than all IOCTLs and IRPs). This platform is shipped as part of WDK..

The DRP platform consists of the following components:

An Upper Filter Device Object (FiDO) installed on the DUT that records Device I/O Control Codes and WMI IRPs to a data file with target binding information.
An IoSpy Action to enable and disable Filter Device Object(s) installed on the DUT.
A Fuzz test is used to generate the IOCTLs and WMI IRPs for DUT(s).
An IoSpy Action to disable the Filter Device Object installed on one or more the DUTs.
A Replay Action to playback any successfully processed IRPs or IOCTLs.

The features of the platform are executed in order as a system which consists of the following phases:

Using WDK to prepare a system for driver development and testing which will consist of a developer box and a target machine, and the target machine will host the hardware/device under test.
Upper Filter Device Object (IoSpy) Enable Phase: enables/installs the IoSpy driver on the DUT.
Recording (training) Phase: records various details about the DUT, Device I/O Control Codes, and WMI IRPs to a file.
Playback Phase: uses the data file to intelligently test DUT(s).

These phases are described in more detail through the rest of this document.

1. Setting up test and target machines

Provision the target from Visual Studio (sets debugger + surfaces KD key/port) ( https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/provision-a-target-computer)

Install WDK using https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk
On the host, open Visual Studio → Extensions → Driver → Test → Configure Devices.
Select Add new device → set Network host name to the target’s computer name or local IP.
Check Provision device and choose debugger settings → Next.
Choose KDNET (Network) and required settings will be prefilled, make sure the host IP is set correct. For KDNET, Visual Studio will configure the network transport and generate the KD key and port values used by WinDbg. Provisioning may reboot the target multiple times. When finished, select Finish, then restart the host if prompted.

After provisioning, the Configure Devices menu displays connection details for kernel debugging—KD key and debug port. Use these values to attach WinDbg (x64) from the host:

Kernel Debugger (recommended)

Launch WinDbg (x64) as Administrator on the host.
File → Kernel Debug → NET.
Enter the Port, and Key exactly as shown on the Target Machine Ready screen of driver extension.

2. Upper Filter Device Object (IoSpy) the Enable Phase

IoSpy is a filter driver that creates an upper Filter Device Object (FiDO) that records data about IOCTLs and WMI requests made to the kernel-mode device or devnode/DUT.

The IoSpy Action is used to install, uninstall the IoSpy driver’s upper FiDO on one or more DUTs. The Device Query (DQ) parameter controls which DUT(s) the IoSpy filter driver’s FiDO is installed on. The diagram below shows how the IoSpy driver is enabled on a DUT and what the device stack looks like after the FiDO has been installed:

Below is sample code of how to install the IoSpy FiDO on a ‘media’ class DUT on a given system using powershell 7.5.0:

# Create the WDTF COM object

$wdtf = New-Object -ComObject "WDTF2.WDTF"

# Query for all started devices in the desired class

# Use 'Camera' for cameras, or 'Media' if you want to keep the scope wider. See here for more

# options for SDEL query https://learn.microsoft.com/en-us/windows-hardware/drivers/wdtf/simple-data-evaluation-language-overview

$devices = $wdtf.DeviceDepot.Query("IsDevice AND Class='Media' AND IsStarted=True")

# Loop through each device and enable IoSpy

foreach ($device in $devices) {

$ioSpy = $device.GetInterface("IoSpy")

$ioSpy.Enable()

}

Below logging information is from this phase. This information is logged by an example test which uses the DRP platform, specifically the IoSpy driver:

WDTF_TARGETS : INFO : - Query("IsDevice AND Class='Media' AND IsStarted=True")

WDTF_TARGETS : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_TARGETS : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_TARGETS : INFO : Target: Realtek High Definition Audio HDAUDIO\FUNC_01&VEN_10EC&DEV_0899&SUBSYS_102805B7&REV_1000\4&220B1BB

C&0&0001

WDTF_TARGET : INFO : - GetInterface("IoSpy")

WDTF_TARGET : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_IOSPY : INFO : - Enable()

WDTF_IOSPY : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_IOSPY : INFO : Data file located at : \??\C:\iospy\IoSpyData_00000037

WDTF_PNP : INFO : - DisableDevice()

WDTF_PNP : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_PNP : INFO : - EnableDevice() : ( get status count: 1 )

WDTF_PNP : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_TARGET : INFO : - GetInterface("IoSpy")

WDTF_TARGET : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_IOSPY : INFO : - Enable()

WDTF_IOSPY : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_IOSPY : INFO : Data file located at : \??\C:\iospy\IoSpyData_00000041

WDTF_PNP : INFO : - DisableDevice()

WDTF_PNP : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

3. Recording (training) Phase

The training phase is longer than the playback phase as we use the Fuzz Action to send many Device I/O Control Codes (IOCTLs) and WMI IRPs to the DUT. In this phase, we specifically identify the IOCTLs and IRPS that the DUT succeeded in and write this information to a data file specific to the DUT. This is how the DRP extension to the WDTF platform determines which IOCTLs and IRPs are ‘meaningful’ to the device- that is, the specific IOCTL or WMI IRP causes the device or driver to perform some action besides simply return an error.

The diagram below shows how the IoSpy driver records IRP and IOCTL processing for a DUT:

The logging information below is from this phase. This information is logged by a test which uses the DRP, specifically the IoSpy driver:

WDTF_TARGETS : INFO : - Query("IsDevice AND Class='Media' AND IsStarted=True")

WDTF_TARGETS : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_TARGETS : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_TARGETS : INFO : Target: Realtek High Definition Audio HDAUDIO\FUNC_01&VEN_10EC&DEV_0899&SUBSYS_102805B7&REV_1000\4&220B1BBC&0&0001

WDTF_TEST : INFO : Device NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_TEST : INFO : IoSpy Info

WDTF_TEST : INFO : Enabled : True

WDTF_TEST : INFO : DataFileName : \??\C:\iospy\IoSpyData_00000037

WDTF_TEST : INFO : fsDataFilePresent : True

WDTF_TEST : INFO : Device Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_TEST : INFO : IoSpy Info

WDTF_TEST : INFO : Enabled : True

WDTF_TEST : INFO : DataFileName : \??\C:\iospy\IoSpyData_00000041

WDTF_TEST : INFO : fsDataFilePresent : True

WDTF_TEST : INFO : Device Realtek High Definition Audio HDAUDIO\FUNC_01&VEN_10EC&DEV_0899&SUBSYS_102805B7&REV_1000\4&220B1BBC&0&0001

WDTF_TEST : INFO : IoSpy Info

WDTF_TEST : INFO : Enabled : True

WDTF_TEST : INFO : DataFileName : \??\C:\iospy\IoSpyData_0000003a

WDTF_TEST : INFO : fsDataFilePresent : True

WDTF_TARGETS : INFO : - Query("IsDevice AND Class='Media' AND IsStarted=True")

WDTF_TARGETS : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_TARGETS : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_TARGET : INFO : - HasInterface("FuzzTest")

WDTF_TARGET : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_TARGET : INFO : - GetInterface("FuzzTest")

WDTF_TARGET : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_TEST : INFO : Number of tests found:5

WDTF_TEST : INFO : Run tests

WDTF_FUZZTESTS : INFO : - RunAll()

WDTF_FUZZTESTS : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_FUZZTESTS : INFO : - RunTestUntilStopped(SubOpens Test)

WDTF_FUZZTESTS : INFO : Target: Microsoft® LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&64B94B2&0&0002

WDTF_FUZZTEST : INFO : - Start()

WDTF_FUZZTEST : INFO : Target: Microsoft® LifeCam VX-7000

WDTF_FUZZTEST : INFO : - Starting fuzz test: SubOpens Test

WDTF_FUZZTEST : INFO : Target : Microsoft® LifeCam VX-7000

WDTF_FUZZTEST : INFO : Found 2 interfaces.

WDTF_FUZZTEST : INFO : Attempting to open interface: \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global

WDTF_FUZZTEST : INFO : Opened \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global. Access Mode=NO SYNC. Open Type=OTHER. Opened with access 1201bf [0]

WDTF_FUZZTEST : INFO : Opened \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global. Access Mode=DIRECT. Open Type=OTHER. Opened with access 120080 [0]

WDTF_FUZZTEST : INFO : Opened \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global\ . Access Mode=NO SYNC. Open Type=OTHER. Opened with access 1201bf [0]

WDTF_FUZZTEST : INFO : Opened \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global\ . Access Mode=DIRECT. Open Type=OTHER. Opened with access 120080 [0]

WDTF_FUZZTEST : INFO : Opened \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global\\. Access Mode=NO SYNC. Open Type=OTHER. Opened with access 1201bf [0]

WDTF_FUZZTEST : INFO : Opened \DosDevices\usb#vid_045e&pid_0723&mi_02#6&64b94b2&0&0002#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global\\. Access Mode=DIRECT. Open Type=OTHER. Opened with access 120080 [0]

Run fuzzing from Visual Studio using the Driver Extension Menu

As the target machine is already provisioned using Visual Studio. Click on the Driver menu under Extensions and select Driver → Test → New Test Group from the context menu. Click add remove tests Choose Fuzz Tests from the list as they make sure to access all the code paths from the available test suites e.g. DF Fuzz Random IOCTL and Fuzz Zero Length buffer test.

Configure and Run the Test
- Set any required test parameters, such as the device query string (e.g., IsDevice AND Class='Media' AND IsStarted=True for media devices).

Click Run to start the Devfund test. Visual Studio will deploy the test binaries, execute the test on the target, and collect results.
Review Results
- Test results, including logs and status, will appear in the Visual Studio Test Explorer or Output window.

When the devices were configured to be spied upon, IoSpy Data file is generated for all the devices which are under test. Following binding file and IoSpy data file information will be provided when IoSpy is enabled. These files are not expected to be modified and they are not in human readable format.

Binding File Information Produced

DisplayName	DeviceID	ClassGuid	DriverBinaryNamesAndVersion	IoSpy Data File
NVIDIA High Definition Audio	HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001	{4d36e96c-e325-11ce-bfc1-08002be10318}	ksthunk.sys 10.0.18218.1000 nvhda64v.sys 1.3.35.1	IoSpyData_00000043
Microsoft® LifeCam VX-7000	USB\VID_045E&PID_0723&MI_02\6&24DE6407&0&0002	{4d36e96c-e325-11ce-bfc1-08002be10318}	ksthunk.sys 10.0.18218.1000 usbaudio.sys 10.0.18218.1000	IoSpyData_00000044
Realtek High Definition Audio	HDAUDIO\FUNC_01&VEN_10EC&DEV_0899&SUBSYS_102805B7&REV_1000\4&220B1BBC&0&0001	{4d36e96c-e325-11ce-bfc1-08002be10318}	ksthunk.sys 10.0.18218.1000 rtkvhd64.sys 6.0.1.7544	IoSpyData_00000042
Microsoft® LifeCam VX-7000	USB\VID_045E&PID_0723&MI_00\6&24DE6407&0&0000	{ca3e7ab9-b4c3-4ae6-8251-579ef933890f}	wdmcompanionfilter.sys 10.0.18218.1000 ksthunk.sys 10.0.18218.1000 usbvideo.sys 10.0.18218.1000	IoSpyData_00000041

4.Playback Phase

Now that we have a data file and binding information, using the DRP extension to the WDTF platform we can playback these I/O (IOCTLS and IRPs) to any number of instance(s) of the same Device on any number of systems..

The diagram below shows how playback works for many DUTs on a single system:

Console Output

The user will see the following output on the screen when running a test that uses the Replay Action on a ‘media’ class device, for example:

WDTF_TARGETS : INFO : - Query("IsDevice AND Class='Media' AND IsStarted=True")

WDTF_TARGETS : INFO : Target: NVIDIA High Definition Audio HDAUDIO\FUNC_01&VEN_10DE&DEV_0051&SUBSYS_10DE1087&REV_1001\5&2A94585&0&0001

WDTF_TARGETS : INFO : Target: Microsoft« LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&24DE6407&0&0002

WDTF_TARGET : INFO : - GetInterface("IoReplay")

WDTF_TARGET : INFO : Target: Microsoft« LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&24DE6407&0&0002

WDTF_TEST : INFO : DataFile: \??\C:\iospy\IoSpyData_0000003d

WDTF_IoReplay : INFO : - IoReplayIOCTL()

WDTF_IoReplay : INFO : Target: Microsoft« LifeCam VX-7000 USB\VID_045E&PID_0723&MI_02\6&24DE6407&0&0002

WDTF_IoReplay : INFO : Data file located at : \??\C:\iospy\IoSpyData_0000003d

WDTF_IoReplay : INFO : Result: Number of IOCTL entries: 2219286. Number of IOCTL to replay 69862

WDTF_TARGET : INFO : - GetInterface("IoReplay")

WDTF_TARGET : INFO : Target: Realtek High Definition Audio HDAUDIO\FUNC_01&VEN_10EC&DEV_0899&SUBSYS_102805B7&REV_1000\4&220B1BBC&0&0001

WDTF_TEST : INFO : DataFile: \??\C:\iospy\IoSpyData_00000037

WDTF_IoReplay : INFO : - IoReplayIOCTL()

WDTF_IoReplay : INFO : Target: Realtek High Definition Audio HDAUDIO\FUNC_01&VEN_10EC&DEV_0899&SUBSYS_102805B7&REV_1000\4&220B1BBC&0&0001

WDTF_IoReplay : INFO : Data file located at : \??\C:\iospy\IoSpyData_00000037

WDTF_IoReplay : INFO : Result: Number of IOCTL entries: 59936772. Number of IOCTL to replay 2285436

Below is sample powershell script that is used to call the Replay action for a Microsoft LifeCam Camera or Media DUT, for example:

# Create the WDTF COM object

$wdtf = New-Object -ComObject "WDTF2.WDTF"

# Query for all started Camera device or Media

$devices = $wdtf.DeviceDepot.Query("IsDevice AND Class='Media’ AND IsStarted=True")

# Loop through each device and replay all I/O

foreach ($device in $devices) {

$ioReplay = $device.GetInterface("IoReplay")

$ioReplay.IoReplayAll()

}

Following powershell script can be used to disable IoSpy

# Create the WDTF COM object

$wdtf = New-Object -ComObject "WDTF2.WDTF"

# Query for all started Media devices

$devices = $wdtf.DeviceDepot.Query("IsDevice AND Class='Media' AND IsStarted=True")

# Loop through each device and disable IoSpy

foreach ($device in $devices) {

$ioSpy = $device.GetInterface("IoSpy")

$ioSpy.Disable()

}

Why DRPP? Key Value Pillars for Driver Validation

The Device IOCTL/WMI Record and Playback Platform (DRPP) introduces a more intelligent, modular approach to driver testing. By decoupling I/O capture from execution, the platform provides several strategic advantages for the ecosystem:

Portable Bug Reproduction: Generate standalone data and binding files to reproduce complex issues on remote machines. This "portable repro" allows engineers to investigate bugs on different systems without moving physical hardware.
Simplified Test Infrastructure: Run tests on a Device Under Test (DUT) without the overhead of the full Fuzz Test suite or specific Simple I/O plugins. This significantly reduces setup complexity and environment requirements.
Accelerated Test Cycles: DRPP focuses on replaying relevant, successful I/O rather than "blind" attempts. This targeted approach reduces total test time and ensures machine cycles are spent on meaningful code paths.
Scalable Deployment: Once captured, data files can be used to playback I/O across any number of DUTs on single or multiple systems simultaneously, making it ideal for large-scale validation labs.
Cross-Device Compatibility: Data and binding files can be tailored to run across similar devices within the same class, allowing a single recording to validate an entire product line.
Streamlined Security Collaboration: Share capture files easily between teams to reproduce security vulnerabilities or Bug Checks (BSODs). This facilitates faster patching and better cross-organizational response.
Filling the Plugin Gap: Microsoft can reuse these data files in the WDK and HLK to provide rigorous testing for device classes that currently lack dedicated SimpleIO (WDTF) plugins.
Data-Driven Security Insights: By analyzing results from DRP and associated Fuzz Tests, we can identify "high-risk" device classes—those with higher security exposure—and prioritize hardening efforts accordingly.

Extensions and Interoperability

The DRPP architecture is designed for integration into broader hardware development lifecycles and collaborative workflows:

Data Sharing: By installing the IoSpy recording driver in a lab environment, teams can capture and share data files across Microsoft and third-party organizations to streamline validation.
Security Testing: Recorded data files can be reused to perform security testing, such as IOCTL buffer attacks, across any number of DUTs.
Replay: Users can tailor binding data to allow for replay and security testing on similar devices within the same device setup class.
Cloud Based Distribution: Training data collected from Microsoft machines can be shared with third parties via Azure, significantly shortening the time required for security testing.

Future Opportunities

We are focused on increasing the flexibility of the platform through the following planned enhancements:

Test Cycle Improvement: Supplying pre-generated data files to IHVs to reduce their internal test cycles.
Data Consolidation: The ability to merge multiple data files for a given DUT or device class into a single test resource.
Granular Control: Enabling the ability to update binding files or remove specific IOCTL entries from a data file for more targeted testing.

References

U.S. Patent 10,922,249 B2. Available at: https://patents.google.com/patent/US10922249B2

Contributors:

Prashant Chahar, Con McGarvey

Towards Rust in Windows Drivers

nate_deisinger — Fri, 14 Nov 2025 23:24:23 GMT

November 2025 update: our cargo-wdk tool is now available on crates.io. As with any cargo tool, it can be installed by running "cargo install cargo-wdk".

Over the last several years, Microsoft and the industry as a whole have embraced Rust as a vital tool to reduce bugs, improve security, and encourage safe, maintainable programming. With its compile-time guarantees around memory safety and strong ergonomics, Rust is a powerful tool for systems-level programming.

We’ve received lots of feedback from driver developers who want to begin writing Windows drivers in Rust so they can take advantage of these benefits when working with the Windows kernel. In response, the Windows team has been working to create a framework for writing and deploying drivers in Rust. By building off the terrific efforts of the Surface team, we’re starting our journey to make Rust a first-class language for driver developers around the world.

This blog post will cover the current state of Rust for Windows Drivers and discuss our vision for the future.

windows-drivers-rs and the WDK environment

Driver developers are used to writing drivers in C by linking to the libraries included in the Windows Driver Kit (WDK). Our goal is to ensure that Rust developers can take advantage of the same libraries and headers in the WDK as C developers, granting them access to all the DDIs needed to write a Windows driver.

windows-drivers-rs is the primary Git repo for enabling developers to begin using Rust with the WDK. Pioneered by Surface, this repo contributes the following crates to the ecosystem:

wdk-build: A library to configure a Cargo build script that performs downstream linking of the WDK and generates Rust bindings.
wdk-sys: Direct FFI bindings to APIs available in the WDK. This includes both autogenerated ffi bindings from bindgen, and also manual re-implementations of macros that bindgen fails to generate.
wdk: Safe idiomatic bindings to APIs available in the WDK.
wdk-panic: Default panic handler implementations for programs built with WDK
wdk-alloc: A global allocator for use by drivers.
wdk-macros: A collection of macros that help make it easier to interact with wdk-sys's direct bindings. This crate is re-exported via wdk-sys and crates should typically never need to directly depend on wdk-macros.
cargo-wdk: A cargo tool to make setting up a Rust driver environment simpler.

Using these crates, driver developers can create valid WDM, KMDF, and UMDF driver binaries that load and run on a Windows 11 machine. For example, this is what a driver entry routine looks like in our KMDF sample:

/// `DriverEntry` initializes the driver and is the first routine called by the /// system after the driver is loaded. `DriverEntry` specifies the other entry /// points in the function driver, such as `EvtDevice` and `DriverUnload`. /// /// # Arguments /// /// * `driver` - represents the instance of the function driver that is loaded /// into memory. `DriverEntry` must initialize members of `DriverObject` /// before it returns to the caller. `DriverObject` is allocated by the system /// before the driver is loaded, and it is released by the system after the /// system unloads the function driver from memory. /// * `registry_path` - represents the driver specific path in the Registry. The /// function driver can use the path to store driver related data between /// reboots. The path does not store hardware instance specific data. /// /// # Return value: /// /// * `STATUS_SUCCESS` - if successful, /// * `STATUS_UNSUCCESSFUL` - otherwise. #[link_section = "INIT"] #[export_name = "DriverEntry"] // WDF expects a symbol with the name DriverEntry extern "system" fn driver_entry( driver: &mut DRIVER_OBJECT, registry_path: PCUNICODE_STRING, ) -> NTSTATUS { let mut driver_config = WDF_DRIVER_CONFIG { Size: WDF_DRIVER_CONFIG_SIZE, EvtDriverDeviceAdd: Some(echo_evt_device_add), ..WDF_DRIVER_CONFIG::default() }; let driver_handle_output = WDF_NO_HANDLE.cast::<WDFDRIVER>(); let nt_status = unsafe { call_unsafe_wdf_function_binding!( WdfDriverCreate, driver as PDRIVER_OBJECT, registry_path, WDF_NO_OBJECT_ATTRIBUTES, &raw mut driver_config, driver_handle_output, ) }; if !nt_success(nt_status) { println!("Error: WdfDriverCreate failed {nt_status:#010X}"); return nt_status; } echo_print_driver_version(); nt_status }

Drivers written in this manner still need to make use of unsafe blocks for interacting with the Windows operating system, but can take advantage of Rust’s rich type system as well as its safety guarantees for business logic implemented in safe Rust. Though there is still significant work to be done on abstracting away these unsafe blocks (more on this below), these Rust drivers can load and run on Windows systems just like their C counterparts.

Introducing cargo-wdk

Traditionally, drivers developed in C have access to various templates in Visual Studio to get up and running quickly. To help make Rust driver development similarly convenient, the Rust for Drivers team has developed cargo-wdk. This cargo extension enables developers to create empty driver projects with all the necessary linkage, build steps, and dependencies pre-populated. It also is capable of calling WDK tools like InfVerif, much as would be done when building a driver in C in Visual Studio. The animation below demonstrates the process:

The above GIF demonstrates a basic cargo-wdk workload. The developer can create a KMDF driver template by calling "cargo wdk new --kmdf". By then calling "cargo wdk build", cargo-wdk invokes INFVerif on the driver and surfaces any errors, as it would in Visual Studio. The developer then edits the INF appropriately, runs cargo-wdk again, and sees that the driver is built alongside the appropriate certificates.

Our long-term goal for cargo-wdk is to enable a developer working in a cargo environment to have access to all the same build tools and configuration options as a developer working in Visual Studio. Some of our medium-term feature plans include:

Automatic installation of dependencies such as the WDK itself
NT_TARGET_VERSION support
Additional driver templates
Full ARM64 support
Increased configurability of build and package steps
Driver deployment to test machines

The next steps: going from unsafe Rust to safe Rust

Today, windows-drivers-rs provides all the building blocks you need to write some kinds of drivers in Rust, but it still requires writing significant amounts of unsafe Rust. Although unsafe Rust still provides benefits such as strong type-checking, zero-cost abstractions, and good FFI compatibility, we recognize that many developers are seeking an experience where the majority of driver code can be written in safe Rust. We also believe that Rust’s type system and borrow checker can be used to prevent certain classes of bugs that could previously only be caught via additional static analysis. As such, we have ongoing efforts to expand the scope of windows-drivers-rs and create safe abstractions for kernel-mode structs and DDIs:

For many device classes in Windows, drivers are written using the Windows Driver Framework (WDF). This covers both kernel-mode drivers (KMDF) and user-mode drivers (UMDF). The WDF team is working on designing safe Rust abstractions in consultation with Rust experts. The goal is to design interfaces that let developers write more idiomatic Rust code. By providing safe Rust bindings and abstractions, developers can take advantage of the language’s safety and reliability features to write more secure and reliable code. This should greatly reduce the amount of unsafe code blocks required and provide additional compile time safety.
Other teams within Microsoft are working to develop safe structs and APIs beyond WDF to be used in both core Windows kernel development and in third-party driver development. Some of this work ships today in the Windows kernel.

Due to the complexity and generic nature of the Windows kernel APIs, we expect this design process to take time as we work across multiple teams to find safe, sound ways to expose the Windows API surface. This means that the first wrapper we develop is not always going to be the final wrapper we ship. As an example, here is one team’s experimental wrapper for LookasideList structs in use today internally:

impl<T> LookasideList<T> { /// Creates a new lookaside list for type `T`. /// /// # Arguments /// * `pool_type` - The type of memory pool (e.g., NonPagedPoolNx). /// * `tag` - A four-byte tag used for memory tracking. /// /// # Returns /// * `Ok(Arc<Self>)` if initialization succeeds. /// * `Err(status)` if initialization fails. pub fn new(pool_type: POOL_TYPE, tag: u32) -> Result<Arc<Self>> { if size_of::<T>() == 0 { return Err(STATUS_NOT_SUPPORTED); } // Allocate uninitialized memory for LookasideList<T>, but use MaybeUninit<T> correctly. let arc = Arc::new(MaybeUninit::<LookasideList<T>>::uninit())?; // SAFETY: Initialize the LookasideList<T> in place. let status = unsafe { ExInitializeLookasideListEx( (*arc.as_ptr()).assume_init_ref().inner.get(), None, None, pool_type, 0, size_of::<T>() as SIZE_T, tag, 0, ) }; if !NT_SUCCESS(status) { return Err(status); } // SAFETY: Now the MaybeUninit<T> is fully initialized, so we can assume initialization safely. Ok(unsafe { arc.assume_init() }) } /// Allocates a new instance of `T` from the lookaside list. /// /// # Returns /// * `Ok(ptr)` if allocation succeeds. /// * `Err(STATUS_NO_MEMORY)` if allocation fails. fn allocate(&self) -> Result<*mut T> { // SAFETY: The inner pointer is valid and pinned, so it won't move. Lookaside list is internally synchronized. let ptr = unsafe { ExAllocateFromLookasideListEx(self.inner.get()) } as *mut T; if ptr.is_null() { Err(STATUS_NO_MEMORY) } else { Ok(ptr) } } /// Frees a previously allocated instance of `T` back to the lookaside list. /// /// The pointer must have been allocated from this lookaside list. /// /// # Safety /// /// `ptr` must come from a previous call to `LookasideList::allocate`, it hasn't been freed yet and won't be used anymore. unsafe fn free(&self, ptr: *mut T) { // The inner pointer is valid and pinned, so it won't move. Lookaside list is internally synchronized. // Cast to *mut _ is because ExFreeToLookasideListEx expects a void *. ExFreeToLookasideListEx(self.inner.get(), ptr as *mut _); } } impl<T> Drop for LookasideList<T> { /// Cleans up the lookaside list when it goes out of scope. fn drop(&mut self) { // SAFETY: The lookaside list was initialized on new. unsafe { ExDeleteLookasideListEx(self.inner.get()) }; } }

Though we believe this wrapper to be sound for the purposes of the team that developed it, it requires further review and testing before we can publish it as the “official” wrapper for these APIs. Thus the above should be considered a possible look at what Rust abstractions for our kernel mode might look like, and not final code.

In the long term, as we make design decisions and finalize our wrappers, our intent is to publish these wrapper crates on crates.io as first-class members of the Rust ecosystem.

Our long-term vision

We believe that memory-safe languages such as Rust represent the future of secure software engineering. Today’s security landscape demands reliability and safety guarantees at every surface from the edge to the cloud, and device drivers play a role at every layer in the stack. At the same time, we recognize that there are many driver models and scenarios that Windows needs to support, and it will take time to fully develop Rust bindings and tooling for all of them.

We encourage you to keep an eye on this blog and our windows-drivers-rs GitHub repo for the latest information and tools involved in Rust development for the Windows kernel. Over the coming months, we will publish more information about best practices for using Rust in your driver, submitting Rust drivers to WHCP, using CodeQL for static analysis, and more.

We look forward to advancing the state of the art in memory safety with you all!

Announcing Updated Static Analysis Requirement for Windows Driver Certification

Paul_Eze — Tue, 12 Aug 2025 18:44:53 GMT

As part of our ongoing commitment to improving the quality and reliability of Windows drivers, Microsoft has updated the static analysis requirements for driver certification in the upcoming Windows release.

Static analysis is a foundational requirement of Windows Hardware Compatibility Program. The validation is performed using the Static Tools Logo Test, which leverages CodeQL to identify potential issues in driver code before deployment.

Microsoft periodically reviews and improves the windows driver static analysis requirement. These updates help us stay ahead of the ever-evolving threat landscape while maintaining strong security and reliability standards

The key highlight in the update are:

Static Driver Analysis checks now apply to software and filter drivers, including antivirus and anti-cheat drivers.
In addition to the existing “must-fix” CodeQL queries required for the Microsoft's static driver analysis testing, partners are now required to run a new set of checks called “must-run.”

This article outlines how to obtain the latest CodeQL query pack and validate your drivers against the updated Microsoft static analysis requirement.

Prerequisites

Before running the updated static analysis tests, ensure the following components are in place:

CodeQL CLI v 2.22.1 or greater
Microsoft Windows Drivers CodeQL Query Pack version 1.6.0 or greater
Driver source code

Getting Started

To analyze your driver using the updated static analysis checks:

Install the CodeQL CLI and Microsoft Windows Driver CodeQL Query Pack according to this installation guide
Build your CodeQL database
Analyze your CodeQL database using updated query suites
Review and address any issues flagged by the analysis to ensure compliance with WHCP certification requirements.

Early adoption will ensure a smoother Windows driver certification process and improve the overall quality and security of the Windows hardware ecosystem.

For questions or support, please contact your Microsoft representative or create a GitHub repo issue.

Building Windows Driver Projects with CI and CD

prashantchahar — Sat, 15 Feb 2025 05:23:24 GMT

Prerequisites

Before diving into the process, ensure you have the following prerequisites:

For local devbox scenarios

Windows 11 system

Visual Studio 2022 with C++ workload installed and other components, see https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk

For github

A repository with windows driver projects

Using WDK NuGet Packages

WDK NuGet packages are latest edition to the packaging technology provided by Microsoft. Read more about that in this blog Here's a quick summary on how to get started with them:

Finding the Latest WDK NuGet Packages

To find the latest version of WDK NuGet packages, visit nuget.org and search for "Microsoft.Windows.WDK". Note the latest version number for use in your projects.

Challenges with Native C++ Projects

NuGet packages were primarily designed for .NET projects, and the PackageReference feature is not supported with native C++ projects. This can lead to issues when maintaining multiple projects in a source repository like GitHub, as updating NuGet versions would require editing every project file that references the NuGet package.

Solving the Problem with Directory.Build.props

The GitHub repository https://github.com/microsoft/Windows-driver-samples presents a solution to this problem. By using a Directory.Build.props file at the root directory level, which MSBuild imports by default, you can centralize the NuGet package references.

Sample `Directory.Build.props`:

</Project>

This file points to the location of the NuGet packages inside the packages folder at the root.

We still need to use the packages.config file, which will contain the NuGet packages' IDs and versions e.g.

<?xml version="1.0" encoding="utf-8"?>

</packages>

This file will help restore the packages on disk using the command:

nuget restore .\packages.config -PackagesDirectory .\packages\

Building the Projects Locally

Add a packages.config file to the root directory and provide the list of NuGets required for building the projects. For example to build x64 driver you will need x64 version of SDK and WDK NuGets, take a hint from the example above.

Add a Directory.Build.props file to the root directory and the content similar to the sample provided above.

To build the driver project you need to do the following later which we will convert to a github action

Using the Visual Studio Developer Command Prompt, restore the packages using: nuget restore .\packages.config -PackagesDirectory .\packages\
msbuild /t:build path\to\your\project.vcxproj This command will build the project with the restored NuGets.

Setting Up Continuous Integration with GitHub Actions

To automate the build process with every pull request, we can create a GitHub Action in our repository. Here’s a step-by-step guide:

Creating a GitHub Action for CI

In your GitHub repository, navigate to the `.github/workflows` directory. If it doesn’t exist, create it.
Create a new file, e.g., `ci.yml`.

Example content of `ci.yml`:

yaml

name: CI Build

on:

pull_request:

branches:

- main

jobs:

build:

runs-on: windows-latest

steps:

- name: Checkout code

uses: actions/checkout@v2

- name: Setup NuGet

uses: NuGet/setup-nuget@v1

- name: Restore NuGet packages

run: nuget restore .\packages.config -PackagesDirectory .\packages\

- name: Build solution

run: msbuild /t:build path\to\your\solution.sln

This GitHub Action will:

Trigger on every pull request to the main branch

Checkout the code

Setup NuGet

Restore NuGet packages

Build the solution

Conclusion

By following this guide, you can efficiently manage and build your Windows driver projects using WDK NuGet packages and automate the process with GitHub Actions for CI. This setup not only simplifies dependency management but also ensures a consistent build process across different environments and development stages.

Building Drivers for Previous OS Releases Using the Latest Windows Driver Kit (WDK)

prashantchahar — Thu, 14 Aug 2025 23:58:39 GMT

The Windows Driver Kit (WDK) is an essential tool for driver developers, providing the necessary headers, libraries, and tools to build drivers for Windows. With each major OS release, the WDK is updated to include the latest Driver Model DDIs and APIs that support the latest innovations across device classes and fixes for previously released OS versions. This means that with the latest WDK, developers can build drivers not only for the current OS version but also for down-level supported OSes. One of the key advantages of this approach is that it allows developers to build drivers for both current and previous OS releases while benefiting from the latest security and other updates, enhancements and fixes.

Previously it had been a pain point for the driver community to upgrade to the latest WDKs and to manage Side by Side installations as they wanted to build for specific versions. With WDK NuGets it is now seamless to get the headers, libs and build tools for both SDK and WDK and to upgrade to newer versions directly from the Visual Studio, follow https://learn.microsoft.com/en-us/windows-hardware/drivers/install-the-wdk-using-nuget for more information.

Building a driver that targets a down-level supported OS version is straightforward and fully supported by Microsoft. Developers need to set the _NT_TARGET_VERSION property corresponding to the target OS, also provided in appendix A. This property can be set in Visual Studio or directly in the vcxproj file. By default this property is set to target the latest version of the OS so if a driver needs to target latest OS version there is no need to change this property.

Setting _NT_TARGET_VERSION in Visual Studio with WDK extension

To build drivers for a specific OS version using Visual Studio, follow these steps:

Open your driver project in Visual Studio.
Right-click on the driver project in the Solution Explorer and select "Properties".
Navigate to "Driver Settings" under "Configuration Properties".
Set the _NT_TARGET_VERSION to the desired OS version.

Here's a visual snippet to guide you through the process:

Setting _NT_TARGET_VERSION in the vcxproj File

If you prefer not to use Visual Studio, you can manually set the _NT_TARGET_VERSION in the vcxproj file. This can be done by adding the following line under the appropriate PropertyGroup for the platform and configuration you need to build for:

<_NT_TARGET_VERSION>Desired OS version</_NT_TARGET_VERSION>

</PropertyGroup>

Example

For example, to target Windows 10, version 1903, you would set _NT_TARGET_VERSION to 0x0A00:

<_NT_TARGET_VERSION>0x0A00</_NT_TARGET_VERSION>

</PropertyGroup>

Conclusion

By leveraging the latest WDK, driver developers can ensure their drivers are up-to-date with the latest security patches and improvements in the driver model headers and libs while maintaining compatibility with previous OS versions. Whether using Visual Studio or editing the vcxproj file directly, setting the _NT_TARGET_VERSION is a straightforward process that enhances the flexibility and reliability of driver development. As the development environment evolves with updated APIs, compilers, and linkers, it's an exciting opportunity to ensure that the rebuilt drivers perform optimally. Thorough testing of the drivers will help us adapt to these changes and maintain high standards of functionality and reliability.

Limitations

Microsoft suspended the support for x86 and ARM32 kernel mode components starting Windows 10.0.22000, so latest WDK will not support building x86 and ARM32 kernel mode components.

Microsoft stopped support for building drivers for Windows 7,8 and 8.1 as they are out of support, hence starting Windows 10.0.22621.0 developers can’t use latest WDK to build drivers targeting Windows 7, 8, 8.1.

Appendix A

OS Version	_NT_TARGET_VERSION
Windows 10.0.26100	0xA000010
Windows 10.0.22621	0xA00000C
Windows 10.0.22000	0xA00000B
Windows 10.0.20348	0xA00000A
Windows 10.0.19041	0xA000008
Windows 10.0.18362	0xA000007
Windows 10.0.17763	0xA000006
Windows 10.0.17134	0xA000005
Windows 10.0.16299	0xA000004
Windows 10.0.15063	0xA000003
Windows 10.0.14393	0xA000002
Windows 10.0.10586	0xA000001
Windows 10.0.10240	0x0A00

Redefine Possibilities: The Windows Driver Kit Agility Release is Here!

Paul_Eze — Thu, 10 Oct 2024 20:07:02 GMT

Microsoft is excited to announce the release Windows 11 24H2 WDK update (version 10.0.26100.1591). This release marks the beginning of an agile WDK release workstream, where updated Windows Driver Kits will be made available more frequently. These regular kit updates will enhance the reliability, security, and quality of our hardware ecosystem.

Each new version of the WDK release can be downloaded from the WDK download page. The latest WDK version (N) will supersede the previously released version (N-1), and the download link will always reflect the most current version. The change log for each release can be found here

Users can install and run the newly released WDK on Windows 10 and later versions. Additionally, this kit can be used to build drivers for Windows 10, Windows Server 2016, and all subsequent client and server versions.

WDK NuGet: A new way to develop drivers on Windows

Paul_Eze — Mon, 15 Jul 2024 22:43:20 GMT

We are excited to introduce the WDK NuGet, a new offering that enables developers to build drivers for Windows.

The WDK is the essential tool for developing, testing and deploying drivers on the Windows platform. It provides the headers, libraries, tools and metadata that you need to create drivers for Windows devices.

Previously, the WDK was available as an MSI installer or an ISO file.

The WDK NuGet contains the compiled code, libraries, headers, tools and metadata for driver development. You can easily consume the WDK NuGet package by adding it to your project and then calling its functionality in your project code.

The WDK NuGet offer some advantages over the traditional WDK offerings:

It is smaller in size, which reduces the download and setup time.
It is portable across different machines and environments.
It can be integrated with large CI/CD pipelines and source control systems.
It better support an agile WDK release model, it can be easily updated latest WDK features and fixes.

The WDK NuGet is now publicly available on nuget.org, where you can find the latest and previous versions of the package.

To get started with the WDK NuGet, you need to have Visual Studio 2022 or later installed on your machine. You can then follow the steps in this Microsoft Learn documentation to install the WDK NuGet package and create your first driver project.

We are also working on improving the developer experience while developing their driver projects from Visual Studio by adding WDK as a Visual Studio individual workload. This will make it easier to install and update the WDK NuGet package from the Visual Studio installer.

We hope you enjoy the WDK NuGet package and find it useful for your driver development needs. We welcome your feedback and suggestions on how to make it better.