Monitor Win2K Kernel-Mode Modules

Driver Verifier quickly smokes out faulty drivers

Your system's been producing blue-screens, and you're trying to figure out what the cause is. You installed that new service pack, and the notes said something about an improved network redirector ... or could that updated NIC driver be causing the problem?

This month, I stray from discussing Microsoft Windows resource kit tools to tell you about a utility that is free but that doesn't come in a resource kit. Driver Verifier is in Windows 2000, in both the Professional and Server incarnations. Despite its name, Driver Verifier isn't just a driver verifier—it tells Win2K to closely monitor and verify any kernel-mode module's behavior on your system. In Driver Verifier, Microsoft has given us a tool that in effect lets us do a quality-assurance check on any or all of the system's low-level parts.

To start the Verifier, click Start, Run, then type Verifier and press Enter to view the Driver Verifier Manager window. Click the Settings tab, and you see a Drivers currently active in the system pane that displays a list of eligible drivers. The listed drivers include some, such as classpnp.sys (Plug and Play—PnP—support), efs.sys (Encrypting File System—EFS), and fastfat.sys (32-bit FAT support), that are more than hardware drivers, though—they're essential parts of the OS.

Stated very simply, all Win2K and Windows NT pieces are either kernel mode or user mode. Kernel-mode modules are generally more powerful (which makes them attractive to developers) but also more capable of accidentally damaging another kernel-mode program's memory areas. Such damage tends to make the program crash and trigger a blue screen, and determining which module committed the damage is difficult. The OS watches user-mode modules more closely than kernel modules: When user-mode modules try to write out of their areas, the OS stops them and wakes up Dr. Watson to tell you.

The beauty of the Verifier is that it basically tells the OS to watch a given driver or group of kernel-mode pieces far more closely, almost as if they were user-mode pieces. Point the Verifier at a module, and the Verifier will watch how the module calls the OS and will check for nonsensical or illegal memory requests and API calls. The Verifier also will examine the module's memory upon driver unload, looking for leftover but unresolved pending actions, such as unfinished I/O operations.

Select the Special pool check box in the Verification type pane, and the OS will allocate the driver's memory in a location that is surrounded by unused memory areas that are marked "nobody reads, nobody writes." So, if the driver strays out of its assigned memory area, Win2K will immediately detect the problem and force a blue screen, and the incriminating evidence will point straight at the bad kernel piece.

If you select Pool tracking, Verifier will watch for memory that the kernel module allocated but never deallocated, a dreaded condition known as memory leak. Pool tracking smokes out the leaking module and forces a blue screen. (Too bad this option doesn't work for user-mode applications, some of which are among the worst leakers.) I also recommend selecting Force IRQL checking, which monitors for behaviors in which an application might try to access pageable memory areas (i.e., areas marked to be moved to the pagefile and that thus are no longer trustworthy), another source of mysterious errors. You probably shouldn't select the Low resources simulation option, which randomly reports out-of-memory conditions to the kernel application. The option is a good test, but it really slows down the system, and well-built kernel applications should be able to handle low-memory conditions. However, you should select I/O verification and set it to level 2. This setting specifically identifies I/O violations; for example, the blue screen might say BugCheck 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION).

Finally, after you enter or change Verifier settings, you need to reboot. For more details about the Verifier, see Mark Russinovich, NT Internals, "Inside Win2K Reliability Enhancements, Part 3," October 1999.

Driver Verifier comes with a price: It will slow down your system a bit, and the more drivers you watch, the slower the system runs. But Verifier's ability to identify a problematic kernel module lets you check out a new server or new system software before you install it on the network. Isolate the new server or software—quarantine it, if you will—and run Verifier for a few days. Its deliberate blue screens might save you from unexpected ones later.

—Mark Minasi