New Driver Verifier feature for Vista: runtime checking for remove locks on fre OS builds

An updated document on WHDC lists the new DV features for Vista. Having used them, there are some great new additions to the verifier. One of the best features is the ability to start verification without a reboot. It has its limitations, but it is still a huge improvement.

Another feature that I requested and made it into the Vista is that you can get the ASSERTs/stops on releasing a tag that was not previously acquired on a IO_REMOVE_LOCK that was not acquired on a fre build of the OS. Normally these ASSERTs are only present in a chk build of the OS itself. Since not that many driver developers know to run a chk build of the OS, many developers were not getting the debug feedback on their misuse of the remove lock. To get this functionality you still need to run a chk of your driver (or more specifically, the chk size of the IO_REMOVE_LOCK structure).

There are new bugcheck subcodes 0xD5 and 0xD6 (MSDN contains this info as well) for DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4) that relate to remove lock verification

Parameter 1	Parameter 2	Parameter 3	Parameter 4	Cause of Error
0xD5 (Windows Vista and later operating systems only)	Address of the IO_REMOVE_LOCK structure created by the checked build version of the driver	Current IoReleaseRemoveLock tag	Reserved	The current IoReleaseRemoveLock tag does not match the previous IoAcquireRemoveLock tag. If the driver calling IoReleaseRemoveLock is not in a checked build, Parameter 2 is the address of the shadow IO_REMOVE_LOCK structure created by Driver Verifier on behalf of the driver. In this case, the address of the IO_REMOVE_LOCK structure used by the driver is not used at all, because Driver Verifier is replacing the lock address for all the remove lock APIs. A bug check with this parameter occurs only when the I/O Verification option of Driver Verifier is active.
0xD6 (Windows Vista and later operating systems only)	Address of the IO_REMOVE_LOCK structure created by the checked build version of the driver	Tag that does not match previous IoAcquireRemoveLock tag	Previous IoAcquireRemoveLock tag	The current IoReleaseRemoveLockAndWait tag does not match the previous IoAcquireRemoveLock tag. If the driver calling IoReleaseRemoveLock is not a checked build, Parameter 2 is the address of the shadow IO_REMOVE_LOCK structure created by Driver Verifier on behalf of the driver. In this case, the address of the IO_REMOVE_LOCK structure used by the driver is not used at all, because Driver Verifier is replacing the lock address for all the remove lock APIs. A bug check with this parameter occurs only when the I/O Verification option of Driver Verifier is active.

Comments

• Anonymous
  March 22, 2007
  First, a correction to my previous remlock post , where I said that you must still compile your driver