In Windows 2000, how does one use the driver Checker to debug the device driver?

Summary

The driver checker package in Windows 2000 can improve stability and reliability, and you can use this tool to debug driver problems. In Windows 2000, kernel-mode components can cause system crashes or system faults and result in incorrect writing to drivers, such as early versions of a Windows Driver Model (WDM) driver. This article explains how to use the driver Checker to isolate and debug a driver in the system.

You can add a registry key and restart your computer to use the driver checker. You don't need to make any other changes to start analyzing the driver of your system. Note: You can activate the driver checker in the retail and checked versions of Windows 2000. The driver validator provides the following performance (you can activate or disable these performance in the registry ). The buffer pool allocation attempts to allocate all the buffer pools of a driver from a special buffer pool. The driver is isolated and restricted by No Access permissions, and cannot be allocated to other system shared buffer pools. This performance determines whether a driver can allocate more resources to the shared buffer pool, resulting in crashes and system instability. When you activate this performance and the target computer has enough physical and virtual memory, the allocation of all drivers is automatically redirected to the special buffer pool.

Extreme Memory Pressure

Extreme Memory Pressure is set on a specific drive without affecting other drives (regardless of the system Memory size ). By indicating memory management, You can invalidate the callable code and data of all drivers, as well as the system callable buffer pool, code, and data. This allows you to find a drive that mistakenly keeps the spin lock or improves IRQL and can then access the code or data on the callable page. You can use Extreme Memory Pressure to detect intermittent problems and isolate them. Parameter verification all spin locks, IRQL and Driver Buffer Pool allocation calls automatically receive Parameter validation. This means that verification can ensure the security of the following situations:

An IRQL increase is actually an IRQL increase (the current IRQL is lower than the target IRQL ).
A lower IRQL is a lower IRQL.
Double release of a spin lock.
Collection/release of spin locks to execute IRQL as appropriate. Page buffer pool allocation/release to properly execute IRQL (APC_LEVEL and below) Non-page buffer pool allocation/release to properly execute IRQL (DISPATCH_LEVEL and below ). For these application interfaces (APIS), random (uninitialized) values are not specified. Pool Allocation Injection failure (Pool Allocation Injection Failures) is marked by the driver as MUST_SUCCEED. The Allocation of the buffer Pool may be random and fail to properly handle the case where the memory is small.

Released Buffer Pool

Check all released buffer pools to ensure that all unused timers in the buffer pool are cleared, which can cause system crashes that are difficult to track.

Buffer Pool Leakage Detection

All drive buffer pool allocations are automatically tracked. When the drive is detached, if a allocation is not released, a bug check starts. Then you can use it! Verifier 3 kernel debugger command to display all unreleased distributions. You can also use this command before detaching to view the explicit address distribution of the drive in a timely manner. Detaching a drive

Execute the uninstall detection of the driver to capture the detached driver and clear the resources used (it increases the possibility of a system bug detection shortly after the driver is uninstalled ). Resources not deleted by the driver include the backup list, delayed process calling (DPC), working threads, queues, clock, and other resources. If you use the validator tool or the VerifyDriverLevel registry key to open the flag of the input/output validator, some input/output manager verifications are enabled. This includes the following items:

All IRPS allocated through IoAllocateIrp are allocated from the special buffer pool.
Check IoCallDriver, IoCompleteRequest, and IoFreeIrp to get the driver error information.
Use the code DRIVER_VERIFIER_IOMANAGER_VIOLATION (0xC9) to check if all input and output validators fail. The only requirement is that you have to install Windows 2000.
Enabling Driver Verifier (activate Driver checker)

You can use verifier.exe or edit the Registry to activate the driver checker. Use verifier.exethis is the first option to activate the driver checker (verifier.exe exists in every copy of Windows2000 and can be installed in the System32 folder ). Verifier.exe has command line and graphical user interface (GUI), so you can specify the driver and authenticate the level as appropriate. You can also pay attention to the real-time statistical table of the driver checker. For more information, see the driver verification manager section in this article.

Edit Registry

Warning incorrect use of Registry Editor can cause serious problems that may require you to reinstall your operating system. Microsoft cannot ensure that all problems caused by incorrect use of Registry Editor are solved. Using the Registry Editor is risky. For details about how to Edit registration table Information, refer to "Changing Keys and Values" in registration table (regedit.exe) to help define "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in regedt32.exe. Note that you should back up your registry before you edit it. If you are running Windows NT or Windows 2000, you should also upgrade your Emergency Repair Disk (ERD ). To activate the driver checker by editing the registry, follow these steps:

