John Carrona - Microsoft MVP

Windows Expert - Consumer

www.carrona.org

I have the Knack: sound byte here



Driver Verifier Settings RSS Feed Subscribe to the RSS feed
Originally Added to Website:  14 Sep 2009
Last updated:  23 Dec 2015
Added Windows 10 instructions, change preliminaries, added section listing the individual settings for Windows 10 at the end of the page.


Driver Verifier Settings

Using Driver Verifier is an iffy proposition.
Most times it'll crash and it'll tell you what the driver is.
But sometimes it'll crash and won't tell you the driver.
Other times it'll crash before you can log in to Windows.
If you can't get to Safe Mode, then you'll have to resort to offline editing of the registry to disable Driver Verifier.

1)  So, I'd suggest that you first backup your stuff and then make sure you've got access to another computer so you can contact us if problems arise.

2)  Then make a System Restore point using System Restore. This is so you can restore the system using the Windows Startup Repair feature in Vista and later OS's.

3)  Create a Repair disc (Recovery Drive in Win8.1/10):
- Vista, you can download the repair discs from different websites.  If unable to locate them, shoot me a PM and I'll try to point you to them.
- Windows 7 - Go to Start...All Programs...Maintenance...Create a System Repair Disc
- Windows 8 - Press "WIN" and "R" to open the Run dialog...type "RECDISC" (without the quotes) and press ENTER
- Windows 8.1 - Go to the Start Screen and type in "recoverydrive" (one word, without the quotes). That will start the recovery drive process. You will need a USB drive of at least 512 mB - and all data will be erased off of it. If copying the recovery partition the drive size will be much, much larger (16 - 32 gB drive required).
- Windows 10 - Go to Start (press the "Win" key) and type in "recoverydrive" (one word, without the quotes). That will start the recovery drive process. You will need a USB drive of at least 512 mB - and all data will be erased off of it. If copying the recovery partition the drive size will be much, much larger (16 - 32 gB drive required).

4)  Test the System Repair disc/Recovery Drive to make sure that you can get to the System Restore entry when you boot from the disk/drive (you may also want to try actually using System Restore to make sure that it works)

Then, here's the procedure to run Driver Verifier:
- Go to Start and type in "verifier" (without the quotes) and press Enter
- Select "Create custom settings (for code developers)" and click "Next"
- Select "Select individual settings from a full list" and click "Next"
- Select everything EXCEPT FOR  "Force Pending I/O Requests" and "Low Resource Simulation" and click "Next" 
NOTE:  
"IRP Logging", if selected, is best analyzed by posting the Full/Kernel Memory dumps (zip them up and upload them to a free file hosting service and post a link to it on the forums).
NOTE:   
"Special Pool" may be able to be used depending on amount of RAM and errors being seen.  In situations with small amounts of RAM, DO NOT select it,
- Select "Select driver names from a list" and click "Next"
Then select all drivers NOT provided by Microsoft and click "Next"
- Select "Finish" on the next page.

Reboot the system and wait for it to crash to the Blue Screen. Continue to use your system normally, and if you know what causes the crash, do that repeatedly. The objective here is to get the system to crash because Driver Verifier is stressing the drivers out.  If it doesn't crash for you, then let it run for at least 36 hours of continuous operation (an estimate on my part).

Reboot into Windows (after the crash) and
locate the memory dump file.  If present, turn off Driver Verifier by going back in and selecting "Delete existing settings" on the first page.  Then, zip up the memory dump file(s) and upload them with your next post.  If no dump files were generated, post back for further suggestions.

If you can't get into Windows because it crashes too soon, try it in Safe Mode.
If you can't get into Safe Mode, try using System Restore from your installation DVD to set the system back to the previous restore point that you created.

If that doesn't work, post back and we'll have to see about fixing the registry entry off-line:
[code]Delete these registry keys to stop Driver Verifier from loading (works in XP, Vista, Win7):
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDrivers
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\VerifyDriverLevel[/code]
Detailed instructions here:  http://www.sysnative.com/forums/bsod-kernel-dump-analysis-debugging-information/5055-disable-verifier-outside-windows-windows-vista-7-8-a.html

More info on this at this link: http://support.microsoft.com/?kbid=244617&sd=RMVP

******************************************************************************************************

Some notes on the above "canned" speech:

- The purpose of testing all 3rd party drivers is to see if they are the problem.  Most BSOD's are caused by issues with 3rd party drivers - so that's why we test them.
- If there are no BSOD's within 36 hours (my estimate), then it's most likely that you either have a Windows problem or a hardware problem.  To rule out Windows drivers - run Driver Verifier on all Windows (aka Microsoft) drivers.  If still no errors, then try a clean install without any extra programs (but all updates).
- If you're testing 3rd party drivers and you get a Driver Verifier BSOD that mentions Windows drivers - then (again) it's most likely a hardware issue or a Windows issue.


******************************************************************************************************
MORE NOTES....

[b][u]DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT-DRAFT[/b][/u]
[COLOR=Green]THEORY[/COLOR] behind this method:

Driver Verifier marks drivers to be verified early in the Boot Process.  
Any BSOD's that occur before this are, therefore, just plain-old BSOD's.
Once operational, BSOD's will be Verifier Enabled if they "trip" the special requirements laid out by Driver Verifier.
You can have non-Verifier Enabled memory dumps even when Driver Verifier is enabled.
It just means that the Driver Verifier conditions weren't "tripped"

