Introduction to the Windows Driver Foundation
Microsoft Corporation
June 2004
The current version of this information is maintained at https://www.microsoft.com/whdc/driver/wdf/wdf-intro.mspx.
Applies to:
Microsoft Windows 2000
Microsoft Windows XP
Microsoft Windows Server 2003
Microsoft Windows codenamed "Longhorn"
Summary: This paper provides preliminary information about the Windows Driver Foundation (WDF) for the Microsoft Windows family of operating systems. It describes limitations of the current driver models that have led to the development of WDF, explains how WDF solves these problems, and introduces the fundamental components of WDF. (8 printed pages)
Contents
Introduction
Limitations of the Current Driver Models
Design Goals for the Next-Generation Windows Driver Model
Windows Driver Foundation
Kernel-Mode Driver Framework
User-Mode Driver Framework
Driver Verification Tools
Resources
Introduction
The Microsoft Windows operating system supports thousands of devices. More than 30,000 drivers have been released, and more are introduced daily. Some of these drivers are based on models that were designed more than 10 years ago. Although these models represented the state of the art at the time, today's devices and operating system technologies stretch these outdated designs to their limits.
Microsoft is taking steps to simplify the development of Windows drivers, and to improve driver quality and system reliability. This paper describes the Windows driver models that are currently supported, summarizes their limitations, and introduces the Windows Driver Foundation, which addresses these problems.
Current Windows Driver Models
Windows currently supports the generic Windows Driver Model (WDM), and many device-class specific driver models for common device classes such as storage, networking, and audio. WDM provides a rich set of features, including asynchronous I/O, driver layering, Plug and Play, power management, and Windows Management Instrumentation (WMI).
The device-class specific driver models are typically structured as a port driver written by Microsoft, paired with a miniport driver written by an independent hardware vendor. The port driver does much of the work required for the device class, and the miniport driver supports device-specific characteristics. For example, the Microsoft-supplied small computer system interface (SCSI) port driver handles the fundamental requirements for SCSI devices, so that vendor-supplied SCSI miniport drivers need to support only device-specific features.
As Windows has added support for new device classes, the number of miniport models has grown. At present, Windows supports more than ten miniport models.
Limitations of the Current Driver Models
Although WDM and the device-class specific driver models provide the features required to write powerful, high-performance drivers, software and hardware have evolved, so that by now these models are showing their age. The following limitations, in particular, point to the need for new models.
The generic WDM driver model is low level and complex.
Writing a basic driver requires thousands of lines of code, much of it for common features. For example, supporting Plug and Play and power management requires at least 2000 lines of tricky code.
Many driver developers find the device-driver interfaces (DDIs) for power management, Plug and Play, synchronization, and asynchronous I/O to be complicated and difficult to use. Implementing a full Plug and Play and power management state engine involves support for at least 100 states. Drivers that support multifunction devices are even more complicated.
Device-driver interfaces were not designed for their present purpose and are not versioned.
When the DDIs were designed many years ago, Microsoft did not anticipate third-party driver development. Consequently, the DDIs were exported directly from the operating system kernel. They were designed only for performance, not for security or ease of use. In many cases, the DDIs expose essential operating system data structures directly to drivers, thus limiting the ability of Microsoft to change these structures and increasing the chance that a driver error might crash or corrupt the system.
Without versioning support, drivers for different versions of Windows often require different binaries, or must be written to use only the features available in the oldest version. These limitations increase testing time and support costs.
There are too many miniport models.
Windows currently supports more than ten miniport models. The miniport models were originally intended to simplify driver development, by shielding some operating system requirements and presenting others in a device-specific context. Although the miniport models are typically simpler than the generic WDM model, it is not always clear which model to use and how to implement common features in each model. To write drivers for two different device types (such as NDIS and storage), a developer must understand two different miniport models.
The miniport models have additional disadvantages:
- The miniport models expose common features, such as Plug and Play and power management, in different ways.
- The miniport interfaces typically require updates whenever new features are added to the operating system or new hardware technologies become available. Consequently, the miniport interfaces become outdated frequently.
- Supporting multifunction devices is unreasonably complicated. To support a multifunction device that fits into two different miniport models, a developer might be required to write a WDM bus driver and two miniport drivers, each based on a different driver model.
- The number of miniport driver models results in duplicated testing and documentation efforts.
The current driver models require that most drivers run in kernel mode.
Most drivers that use the WDM and miniport driver models must run in kernel mode. Kernel-mode drivers are treated as part of the operating system and have access to the system virtual address space. Consequently, errors in kernel-mode drivers can cause the system to crash.
User-mode applications, however, do not have access to system structures or to the system virtual address space. The operating system is thus isolated from user-mode driver failures.
Today, many devices do not have interrupts or stringent timing requirements and do not need direct access to hardware registers. The drivers for these devices should be able to run in user mode, where the risk to system reliability is much lower.
The number of driver models makes technologies for testing and verification difficult to develop and use effectively.
Using new static analysis tools such as PREfast and Static Driver Verifier (SDV) can significantly improve driver quality. Such tools verify driver code according to a set of rules, but because of the wide differences among the driver models each model requires a different set of rules. Developing these tools thus involves duplicated effort.
Design Goals for the Next-Generation Windows Driver Model
Making drivers easier to develop, test, and maintain can help hardware vendors to improve the quality of their products, decrease their development time, and lower their costs. To achieve these results, Microsoft has identified several key design goals for the next-generation Windows driver model.
The driver model should be simple and flexible.
A simple, flexible driver model helps developers to produce robust, reliable drivers more easily and quickly. The model should scale well for complex drivers, and must support Plug and Play, power management, synchronization, WMI, driver layering, and asynchronous I/O. In addition, the new model should be flexible enough to accommodate future system innovations.
The driver model should be separate from core operating system components.
The driver model should be a separate, external framework that shields driver developers from the details of the operating system. The model should enable Microsoft to change the operating system without introducing driver incompatibilities, and should isolate driver developers and hardware vendors from incremental changes in each new version or update of the operating system.
The driver model should support versioning and side-by-side support.
The driver model should support versioning, so that a single driver binary will run on any version of the operating system. In addition, the model should provide side-by-side support, the simultaneous use of two or more versions by two or more drivers. Versioning and side-by-side support enable binary compatibility for drivers across different versions of the operating system, thus simplifying testing and installation requirements.
The driver model should be consistent.
The driver model should be consistent across all device classes. A basic set of DDIs should support operating system features that drivers for all devices must support, such as Plug and Play, power management, synchronization, I/O queues, access to the registry, and support for direct memory access (DMA). New features that are common to all device classes will be added to the base set of DDIs.
A consistent model ensures that knowledge acquired while writing a driver for one device class is transferable across device classes, thus reducing the learning curve for driver developers.
The driver model should be extensible.
The driver model should be extensible, and extensions should provide features that are required by one or more specific device classes, but not by every device class.
Extensibility standardizes the common features of each device class, so that driver developers can focus on the unique details of their specific device.
The driver model should allow many drivers to be written in user mode.
Network-connected devices (based on the Universal Plug and Play specification) and some USB devices require third-party support for proprietary protocols. Drivers for these devices should run in user mode. User-mode drivers pose a much lower risk to system stability than kernel-mode drivers.
The driver model should support the use of high-level languages.
Defining rules to describe and verify interfaces is easier if the interfaces can be expressed in high-level object-oriented and type-safe languages. Accurately describing interfaces is critical for creating rule-based code analysis tools.
DDIs should be designed for easy verification and analysis.
The DDIs should be simple and straightforward, to promote the development and use of verification and analysis tools such as PREfast and SDV.
The driver model should enable the future development of driver isolation.
The driver model should enable the development of driver isolation, so that kernel-mode drivers can run in a protected environment. When drivers run in this environment, the operating system can recover from driver errors without crashing.
Windows Driver Foundation
The Windows Driver Foundation (WDF) is the strategy of Microsoft for addressing these design goals. WDF is a conceptual driver model that includes several components:
- Kernel-mode driver framework
- User-mode driver framework
- Driver verification tools
WDF provides an object-oriented, event-driven model in which:
- Objects work as building blocks for the driver. A driver modifies these objects through well-defined interfaces.
- A set of events can affect each type of object. The framework defines default behavior for each event; to support device-specific behavior, the driver includes callback routines that override the defaults.
This conceptual model enables driver developers to write a simple driver quickly, and to increase the complexity of the driver in small increments by including packages that provide additional functionality. WDF is designed to enable driver developers to focus on their hardware and software, not on the operating system.
To make drivers easier to debug and maintain, the framework contains built-in support for verification and event tracing for Windows. Both verification and tracing can be enabled in debug and retail builds.
Microsoft will continue to support existing driver and miniport models such as WDM and NDIS. For new device classes, such as the biometric device class, Microsoft currently plans to start using WDF in the next client version of Windows, codenamed "Longhorn."
Kernel-Mode Driver Framework
The kernel-mode framework implements the fundamental features required for kernel-mode drivers, including complete support of Plug and Play, power management, I/O queues, DMA, WMI, and synchronization, along with specific support for major buses such as USB and IEEE 1394. In addition, it can be extended to support device-class-specific features and requirements in a way that is appropriate to the specific device class.
The kernel-mode driver framework is not part of the operating system kernel. Instead, it is a separate library that supports versioning and side-by-side usage. The kernel-mode driver framework will be supported on Windows 2000 and later releases.
Using the kernel-mode driver framework, writing a bus driver to support a multifunction device is much simpler than using the current WDM model. The driver enumerates its child devices, and lists the properties of each child device. The framework handles all the other common requirements, such as setting up device objects, directing I/O request packets (IRPs) to drivers for the child devices, and so forth. A sample toaster bus driver developed with the kernel-mode driver framework is supplied on the "Windows Driver Foundation May 2004 pre-release" CD in the WinHEC conference materials.
The interfaces in the kernel-mode driver framework are designed to make driver isolation possible in the future. Under driver isolation, a kernel-mode driver runs in a protected environment. If the driver crashes, the system cleans up any resources allocated by the driver and recovers without crashing or halting the system. Implementing driver isolation requires well-designed interfaces that can be readily marshaled and validated across the boundaries of the protected environment.
Current plans for Windows Longhorn call for many in-box drivers to use the kernel-mode framework, including audio, storage, and IEEE 1394.
User-Mode Driver Framework
The user-mode driver framework implements a subset of the kernel-mode framework functionality, including support for Plug and Play, power management, and asynchronous I/O.
Using the user-mode framework, developers can create drivers for network-connected devices and some USB devices, such as portable media players, cameras, and cell phones. Although these drivers run in user mode, they will be standard Plug and Play drivers that the system finds and installs in the same way as kernel-mode Plug and Play drivers.
The user-mode driver framework will be supported on Windows Longhorn.
Driver Verification Tools
Two rule-based static analysis tools, PREfast and Static Driver Verifier, will support both the kernel-mode and user-mode frameworks.
PREfast flags violations of rules and conventions that drivers must follow. It analyzes the driver's code paths at a function level by applying a set of rules to one function at a time, verifying that the code within the function complies. For example, if function A acquires a spin lock and then attempts to call function Z, which must be called at PASSIVE_LEVEL, PREfast will flag this error because acquiring a spin lock raised IRQL to DISPATCH_LEVEL. If, however, function A acquires the spin lock and then calls function M, which can legitimately be called at DISPATCH_LEVEL, and function M then attempts to call function Z, PREfast cannot detect the error. PREfast is available in Windows Server 2003 SP1 and in the Windows DDK on the WinHEC Conference CDs.
SDV is a rule-based tool that has built-in knowledge about Windows internals, and about how drivers should use operating system interfaces. It emulates the operating system's path through the driver, calling, for example, the driver's DriverEntry routine before calling its AddDevice routine. When SDV finds an error, it displays the path through the driver code to the error.
In addition, WDF includes a built-in verifier capability. This feature works in the same way as the Driver Verifier: it sets a flag in the registry that enables verification of the driver.
Resources
Windows Driver Foundation on Windows Hardware and Driver Central, including information about the beta program for WDF