What Is Windows Driver Kit (WDK)?

Windows Driver Kit (WDK) is the toolset that makes Windows driver development possible. But for developers coming to driver projects for the first time, WDK has a steep learning curve. 

This article breaks down what WDK is, what it includes, and when and how to use it.

What is WDK?

The Windows Driver Kit, previously known as the Driver Development Kit, is a Microsoft toolset for developing device drivers. It includes the headers, libraries, templates, code samples, and documentation developers need to work with Windows driver APIs.

WDK integrates with Microsoft Visual Studio and the Windows SDK to form a complete driver development environment that is used throughout the driver development cycle, from writing code to debugging and deployment.

Who uses WDK and why?

Whether you’re a hardware manufacturer, an independent hardware vendor, or a software development company working on a Windows driver, you’ll need to use WDK, as it’s the only kernel-level interface with Windows.

There is no supported alternative for building drivers that pass Windows Hardware Lab Kit (HLK) certification — Microsoft’s mandatory testing program for certifying hardware as compatible with Windows.

Teams that need isolated or repeatable builds can use Enterprise WDK (EWDK) instead — a corporate version of WDK that bundles the build tools, SDK, and WDK into a single ISO that requires no installation and can be version-controlled or distributed across machines. 

Note: EWDK is a command-line only tool: it drops the Visual Studio IDE, which means no driver deployment or in-environment testing.

What are the key components of WDK?

WDK includes everything a development team needs to work on a driver project. In it, you’ll find:

Headers and libraries. WDK provides the C header files and static libraries that define Windows kernel interfaces and driver APIs. The versions of these files and libraries match specific Windows releases, which allows developers to build drivers that target specific operating system versions.

Windows Driver Frameworks (WDF). WDF is the set of driver frameworks on which most modern Windows drivers are built. It has two variants: 

• Kernel-Mode Driver Framework (KMDF) for drivers that need to run in the kernel
• User-Mode Driver Framework (UMDF) for drivers that can run in user space with less risk to system stability 

WDF handles a large portion of the boilerplate driver elements: I/O request processing, device object lifecycle, and synchronization. It helps development teams to focus on device-specific logic.

Build environment and templates. WDK integrates with Visual Studio and provides project templates for common driver types like WDF drivers, USB drivers, and file system filters.

Debugging tools. For debugging tasks, WDK includes:

• WinDbg, which is the most common debugger for Windows kernel and driver development
• WDF-specific debugger extensions for inspecting driver states at a lower level than WinDbg allows

Static analysis and verification tools. WDK comes with Driver Verifier, a runtime tool that stress tests a loaded driver to find errors that only appear in specific execution paths. For static analysis, modern driver development relies on CodeQL, which isn’t included in WDK.

Testing and certification integration. WDK integrates with the Windows HLK, which is used to validate drivers against Microsoft’s certification requirements and ensure compatibility with specific Windows versions.

Sample code. WDK includes reference implementations for common driver patterns across device classes. These serve as starting points and as examples for how Microsoft expects certain driver behaviors to be implemented.

Documentation. The kit comes with documentation covering driver models, DDI reference, setup and installation, and development workflows. However, Microsoft encourages developers to use Microsoft Learn as their definitive source of up-to-date information.

Deployment and packaging tools. WDK includes tooling for creating and validating driver packages (INF files), preparing them for installation, and integrating with Windows driver signing workflows.

Using WDK for driver development

Microsoft documentation describes in detail how to use Windows Driver Kit. The steps seem rather simple: install Visual Studio, a compatible version of Windows SDK, and WDK, then configure driver testing infrastructure. 

But while this process seems straightforward, there are several hidden challenges:

• Version matching. Driver development is sensitive to toolchain mismatches. The build number of the SDK and WDK installations must match exactly. The safest approach is to download both from the official WDK page at the same time, as the versions on this page are kept in sync.
• Certification and verification. Teams preparing drivers for public distribution or Microsoft certification use WDK alongside HLK. It runs automated compatibility tests required for the Windows Hardware Compatibility Program. They also have to use Driver Verifier to validate driver behavior under stress conditions before submission.

Develop custom Windows drivers with Apriorit

Developing drivers with WDK requires a steep learning curve, even for seasoned developers. They must learn how all the tools inside WDK work, how they interact with each other, and which versions to choose for their target environment.

Apriorit provides you with skilled engineers who have already mastered WDK as well as driver development for Linux, macOS, and cross-platform systems. They can help you with:

✅ Developing custom drivers. Whether you’re building embedded systems, IoT devices, robotics elements, or virtual hardware, Apriorit engineers will tailor your drivers to your hardware capabilities.

✅ Analyzing, improving, and maintaining existing drivers. Need to improve the security or compatibility of an outdated driver? Our team will bring it up to modern standards without complete redevelopment (if possible).

✅ Preparing Windows drivers for WHQL testing. While we can’t pass WHQL testing for you, we can test and improve your driver to ensure it gets a WHQL signature.