Upravit

Sdílet prostřednictvím


IRP Logging

The IRP Logging feature of Driver Verifier monitors a driver's use of IRPs and makes a record of IRP usage. This record is stored as WMI information.

The Windows Driver Kit (WDK) includes the tool DC2WMIParser (dc2wmiparser.exe) that can convert this WMI record to a text file.

This Driver Verifier option is only available in Windows Server 2003 and later.

The WMI Record

The WMI record will not include more than twenty IRPs for each device. Once the twenty-first IRP is recorded, the first IRP record is replaced. So if the record lists twenty IRPs, these are always the most recent twenty, but there is no way to know which of these is the most recent one.

Since the WMI record is stored in memory, it will be erased when the computer is rebooted. Therefore, use DC2WMIParser to save this information to a file.

If you use the /t option, DC2WMIParser will run continuously for the specified duration. In this situation, the record can include more than twenty IRPs per device (up to twenty IRPs in each sampling period).

Activating This Option

You can activate the IRP Logging feature for one or more drivers by using Driver Verifier Manager or the Verifier.exe command line.

To activate the IRP Logging feature, you must also activate I/O Verification.

  • At the command line

    At the command line, the IRP Logging option is represented by 0x400 (Bit 10).

    To activate IRP Logging, use a flag value of 0x410 or add 0x410 to the flag value. This value activates I/O Verification (0x10) and IRP Logging (0x400). For example:

    verifier /flags 0x410 /driver MyDriver.sys
    

    The feature will be active after the next boot.

    On Windows Vista and later versions of Windows, you can also activate and deactivate IRP Logging without rebooting the computer by adding the /volatile parameter to the command. For example:

    verifier /volatile /flags 0x410 /adddriver MyDriver.sys
    

    This setting is effective immediately, but is lost when you shut down or reboot the computer. For details, see Using Volatile Settings.

  • Using Driver Verifier Manager

    1. Start Driver Verifier Manager. Type Verifier in a Command Prompt window.
    2. Select Create custom settings (for code developers) and then click Next.
    3. Select Select individual settings from a full list.
    4. Select (check) IRP Logging and I/O Verification.

DC2WMIParser

DC2WMIParser is a tool that collects the WMI IRP records created by Driver Verifier and converts this log to a text file.

The DC2WMIParser syntax is as follows:

dc2wmiparser [/f File] [/t Time]

The parameters have the following meanings:

/fFile
Specifies the full path and filename of the log file to be written. Relative paths will be taken relative to the current directory. If this is omitted, the file name dc2verifier.act in the current directory will be used.

/tTime
Specifies the length of time, in minutes, that DC2WMIParser will continue to run. If Time equals zero, DC2WMIParser will record all the WMI IRP information that has already been stored by Driver Verifier and then exit. If Time is set to a positive value, DC2WMIParser will continue to run for the specified length of time, storing new information as it arrives. The default is zero.

Format of DC2WMIParser Log Files

The file generated by DC2WMIParser is an ASCII text file.

The first line of this file contains a decimal number that represents the number of devices logged in the file.

After the first line, the file is divided into sections; each section describes one device.

For each device the format is:

  • On a single line: The device name.

  • On a single line: A decimal number specifying how many device types and functions are targeted to this device.

  • On one line for each device type and function: Three hexadecimal numbers, separated by commas. These represent the device type, and the lowest and highest functions that were recorded in this record.

  • In one group of lines for each device type and function:

    • A single line with a decimal number specifying the count of IOCTLs for the current device type.
    • One line for each IOCTL. Each of these lines contains six hexadecimal numbers separated by commas. These specify the device type, the function, the method, the access, the length of the input buffer, and the length of the output buffer.

Here is a sample DC2WMIParser log file. In an actual file there will not be any spaces, comments, or blank lines, but these have been added to this example to make it more clear.

2           There are two devices described by this log file.

The first device begins here:

  DP(1)0x7e00-0x21dbda400+3   Device name of the first device
  2                           Number of device type IOCTLs targeted at this device

    7,12,12                     First targeted device: device type 7, low function 12, high function 12
    2d,420,420                  Second targeted device: device type 2d, low function 420, high function 420

    1                           Number of IOCTLs for first targeted  device (type 7)
      7,12,0,0,90,0               Device type 7, function 12, method 0, access 0, inbuflen 90, outbuflen 0
    1                           Number of IOCTLs for second targeted device (type 2d)
      2d,420,0,0,c,0              Device type 2d, function 420, method 0, access 0, inbuflen c, outbuflen 0

The second device begins here:

  DP(1)0x7e00-0x21dbda400+2   Device name of the second device
  2                           Number of device type IOCTLs targeted at this device

    7,12,12                     First targeted device: device type 7, low function 12, high function 12
    2d,420,420                  Second targeted device: device type 2d, low function 420, high function 420


    1                           Number of IOCTLs for first targeted  device (type 7)
      7,12,0,0,90,0               Device type 7, function 12, method 0, access 0, inbuflen 90, outbuflen 0
    1                           Number of IOCTLs for second targeted device (type 2d)
      2d,420,0,0,c,0              Device type 2d, function 420, method 0, access 0, inbuflen c, outbuflen 0