SCSI Verification

04/20/2017

4 minutes to read

Contributors

In this article

The SCSI Verification feature of Driver Verifier monitors the interaction between a SCSI miniport driver and the port driver. If the miniport driver misuses a routine, responds incorrectly to a request from the port driver, or takes an excessive amount of time to respond to a request, a bug check is issued.

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

Violations Detected by SCSI Verification

The SCSI Verification option can detect several misuses of SCSI routines. It is also possible to individually disable certain of these checks.

When a SCSI miniport driver commits one of the following violations, Driver Verifier will issue bug check 0xF1.

The miniport driver passes a bad argument to ScsiPortInitialize.

The miniport driver calls ScsiPortStallExecution and specifies a delay longer than 0.1 second, stalling the processor for an excessive length of time.

The port driver calls a miniport driver routine, and the miniport driver takes longer than 0.5 second to execute it. (The FindAdapter routine is exempt, and the HwInitialize routine is allowed 5 seconds.)

The miniport driver completes a request more than once.

The miniport driver completes a routine with an invalid SRB status.

The miniport driver calls ScsiPortNotification to ask for NextLuRequest, but an untagged request is still active.

The miniport driver passes an invalid virtual address to ScsiPortGetPhysicalAddress. (This usually means the address supplied doesn't map to the common buffer area.)

The bus reset hold period ends, but the miniport driver still has outstanding requests.

See Bug Check 0xF1 (SCSI_VERIFIER_DETECTED_VIOLATION) for a complete list of the bug check parameters.

In addition to these violations, SCSI Verification also monitors the miniport driver's memory access for improper use. Two common memory violations made by miniport drivers are accessing an SRB extension after a request completes, and accessing an SRB's DataBuffer when the miniport driver has not specified MapBuffers.

Memory violations of this sort will usually result in Bug Check 0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) being issued.

Activating This Option

The procedure for activating the SCSI Verification option is different from the procedures for activating other Driver Verifier options.

Open the registry using regedit.exe. In the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ScsiPort key, add a subkey named Verifier. Within that key, add a REG_DWORD entry named VerifyLevel. The value assigned to this entry will determine which SCSI Verification tests will be active. The value 0x1 will give maximum verification.

Reboot the computer.

If the VerifyLevel value does not exist, or is equal to 0xFFFFFFFF, SCSI Verification will be disabled.

The individual bits in the VerifyLevel value can be used to control exactly which tests will be performed. Bit zero (0x1) enables certain tests; bits 28, 29, 30, and 31 disable certain tests. Therefore, maximum verification can be obtained by using the value 0x00000001.

The effects of each bit are as follows:

Bit

Value

Effect

0

0x1

Driver Verifier will monitor the miniport driver's memory access and check for improper use of memory buffers.

28

0x10000000

Driver Verifier will not issue a bug check when the HwAdapterControl routine takes more than 0.5 second to complete.

29

0x20000000

Driver Verifier will not issue a bug check when a reset hold period ends and there are still outstanding requests on a logical unit.

30

0x40000000

Driver Verifier will not issue a bug check when the miniport driver calls ScsiPortNotification with NextLuRequest while an untagged request is still active.

31

0x80000000

Driver Verifier will not issue a bug check when the HwInitialize routine takes more than 5 seconds to complete.

In most cases, the recommended setting is 0xD0000001. This enables all SCSI Verifier tests except for the time limit on HwAdapterControl, the time limit on HwInitialize, and the ban on multiple requests to a logical unit. These three tests are often too stringent.

If a kernel debugger is attached, it is possible to change the SCSI Verification level after the boot cycle. To do this, use the debugger command:

kd> ed scsiport!SpVrfyLevel Level

This command allows you to set a new value for Level. Using this method, you can change the high bits (0x10000000 through 0x8000000) at any time. However, if you wish to change the low bit (0x1), you must do so during the boot process (at the kernel debugger's initial breakpoint).

Similarly, if you want to completely deactivate SCSI Verification, you need to set Level to 0xFFFFFFFF at the initial breakpoint.

Note The value 0xF0000000 will disable all tests, but the SCSI Verification modules will still be loaded. Use this value if you wish to disable verification but intend to enable the high-bit tests at a later time. On the other hand, the value 0xFFFFFFFF prevents the modules from being loaded entirely; if this value is used during boot it will not be possible to enable SCSI Verification without rebooting.

Activating without Rebooting

In general, you cannot activate or deactivate SCSI Verification without restarting ("rebooting") the computer on any Windows operating system. The ScsiPort.sys driver reads the VerifyLevel registry entry only when it loads, which is typically at boot time. However, if the ScsiPort.sys driver is not loaded when you add the registry entry, or if it is unloaded and reloaded, you can enable SCSI Verification on Windows XP and later versions of Windows without restarting the computer.