Mark Russinovich spoke at TechEd 2006 about crash analysis and laid out the method that I use.
It performs all possible tests on all possible 3rd party drivers.  
So, if the 3rd party driver is at fault, then Driver Verifier should catch it with one of the enabled tests.
Not using all of the tests or not verifying all of the 3rd party driver results in an analysis that has missed some of the possible causes.

Since we've encountered situations where crashes do not occur under Driver Verifier, I adopted the 36 hour rule.
Simply run Driver Verifier for 36 hours - if it doesn't crash, then you can assume it's done all that it'll do.
Why 36 hours?  It's a guess that I made :0)

Finally, what about the situation where a driver is stable under normal conditions - but continues to crash under Driver Verifier?
This results in a hard choice for the user to make:
- could it be a minor hardware fault?
- could it be a fault in the driver?
- could it be a fault in another program that causes the fault in the driver?
There's lot's of things that this could be - so my suggestion is to NOT use Driver Verifier unless you have a memory dump that indicates that it might trip Driver Verifier tests.
Drivers have different degrees of stability - so testing a driver without a previous BSOD isn't a valid test IMO.


[COLOR=Green]RESULTS[/COLOR] analysis:

There are 2 possible results from Driver Verifier:
- no BSOD crash
- a BSOD crash

All you can attribute to the absence of a crash is that nothing "tripped" Driver Verifier.
This tells us that the 3rd party drivers aren't likely to be the problem.

If you get a BSOD crash, you may or may not get a memory dump.
So it's important to read all the info on the BSOD screen

If you don't have a memory dump, then it's gonna be very difficult without a driver name from the BSOD itself
If you do have a memory dump, then it may be a bit easier

You'll either have a memory dump that's Verifier Enabled, or one that's not.
If it's not Verifier Enabled - then it's something that has to be fixed before we can re-run Driver Verifier

If it's Verifier Enabled - it'll either point to a 3rd party driver, or not
If it's a 3rd party driver - remove it or fix it (it may be corrupted)
If it's not - then we've got more work to do (you told it to verify 3rd party drivers - but there's wasn't an issue with one).
This is similar to the dump files that aren't Verifier Enabled

Most often it's a hardware problem - but it can also be a compatibility issue or a Windows problem.
(remember the hardware rule - a lot of different BSOD's with a lot of different errors and causes are usually hardware/compatibility problems)

******************************************************************************************************

http://www.microsoft.com/whdc/DevTools/tools/DrvVerifier.mspx

XP Verifier tests:
Predefined settings:
- Standard settings
- Rigorous but possibly excessive or spurious tests
- Low resource simulation

Individual settings:
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Enhanced I/O verification - Not in Win7
- Deadlock detection
- DMA checking
- Low resources simulation

Vista Verifier tests:

Predefined settings:
- Standard settings
- Disk integrity checking - not in Win7
- Enhanced I/O verification - not in Win7
- Force pending I/O requests
- Low resources simulation
- IRP Logging

Individual settings:
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Enhanced I/O verification - Not in Win7
- Deadlock detection
- DMA checking
- Security checks
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Disk integrity checking - Not in Win7
- Miscellaneous checks

Windows 7 Verifier tests:
Predefined settings:
- Standard settings
- Force pending I/O requests
- Low resources simulation
- IRP Logging

Individual settings:
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Deadlock detection
- DMA checking
- Security checks
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Miscellaneous checks

Windows 8 Consumer Preview Verifier tests:
Predefined settings:
- Standard settings
- Force pending I/O requests
- Low resources simulation
- IRP Logging

Individual settings:
- Special pool
- Pool tracking
- Force IRQL checking
- I/O verification
- Deadlock detection
- DMA checking
- Security checks
- Force pending I/O requests
- Low resources simulation
- IRP Logging
- Miscellaneous checks
- Concurrency Stress Test  Now is Power Framework Delay Fuzzing (changed from the Preview to the Release version)
- DDI compliance checking

New tests listed here:  http://msdn.microsoft.com/en-us/library/windows/hardware/hh698274%28v=vs.85%29.aspx

Windows 8.1 Verifier tests:
from:  http://msdn.microsoft.com/en-us/library/windows/hardware/ff545470%28v=vs.85%29.aspx


Windows 10 (builds 10240 and 10586) Verifier tests:

Special pool
Force IRQL checking
Randomized low resources simulation
Pool tracking
I/O verification
Deadlock detection
DMA checking
Security checks
Force pending I/O requests (*)
IRP logging (*)
Miscellaneous checks
Invariant MDL checking for stack (*)
Invariant MDL checking for driver (*)
Power framework delay fuzzing
Port/miniport interface checkingDDI compliance checking
Systematic low resources simulation
DDI compliance checking (additional)
NDIS/WIFI verification
Kernel synchronization delay fuzzing
VM switch verification
Code integrity checks

Flags marked with a (*) require I/O Verification (bit 4) also be enabled.









© 2016 - John D. Carrona, Microsoft MVP
Windows Expert - Consumer
Forum screen name: usasma

Microsoft MVP Profile - http://mvp.microsoft.com/en-us/mvp/John%20D.%20Carrona-33494