Open Registry Editor (Regedt32)
Find the following registry key: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory ManagementVerifyDrivers
Edit the REG_SZ key. Set the REG_SZ key to the name of the driver you want to test. You can specify multiple drivers, but you should use one driver to ensure that available system resources are not exhausted too early. Too early resource depletion is not caused by system instability, but may cause some driver tests to be bypassed.
The following is an example of a REG_SZ key value:

Ntfs. sys
Win32k. sys ftdisk. sys
*. Sys

You can specify the driver verification level in the following registry key. HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSessionManagerMemory ManagementVerifyDriverLevel ):

0x01: Try to satisfy all allocation of the special buffer pool.
0x02: for access to Page code and data, apply the memory pressure to this driver to make IRQL effective.
0x04: various buffer pool allocation requests fail randomly. This behavior is feasible after the system starts and reaches a point that considers the problem as a reasonable situation.
0x08: Activate the buffer pool allocation trail. Each allocation must be released before the driver is detached or the system executes a bug check.
0x10: Activate the input/output checker.
Note: If this key does not exist or you have not specified a driver level, the default value is 3. Debugging driver checker exceptions in the kernel! The verifiercommand and verifier.exe tools display the current driver checker configuration and real-time statistics table. An exception in all drivers will cause a bug check. The most common (though not all are necessary) are as follows:

IRQL_NOT_LESS_OR_EQUAL 0xA
PAGE_FAULT_IN_NONPAGED_AREA 0x50
PAGE_FAULT_IN_NONPAGED_AREA 0x50 ATTEMPTED_WRITE_TO_READONLY_MEMORY 0xBE
Special_pool_detected_memory_0000uption 0xC1
DRIVER_VERIFIER_DETECTED_VIOLATION 0xC4 DRIVER_CAUGHT_MODIFYING_FREED_POOL
0xC6 TIMER_OR_DPC_INVALID 0xC7 DRIVER_VERIFIER_IOMANAGER_VIOLATION 0xC9

Driver checker and graphics driver

Windows 2000 kernel-mode graphics drivers (such as printers and display drivers DLLs) cannot directly call the buffer pool entry point. Instead, buffer pool allocation uses the graphical Device Driver Interface (DDI) callback Win32k. sys. For example, EngAllocMem is a callback function explicitly called by the graphics driver to allocate the buffer pool memory. Similarly, other specific callback functions, such as EngCreatePalette and EngCreateBitmap, return the buffer pool memory. In order to provide automatic testing of the same type for image drivers, some driver checker functions are integrated with Win32k. sys. However, because graphics drivers are more restrictive than drivers in other kernel modes, they need a subset of driver checker functionality. Obviously, IRQL checks and input/output validation are not required. Other functions, that is, the use of special buffer pool, random failure of buffer pool allocation and buffer pool tracking, are supported to change the location of DDI callback information in different graphics. Supports random failure locations for the following DDI callback functions: EngAllocMem
EngAllocUserMem
EngCreateBitmap
EngCreateDeviceSurface
EngCreateDeviceBitmap
EngCreatePalette
EngCreateClip
EngCreatePath
EngCreateWnd
EngCreateDriverObj
BRUSHOBJ_pvAllocRbrush
CLIPOBJ_ppoGetPath

In addition, special buffer pool usage and buffer pool tracking are supported to be suitable for EngAllocMem. Activating the driver checker for a graphics driver is the same as activating other drivers (for additional information, see the "Activate driver checker" section in this article ). For example, the unsupported flag of the IRQL check is ignored. In addition, you can use the gdikdx. verifier kernel debugger command to detect the current driver checker status and buffer trace of the graphic driver.

Note: You should use the random allocation failure setting for the full test. This setting causes an error message. Therefore, you should not use this setting to check whether the execution of the graphic driver is correct through validation testing (for example, by comparing the graphic driver output to a reference image ).

Driver verification manager (verifier.exe)
The driver checker tool (verifier.exe) is used to create and modify driver checker settings. You can also collect the preferred method for the driver checker statistical table. In every Windows 2000 installation process, verifier.exe is located in the % WinDir % System32 folder.

Driver status

The driver status property page provides you with an image of the status of the current driver checker. You can see what driver is being tested. The status may be one of the following:

Loaded: the driver is now Loaded and tested.
Unloaded: the driver is not loaded now, but it is loaded at least once because you restart the computer.
Never Loaded: the driver is Never Loaded. This status indicates that the driver's image file is damaged or you have specified a name lost from the system.
You can click the header to rename the category according to the driver name or status. In the upper-right area of the dialog box, you can view the current type of confirmation.