Windows Driver Model (WDM)
Updated: April 15, 2002
Windows driver model (WDM) is a strategy for making driver development simpler. The ultimate goal of WDM is a more robust platform for Microsoft Windows operating systems and better user experiences with new hardware for Windows-based PCs.
WDM provides a common set of services for developers to create drivers that are compatible across Windows operating systems for certain device classes. A WDM driver can be source-code-compatible for Windows?XP, Windows?2000, Windows Millennium Edition (Windows?Me), and Windows?98.
This article provides an orientation to WDM for non-developers. Driver developers should see the Windows DDK for in-depth information about developing WDM and non-WDM drivers for Windows operating systems.
Windows DDK
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
On This Page
Why WDM Is Important
WDM helps developers produce more robust drivers with less effort. Driver developers can gain substantial benefits from studying the WDM model for their device class during early driver development and test planning:
| •
| Developers can write one driver for multiple platforms.
|
| •
| Developers can use one development environment, the latest Windows DDK, which will be released concurrently with the release of Windows?XP.
|
Writing one driver for multiple platforms means that developers can create and manage a single source-code base rather than writing a separate driver for each platform, and this reduces the amount of code that must be tested and debugged.
The WDM strategy is a cornerstone of Microsofts driver quality initiative, which also includes:
| •
| The Windows DDK, which provides build environments, sample code, and documentation for developing WDM drivers.
|
| •
| Test tools, such as Driver Verifier and the Windows Hardware Compatibility Tests, supplied with the Windows DDK, in the operating system, and from the web.
|
| •
| Microsoft Technical Support for driver developers.
|
| •
| Driver signing, which contributes to the stability of the Windows operating system in the field by guarding against the installation of untested device drivers.
|
| •
| Testing of early versions of third-party device drivers through the Microsoft Windows Beta program.
|
| •
| Testing of final versions of third-party device drivers by Windows Hardware Quality Labs (WHQL).
|
How WDM Benefits Developers
WDM development at Microsoft has developed, tested, and released code for each version of the Windows operating system since Windows?95. Microsoft WDM developers:
| •
| Contribute to a development environment that is common across all releases of Windows as listed earlier. A completely common development across all Windows platforms would enable third-party driver developers to create a single driver binary for their device that would run on all versions of Windows.
|
| •
| Write WDM bus drivers. All bus drivers are supplied by Microsoft.
|
| •
| For as many device classes as possible, contribute WDM code that enables a port/miniport driver model. Microsoft builds the port driver as part of the Windows product, and third-party vendors write minidrivers for their particular hardware. Minidrivers use services exported by the Microsoft port driver to perform many of the functions common to a device driver.
|
WDM for Windows?XP, Windows?2000, and Windows?Me
All versions of Microsoft Windows after Windows?95 have implemented WDM, which has continued to evolve for Windows?XP, Windows?2000, and Windows?Me. With a few special-case statements in the code, WDM drivers for supported device classes can be source-code compatible across Windows?XP/Windows?2000 and Windows?98/Me operating systems.
Binary compatibility is possible on processors that are compatible with the Intel Architecture. Achieving a single binary still requires rigorous testing on all versions of all operating systems.
Later operating system releases support WDM features that were not?available in earlier releases. For details about differences between WDM versions, see "Writing Drivers for Multiple Platforms and Operating Systems" in the Beta release of the Windows DDK to be released with?Windows?XP.
WDM Bus and Device Support
Bus Support.
In the context of WDM, a bus is any device to which other physical, logical, or virtual devices are attached. Windows XP contains WDM support for these buses:
| •
| PCI
|
| •
| Dynamic Plug and Play serial I/O buses,
including USB and IEEE 1394
|
| •
| SCSI
|
| •
| NDIS
|
| •
| Remote NDIS (RNDIS)
|
The goals of new RNDIS support are consistent with the WDM strategy:
| •
| Simplify the development experience for network device hardware manufacturers
|
| •
| Reduce the need for device-specific Windows network drivers
|
| •
| Simplify the installation experience for end-users of network devices
|
RNDIS Information for Developers
http://www.microsoft.com/whdc/device/network/NDIS/rmNDIS.mspx
Device Support.
Windows XP contains WDM support for:
| •
| USB device classes, such as the Human Interface Device (HID) class
|
| •
| Cameras/scanners
|
| •
| Video capture over IEEE 1394
|
| •
| Audio
|
| •
| WinModem, for controllerless modems
|
| •
| USB and IEEE 1394 storage devices
|
Layered Driver Architecture
WDM uses a layered approach in which a given device is served by at least two drivers: a bus driver and a function driver. A device might also have filter drivers that add value or modify the behavior of the device. The chain of drivers that serve a device is called a driver stack.
Bus drivers.
A bus driver serves an I/O bus, such as IEEE?1394. In context of WDM, a bus is any device to which other physical, logical, or virtual devices are attached. This includes traditional buses such as SCSI and PCI, as well as parallel ports, serial ports, and i8042 ports.
Microsoft supplies the bus drivers for Windows operating systems. A bus driver provides the following services for third-party driver developers:
| •
| Enumerates the devices on its bus
|
| •
| Responds to Plug and Play and power management I/O requests
|
| •
| Provides device-independent administration for the devices on its bus
|
Function drivers.
A function driver is the main driver for a device and is typically written by the device manufacturer. The primary responsibilities of a function driver are to:
| •
| Provide the operational interface for the device
|
| •
| Handle reads and writes to the device
|
| •
| Manage device power policy
|
Filter drivers.
Filter drivers are an option available to driver writers who must add value to or modify the behavior of a device, a class of devices, or a bus. A filter driver is installed above or below one or more other drivers in a driver stack. A filter driver intercepts requests for a device, a class of devices, or a bus, evaluates these requests, and may modify the content or destination of the request. For example:
| •
| An upper-level filter driver for a USB keyboard might enforce additional security checks.
|
| •
| A lower-level class filter for a mouse device might provide acceleration by performing a non-linear conversion of mouse movement data.
|
Function Drivers Structured as Class Drivers and Minidrivers
Common operations for a class of devices can be implemented in a class driver. Driver developers write a much smaller minidriver that interacts with their hardware and that calls the class driver to do most of the work. Taken together, a class driver and a minidriver serve as the function driver for a device.
| •
| Microsoft-supplied class drivers handle common system tasks, such as Plug and Play and power management, for all devices of a particular class. Class drivers ensure that the operating system handles such tasks consistently, resulting in a more consistent user experience.
|
| •
| Vendor-supplied minidrivers implement hardware-specific operations and call the appropriate class driver to perform the common tasks. The smaller amount of driver code in the minidriver means fewer code paths that can potentially fail and cause a bad experience for the user.
|
If an industry standard exists for a device class, the Microsoft-supplied WDM class driver may be able to handle all the necessary tasks for a device that fully implements the standard, which eliminates the need for a third-party minidriver. For example, the Microsoft-supplied HID class driver is based on the USB HID Class Specification, v1.1, and eliminates the need for a third-party minidriver for many USB keyboards, mice, and game controllers.
Microsoft provides the following WDM class drivers:
| •
| Stream class driver to support kernel-mode streaming of data for video capture, MPEG decoders, audio, DVD, and broadcast architectures
|
| •
| HID class driver to support input devices
|
| •
| USB and IEEE 1394 bus class drivers
|
| •
| Storage protocol support for serial and parallel buses
|
|
Component
| Description
|
Kernel
| Synchronization primitives, performance counters and timers, stall and IRQ control
|
Object Manager
| Object reference counting
|
Executive
| Memory allocations, interlocked operations, list operations
|
I/O Manager
| I/O Request Packet (IRP) handling, device objects, work items, registry access, system state notifications, DMA?and interrupts
|
Memory Manager
| Virtual-to-physical memory mapping, physical memory commitment and locking, driver image memory locking, portable I/O space
|
Process Service
| System thread creation and deletion
|
Run-time Library
| Bulk memory, Unicode, and data type conversions
|
Power Manager
| Power state changes, power IRP handling, device idle detection
|
Plug and Play Subsystem
| Hardware detection and resource allocation, Plug and Play IRP handling, hardware events
|
Windows Management Instrumentation (WMI)
| Support and infrastructure for exposing device measurement and instrumentation data
|
Kernel Streaming
| Support and infrastructure for streaming-data device connections
|
Hardware Abstraction Layer
| Platform abstraction; access and usage for I/O ports and memory-mapped devices
|
Writing WDM Drivers
Any new kernel-mode driver should be a WDM driver, and Windows?XP is the recommended development platform. All WDM drivers must support Plug and Play and power management and can also implement WMI, as documented in the Windows DDK.
In general, it is always better to start driver development on Windows?XP and then migrate support back to other Windows versions. This is true even if driver support for the targeted device does not fit completely within the WDM model.
To write a WDM driver, developers must understand differences among Windows platforms as documented in the latest Windows DDK. Developers should also understand bus- and device-specific issues, and Windows kernel concepts such as:
| •
| Thread-based and interrupt-based scheduling
|
| •
| Synchronization
|
| •
| Device objects and driver objects
|
| •
| I/O theory, including handling IRPs, queuing, and asynchronous I/O
|
| •
| Security
|
| •
| Debugging
|
Differences among Windows platforms are documented in the Windows DDK. Here are some brief examples:
| •
| Driver code generally executes differently on the different Windows platforms; this is because WDM allows for significant architectural differences between Windows?XP/Windows?2000 and Windows?98/Windows?Me. After a driver is working on one platform, it must be thoroughly tested on the other platform, especially with multiprocessor systems.
|
| •
| WDM does not support all types of hardware. For example, separate printer or video drivers must be developed for each platform.
|
| •
| INF files must accommodate differences among platforms. In most cases, a driver can be installed with a single INF file, but will generally require separate sections for Windows?XP/Windows?2000 and Windows?98/Windows?Me.
|
Resources
Windows beta testing
Beta releases of Windows are distributed as part of MSDN Professional Subscriptions:
http://msdn.microsoft.com/ subscriptions/ prodinfo/ overview.asp
Windows DDK
http://www.microsoft.com/whdc/devtools/ddk/default.mspx
Microsoft Technical Support for driver developers
http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS
Debugging tools and resources
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Driver Verifier Preview in Windows?XP
http://www.microsoft.com/whdc/devtools/tools/verifier.mspx
Digital signatures for drivers
http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx
Windows Hardware Quality Labs (WHQL)
http://www.microsoft.com/whdc/whql/default.mspx
News and white papers for developing Windows drivers
http://www.microsoft.com/whdc/driver/default.mspx
Programming the Microsoft Windows Driver Model
Walter Oney (Microsoft Press)
http://mspress.microsoft.com/prod/books/2507.htm
Terms
device object
A kernel-mode object, defined by the I/O Manager, that represents a physical, logical, or virtual device.
HID
Human Interface Devices
IEEE 1394
A high-speed serial bus that provides enhanced PC connectivity for a wide range of devices, including consumer electronics audio/video appliances, storage peripherals, other PCs, and portable devices.
INF file
A file that provides the operating system with information required to install and configure a device.
IRP
I/O Request Packet. A data structure used to send I/O requests between the operating system and device drivers.
kernel mode
The Windows kernel manages the most basic functions of the operating system, such as sharing the processor between different blocks of executing code. Kernel mode allows full, unprotected access to the system. A driver or thread running in kernel mode has access to system memory and hardware.
NDIS
Network Driver Interface Specification
PCI
Peripheral Component Interconnect
SCSI
Small Computer System Interface
USB
Universal Serial Bus
WHQL
Windows Hardware Quality Labs
WMI
Windows Management Instrumentation