Device Path Exerciser Overview
Device Path Exerciser consists of a set of tests, each of which concentrates on a different entry point or I/O interface. These tests are designed to assess the robustness of a driver, not its functionality.
During a test, Device Path Exerciser typically sends hundreds of thousands of similar calls to the driver in rapid succession. The calls include varying data access methods, valid and invalid buffer lengths and addresses and permutations of the function parameters, including spaces, strings, and characters that might be misinterpreted by a flawed parsing or error-handling routine.
Introduction to Device Path Exerciser Testing
The Device Path Exerciser test identifies drivers that do not correctly handle the following calls:
Unexpected I/O requests to the driver, such as file system query requests directed to a sound card.
Query requests with buffers that are too small to contain all the data to be returned.
IOCTL/FSCTL requests with missing buffers, buffers that are too small, or buffers containing meaningless information.
IOCTL/FSCTL requests with direct I/O or neither I/O data access in which the data is changing asynchronously.
IOCTL/FSCTL requests with invalid pointers for requests using neither I/O.
IOCTL/FSCTL requests and fast path query requests in which the mapping of the user buffer changes asynchronously, causing the pages to become unreadable.
Relative open operations with arbitrary or hard-to-parse file names and open operations to fictitious device objects.
The Device Path Exerciser tests verify that calls sent to the device are completed correctly and do not cause system crashes, system memory pool corruption, or memory leaks.
The Device Path Exerciser tests send tens of thousands of device control requests to a driver during the course of testing. A device driver is expected to handle each of these requests properly, either by returning valid data or by rejecting the request.
Memory Leak Monitoring
After each test, Device Path Exerciser requests information about the memory that the driver has allocated from system paged and nonpaged memory pools and from the lookaside list.
If the amount of memory that the driver allocated from any of these resources increases, Device Path Exerciser repeats the test and checks the resources again. If the increased memory use is not related to the call, then the amount of memory allocated should not change as a result of the second call. However, if the driver is causing a pool leak by allocating, but not freeing, memory, Device Path Exerciser will detect the leak, especially after repeated calls.
For calls that use buffered I/O, the program tracks the number of exceptions that the operating system has dispatched. If the number of exceptions increases, the operation is repeated.
Exception dispatching might indicate an internal error that is being handled by an exception handler, thereby hiding a parameter validation error or a handle validation error. In this case, you can run Device Path Exerciser with the /n parameter, which maps the zero hardware page and fills it with null values. As a result, when the driver dereferences a null pointer without first validating the pointer, it will return meaningless information, instead of raising an exception.
If Device Path Exerciser finds a change in the amount of allocated memory or a change in the exception count, it records a message in the Diags.log file.
After a test completes, search the Diags.log file for messages that include the words "exception," "lookaside," and "pool." These might help you detect a problem, even if the memory leak does not crash the system. Device Path Exerciser also records the pool tag of the allocations that it was tracking. Then, you can use PoolMon to track allocations with this tag.
Using Driver Verifier
Before starting Device Path Exerciser, start Driver Verifier and configure it to test the driver that you are testing in Device Path Exerciser. Device Path Exerciser is most often run while using Driver Verifier to monitor the driver. This produces a thorough profile of the driver's behavior during the stress of the Device Path Exerciser tests.
If you are running an Active Control Test on a computer running Windows Server 2003 or later, enable the IRP Logging feature in Driver Verifier. This feature uses WMI software tracing to record the IRPs that the driver processes while Driver Verifier is monitoring. Then, start the DC2WMIParser tool (Dc2wmiparser.exe), a tool that parses the IRP log and creates the input file for the Active Control Test.
Restarting Device Path Exerciser
Device Path Exerciser is often run repeatedly. If a Device Path Exerciser test causes a driver to crash the system, you can fix the error that caused the crash and then perform the test again, or skip the test that caused the crash and perform the other Device Path Exerciser tests.
In either case, the procedure will be similar. Device Path Exerciser does not retain any commands from previous test sessions and it always begins by using the same default values. Use one of the following procedures.
To rerun the same test, use the same command line. Device Path Exerciser records the command line in the Dc2.log file.
If you are running the Random Test or a test that includes the Random Test, such as the HCT Test, use the /rs parameter to set the seed number for the random routine to the seed number used in the original test. The seed number is recorded in the Dc2.log file.
To skip tests that caused a system crash, add the /c parameter to the command. The /c parameter skips all tests listed in the Crash.log file, and the last test in the Crashn.log file.
To skip tests that Device Path Exerciser performed during a previous test session, add the /r parameter. This parameter skips all tests listed in the Crashn.log file.
Review the contents of the Crash.log and Crashn.log files before you restart Device Path Exerciser. These files are cumulative and might contain tests that were performed on other drivers or devices.
Send comments about this topic to Microsoft
Build date: 9/28/2012