Developing Drivers with the Windows Driver Foundation (Pro Developer)
Detecting and evaluating errors in Windows drivers can be challenging, even with the advances that WDF provides. Kernel-mode drivers are asynchronous and massively reentrant, and each driver must follow many complex rules to correctly use hundreds of WDM and KMDF DDI functions. In addition, driver testing is complicated because:
-
You cannot directly observe an error in the interaction between the driver and Windows itself.
-
A driver that works correctly most of the time can have subtle errors that occur only in exceptional situations.
-
If a driver violates implicit usage rules in a way that causes the driver to behave improperly or crash the system, detecting the root cause of that error can be very difficult.
SDV enhances your ability to observe errors when testing drivers by monitoring the driver's compliance with rules for KMDF and WDM that define how device drivers should use the related DDI functions.
SDV is designed to be run near the end of the development cycle on drivers that have been built and are approaching the test phase of development. SDV does deeper analysis than PREfast and often finds errors after PREfast errors have been fixed. SDV runs on Windows XP and later versions of Windows, and it supports free and checked build environments for x86 and x64.
| Important | To take advantage of SDV when you develop KMDF drivers, you must use the edition of the WDK provided with Windows Server Longhorn Beta 3 or later. See "Static Driver Verifier" on WHDC for up-to-date information about SDV advances for Windows driver development-online at http://go.microsoft.com/fwlink/?LinkId=80082. |
SDV works with these kinds of drivers SDV works best for smaller drivers that have less than 50K lines of code. SDV can verify drivers that have the following characteristics:
-
Drivers and libraries written in C and contained in source files with a .c file name extension.
-
KMDF or WDM device drivers (that is, function drivers, filter drivers, and bus drivers) and file system filter drivers.
Microsoft Research (MSR) invested several years of work to create an engine that automatically checks that a C-based program correctly uses the interfaces to an external library. This project-called SLAM at MSR-resulted in the powerful analysis engine that was incorporated into SDV.
The MSR team describes the choices they made in "Providing a Template for Tech Transfer" on the MSR Web site-online at http://research.microsoft.com/slam and http://research.microsoft.com/displayArticle.aspx?id=1338.
Категории