|
|
|
Memory corruption is a common driver problem. Driver errors can result in crashes long after the errors are made. The most common of these errors is accessing memory that has already been freed, and allocating n bytes and then accessing n+1 bytes.
To detect memory corruption, Driver Verifier can allocate driver memory from a special pool and monitor that pool for incorrect access.
Two alignments of the special pool are available. The Verify End alignment is better at detecting access overruns, and the Verify Start alignment is better at detecting access underruns. (Note that the vast majority of memory corruptions are due to overruns, not underruns.)
When Special Memory Pool is active and Verify End has been selected, each memory allocation requested by the driver is placed on a separate page. The highest possible address that allows the allocation to fit on the page is returned, so that the memory is aligned with the end of the page. The previous portion of the page is written with special patterns. The previous page and the next page are marked inaccessible.
If the driver attempts to access memory after the end of the allocation, Driver Verifier will detect this immediately, and will issue bug check 0xCD. If the driver writes in the memory prior to the beginning of the buffer, this will (presumably) alter the patterns. When the buffer is freed, Driver Verifier will detect the alteration and issue bug check 0xC1.
If the driver reads or writes to the buffer after freeing it, Driver Verifier will issue bug check 0xCC.
When Verify Start is selected, the memory buffer is aligned with the beginning of the page. With this setting, underruns cause an immediate bug check and overruns cause a bug check when the memory is freed. This option is otherwise identical to the Verify End option.
Verify End is the default alignment, as overrun errors are much more common in drivers than underrun errors.
An individual memory allocation can override these settings and choose its alignment by calling ExAllocatePoolWithTagPriority with the Priority parameter set to XxxSpecialPoolOverrun or XxxSpecialPoolUnderrun. (This routine cannot activate or deactivate the special pool, or request the special pool for a memory allocation, which would otherwise be allocated from normal pool. Only the alignment can be controlled from this routine.)
There are two other ways to use the special pool: it can be used for all allocations that are marked with a specific pool tag, or for all allocations whose size is within a specific size range. These uses of special pool are controlled through the Global Flags utility, not Driver Verifier. For details, see Using the Global Flags Utility.
It is permissible to request special pools though Driver Verifier and the Global Flags utility at the same time. In this case, Windows will attempt to use the special pool for all allocations indicated by Driver Verifier and all allocations indicated by the Global Flags utility.
Each allocation from the special pool uses one page of nonpageable memory and two pages of virtual address space. If the pool is exhausted, memory is allocated in the standard way until the special pool becomes available again. Thus, it is not recommended that multiple drivers be verified at the same time if Special Memory Pool is in effect.
A single driver that makes a large number of small memory requests can also deplete this pool. If this is occurring, it may be preferable to assign pool tags to the driver's memory allocations and dedicate the special pool to one pool tag at a time.
The size of the special pool increases with the amount of physical memory on the system; ideally this should be at least 1 Gigabyte (GB). On x86 machines, booting without the /3GB switch is also preferred, as virtual (in addition to physical) space is consumed. Increasing the pagefile minimum/maximum quantities (by a factor of two or three) is also a good idea.
To be sure that all of a driver's allocations are being tested, stressing the driver over long periods of time is recommended.
Statistics relating to pool allocations can be monitored. These can be displayed by the Driver Verifier Manager graphical interface, the verifier.exe command line, or in a log file. See Monitoring Global Counters for details.
If the Pool Allocations Succeeded in Special Pool counter is equal to the Pool Allocations Succeeded counter, then the special pool has been sufficient to cover all memory allocations. If the former counter is lower than the latter, then the special pool has been exhausted at least once.
These counters do not track allocations whose size is one page or larger, since the special pool is not applicable to them.
If Special Memory Pool is enabled, but less than 95% of all pool allocations have been assigned from the special pool, a warning will appear in the Driver Verifier Manager graphical interface. In Windows 2000, this warning will appear on the Driver Status screen. In Windows XP and later, this warning will appear on the Global Counters screen. If this occurs, you should verify a shorter list of drivers, verify individual pools by pool tag, or add more physical memory to your system.
The kernel debugger extension !verifier can also be used to monitor special pool use. It presents similar information to that of Driver Verifier Manager. For information about debugger extensions, see Debugging Tools for NT-Based Operating Systems.
The Special Memory Pool option can be activated for one or more drivers by using the Driver Verifier Manager graphical interface or the verifier.exe command line. This activation will take effect after the next boot. See Selecting Driver Verifier Options for details.
This option can also be turned on and off without an intervening reboot. See Using Volatile Settings for details.
Activating the Special Memory Pool by pool tag or allocation size is done by using the Global Flags utility. This utility is also used to set the Verify Start and Verify End alignments — these alignment settings apply to all special pool allocations.
See Special Memory Pool for Graphics Drivers for details on how this option affects display drivers and kernel-mode printer drivers.