Introduction to the Windows Driver FoundationUpdated: October 13, 2006
This paper provides information about the Windows Driver Foundation (WDF) for the Microsoft Windows family of operating systems. It describes limitations of the earlier driver models that have led to the development of WDF, explains how WDF solves these problems, and introduces the fundamental components of WDF. This information applies for the following operating systems:
On This Page
IntroductionThe Microsoft Windows operating system supports thousands of devices. More than 30,000 drivers have been released; 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 limitations. Earlier Windows Driver ModelsEarlier driver modes include 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 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 10 miniport models. Limitations of Earlier Driver ModelsAlthough the WDM and 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 2,000 lines of tricky code. Many driver developers find the device-driver interfaces (DDIs) for power management, Plug and Play, synchronization, and asynchronous I/O 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 Microsoft's ability 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 10 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:
Earlier 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 testing and verification technologies 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. However, because of the wide differences among the driver models, each model requires a different set of rules. Developing these tools to support the existing driver models thus involves duplicated effort. Design Goals for the Next-Generation Windows Driver ModelMaking 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 major 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 can 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 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 drivers can run in a protected environment. When drivers run in such an environment, the operating system can recover from driver errors without crashing. Windows Driver FoundationThe Windows Driver Foundation (WDF) is Microsoft's strategy for addressing these design goals. WDF is a conceptual driver model that includes several components:
WDF provides an object-oriented, event-driven model in which:
This conceptual model enables driver developers to write a simple driver quickly and to increase the complexity of the driver in small increments by adding 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, Microsoft plans to start using WDF in Windows Vista. Kernel-Mode Driver FrameworkThe kernel-mode driver framework (KMDF) implements the fundamental features required for kernel-mode drivers, including complete support for 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 KMDF release includes numerous sample drivers for a variety of devices. The kernel-mode driver framework is not part of the operating system kernel. Instead, it is a separate run-time library that supports versioning and side-by-side usage. 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. 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. User-Mode Driver FrameworkThe user-mode driver framework (UMDF) is a general-purpose driver platform that implements a subset of the kernel-mode framework functionality, including support for Plug and Play, power management, and asynchronous I/O. Using UMDF, developers can create drivers for protocol- and serial-bus-based devices. Such drivers are standard Plug and Play drivers that the system finds and installs in the same way as kernel-mode Plug and Play drivers. User mode provides a simpler operating environment than kernel mode. User-mode drivers have access only to their own address space, not to the system address space, and they use the Win32 API instead of calling kernel-mode functions. As a result, user-mode drivers contribute to greater system stability and security. However, user-mode drivers are subject to certain limitations. They cannot directly manipulate hardware, so they cannot perform DMA or use interrupts. In addition, they cannot have kernel-mode clients or extremely tight timing requirements. Driver Verification ToolsTwo rule-based static analysis tools, PREfast and SDV, will support both the kernel-mode and user-mode frameworks. These tools also work on non-framework drivers, so they can be used to troubleshoot existing drivers. 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 raises IRQL to DISPATCH_LEVEL. However, if function A acquires the spin lock, 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. 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, for example, calling 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. SDV can find some errors that PREfast cannot, such as the IRQL error that is described in the preceding paragraph. Because SDV explores all source code paths in a driver according to a user-selected set of rules, its running time and resource requirements depend on the size of the driver and the complexity of the rule set. A run time of 10-30 minutes is typical for a small driver. For a large driver, verifying many complex rules can take several hours. 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. WDF Release ProgramBoth KMDF and UMDF are found in the Windows Driver Kit (WDK). Resources
|
|
- Related developer sites
- Microsoft Connect
- OSR Online
- Windows Phone
- Other Windows sites
- Enterprise
- Small business
- Students
- Home users
- Essentials
- Recently published
- Debugging
- Samples
- Hardware dashboard
- Support
- Forums
- More support resources
© 2013 Microsoft. All rights reserved.
