How Windows XP's Device Driver Verifier Works
Date: Jul 6, 2001
Article is provided courtesy of Sams.
Facing the task of upgrading device drivers for even a few PCs can be a time-consuming process marked by trial and error. Looking to further differentiate from Linux and UNIX, Microsoft's Windows XP's Device Verifier makes migration of previous device driver settings and the correct installation of device drivers more predictable. This article by expert Louis Columbus explains how Windows XP handles the process at the architectural level.
Windows XP's second beta shows positive signs of being able to quickly ascertain device driver attributes and migrate device settings to the new operating systems' operation. Microsoft first introduced the Device Driver Verifier during Windows 2000, and has expanded on its functionality in the first two beta releases of Windows XP Professional. The intent of this article is to define how the Device Driver Verifier works, and what the implications are for Windows XP developers and users.
Responding to the problems with memory management on device driver installation and operation, Microsoft has chosen to architect the Device Driver Verifier to do the following:
It replaces the default operating system routines with routines that are specifically developed to catch mistakes.
It makes driver verifier functionality multithreaded, so that several device drivers can be monitored at the same time.
It has the design objective of targeting failures and corruption to device drivers before overall system integrity is affected.
Acting within the kernel mode, it can target specific device drivers for continual checking.
How the Device Driver Verifier Works
At the kernel mode of Windows XP, the Device Driver Verifier monitors device driver installation routines during installation to make sure that their respective system calls don't impede overall system performance. As was discussed in the article on Device Driver Rollback and the broader reliability features of Windows XP, the Device Driver Verifier completes this process of checking the validity and compatibility of drivers transparently to the user. Developing for Windows XP, many companies building device drivers with their applications will most likely opt for checking multiple drivers at once—a feature that is new to Windows XP's development environment.
Microsoft has isolated device drivers from memory used by typical application tasks, specifically by taking driver tasks away from the normal memory heap manager. Allocations of memory for the Driver Verifier and the resultant drivers it works with are driven through an allocation or special pool of memory. Also, to minimize conflicts over virtual addresses, Microsoft has increased the lag time between the use of virtual addresses overall. One of the other key design criteria with the Verifier is its capability to run in low-resource scenarios. Developers for the Windows XP platform, for example, can create simulated low-resource environments in which both random driver allocation and operating system functions fail. This will be especially useful for those companies targeting entry-level applications using the Windows XP Professional and Windows XP Home versions.
Key Is Monitoring IRPs in the System
Operating systems arbitrate which resource will be used during processing of tasks through the use of Interrupt Requests, or IRPs for short. Device Verifier actually monitors all IRPs in the system looking for mistakes in device drivers, including common processing errors and conflicts over IRP assignment. The Driver Verifier, acting within the kernel mode, checks the IRPs being completed; and sees whether incorrect values are being sent, whether the I/O processes between IRPs are correct or not, and most importantly, whether the IRPs for plug-and-play, power and WMI functionality are being completed accurately. Clearly, with the integration of plug-and-play in the kernel mode of Windows 2000 and in Windows XP now as well, the role of IRPs as communication points between kernel mode subsystems in the broader operating environment is accentuated. Figure 1 shows an example of the Windows 2000 kernel and user mode subsystems. The architectural differences to Windows XP are minimal on the plug-and-play in addition to the IRP role definition. What's significantly different is the role the Driver Verifier plays in the overall development of system stability.
){kind=link}
Figure 1 The Windows 2000 kernel and user modes resemble Windows XP.
Intricacies of the Device Verifier
When looking in greater detail at the Device Driver Verifier, there are several features that many developers are looking to include in both their Windows 2000 and Windows XP device drivers. Windows XP Professional's initial driver sets include many of these features, with the device drivers themselves being in beta:
AutoCheck Routines. These checks are always performed on a driver that is being verified, regardless of which options have been selected for the specifics of the device driver command set. If the driver uses memory at an improper IRQ, improperly calls or releases spin locks and memory allocations, improperly switches stacks, or frees a memory pool without first removing timers, Driver Verifier will detect this behavior. When the driver is unloaded, Driver Verifier will check to see that it has properly released its resources.
Definition of Special Memory Pool. When this option is active, Driver Verifier allocates most of the driver's memory requests from a special pool. This special pool is monitored for memory overruns, memory underruns, and memory that is accessed after it is freed.
Forcing IRQ Checking. When this option is active, Driver Verifier places extreme memory pressure on the driver by invalidating pageable code. If the driver attempts to access paged memory at the wrong IRQL or while holding a spin lock, Driver Verifier detects this behavior.
Simulating Low Resource Conditions. When this option is active, Driver Verifier randomly fails pool allocation requests and other resource requests. By injecting these allocation faults into the system, Driver Verifier tests the driver's capability to cope with a low-resource situation.
Tracking Memory Pool Usage. When this option is active, Driver Verifier checks to see if the driver has freed all its memory allocations when it is unloaded. This reveals memory leaks.
Verification of I/O. When this option is active, Driver Verifier allocates the driver's IRPs from a special pool, and monitors the driver's I/O handling. This detects illegal or inconsistent use of I/O routines.
DMA Verification. When this option is active, Driver Verifier monitors the driver's use of DMA routines. It detects improper use of DMA buffers, adapters, and map registers. This is a new development in the Device Verifier, specific to Windows XP only.
Deadlock Detection. When this option is active, Driver Verifier monitors the driver's use of spin locks and requests for multiplexing driver execution requests. It will detect if the driver's code has the potential for causing a deadlock at some point. This feature of the Device Verifier is only in Windows XP today.
SCSI Verification. When this option is active, Driver Verifier will monitor a SCSI driver for improper use of exported SCSI port routines, excessive delays, and improper handling of SCSI requests. Although the use of SCSI devices is pervasive, it's surprising that it wasn't in Windows 2000. Windows XP will be the first operating system to see SCSI verification within a widespread release.
What About System Administrators?
If you're responsible for keeping tens, hundreds, or thousands of PCs up and running, and you're currently evaluating WindowsXP, definitely take the time to work with Verifier from both the command line. The executive Verifier.exe is delivered with both Windows XP Professional and Windows XP Home. As with any executable, you can embed this command in a shellscript so it can be run at startup across a network as well. Keep in mind that Verifier is disabled during safe mode, often initiated during troubleshooting mode or when a system is booted up using the F8 key. By default, Microsoft loads Verifier.exe in the windows/system32 subdirectory. This executable also relies on the ADVAPI32.DLL, a common dynamically linked library used by system-level resources throughout both Windows 2000 and Windows XP.
What Microsoft Needs to Include Before Launch
With Device Verifier now in its second generation and the integration of key performance checkpoints such as SCSI integration and driver testing, there are still several areas that Microsoft has yet to address with Driver Verifier. Here's a short list of the areas that will most likely be completed in the coming months before the Windows XP launch:
Tackling the video driver problem more cleanly. There are the Win16 API-based drivers that Windows XP's Driver Verifier can find when installing XP for the first time, and even the verification process that shows that the driver is accurate and plays well with the other Windows XP components. Yet, the Win32 API-based drivers are a different story, and are not easily recognized and installed by Device Verifier in Windows XP Professional.
.NET and the Win32API dilemma. Still unanswered is the migration within Driver Verifier as to its role in the entire migration from Win32 to .NET API for many device drivers and applications. It remains to be seen how Microsoft will resolve this issue.
Network device driver arbitration. There's been much work dedicated to the development of internally focused programs and executables in the Device Verifier that looks into the specifics on the system itself for device driver failures, but little has been done for arbitrating and solving network device driver problems. Microsoft continues to refine the plug-and-play aspects of Windows XP, so the entire upgrade process can take less than an hour on a workstation and low-end dual processor server. Yet the networking troubleshooting is somewhat absent in more complex configurations. The Device Verifier could actually be used for better troubleshooting of the network drivers, actually testing the validity of connections before installing the device driver itself.
Summary
The Device Verifier shows significant promise in being able to short-circuit common and difficult problems to resolve with device drivers once they are installed. The role of device drivers and their innate capability to use the same resources in completing tasks makes for challenging complex configurations and the support of them. Taking the Device Verifier and making in effect a defined memory pool is a step in the right direction, as is the support of multiple Device Verifier sessions for drivers on the same system.