Add'l BSODs (1909)

Please run driver verifier using the following settings for 48 hours.

• Special Pool
• Force IRQL checking
• Pool Tracking
• Deadlock Detection
• Security Checks
• Miscellaneous Checks
• Power framework delay fuzzing
• DDI compliance checking

Warning: driver verifier could cause boot issues and/or performance issues.

• Make sure that you have recovery media, if needed you can create it.
• Configure a restore point prior enabling driver verifier.

Resetting driver verifier options (recommended in this order)

1. In normal mode open an administrator command prompt and enter the below command
2. In safe mode open an administrator command prompt and enter the below command
3. On 3 boot failures, you'll boot automatically to the recovery options,
   
   • click Troubleshoot
   • go to the advanced options
   • choose command prompt
   • enter the below command
   
   
4. Boot with the recovery media, see above 4 steps in option 3.
5. Via the recovery options or recovery media, select a restore point prior enabling driver verifier

Code:

verifier /reset

Crashed when running driver verifier

1. Reset driver verifier
2. Boot in normal mode if necessary
3. Follow Blue Screen of Death (BSOD) Posting Instructions to provide the requested logs

Extra information about driver verifier
When you run driver verifier, there are two things you're looking out for
1. Driver verifier won't find any driver violating something and thus in the time you need to run it there won't be a crash
2. Driver verifier will find a driver violating something and thus the system will crash.

The end result of driver verifier is either of the two, but when driver verifier finds something your system will BSOD.


Driver verifier essentially validates selected drivers on selected actions, this validation adds some delay to actions performed in the background which results in a performance decrease that many people notice. This is called stress testing drivers and depending on quite a few factors this performance decrease is worse for some than for others, and some won't even notice a difference.

Depending on the drivers selected, it is possible that some of the selected drivers are so-called 'boot' drivers, meaning they load when your system is booting. If these drivers don't pass a validation check, your system will crash, but since the drivers are loading at boot, your system will basically be in a boot loop. That is one of the risks involved and the most important one. Of course, there are various methods to recover from it.

If you want visual confirmation that driver verifier is actually running, copy/paste the following command in powershell or command prompt

Code:

verifier /query

If the command gives a result similar to this, it means driver verifier is running.

There are some settings that could cause false positives to occur, but that would only happen if you use those settings inappropriately. The main one that I know is commonly used here, but I do not know why, it is the setting 'force pending I/O requests'. I/O communication is mostly done with something called IRPs (I/O Request Packet) that have a status indicating whether it is waiting, pending, completed, etc.

Force Pending I/O Requests is an additional option which means that it should not just be run randomly but only in specific scenarios. What it does is it randomly changes the status of an IRP to waiting so that driver verifier can uncover whether a driver handles that status correctly or not. The thing about that is that most drivers are not supposed to handle such situations because IRPs can be send to a driver that is well-known to complete the IRP so that the driver sending the IRP doesn't have to handle the waiting status. As such, this option could possibly cause false positives.

There are other settings that could cause false positives when they're used on a bunch of drivers instead of selected driver(s), such as systematic low resources simulation which, as it suggests, creates a simulation where a driver has to deal with low resources that could cause performance issues if used on a lot of drivers, but none of those options are in the list of options I gave.


The only part in a driver verifier configuration that could cause driver verifier to crash the system at boot is the drivers selected. If the selected drivers load at boot and then do something inappropriately that driver verifier catches, that could end up in a boot loop. Fortunately, there are quite a few ways to get of it as outlined in my instructions.


With driver verifier enabled, as ironically as it may sound, I always hope for a BSOD caused by driver verifier as that suggest a driver caused a problem. I will need new logs by then so I can look into the crash and spot the driver that caused the crash.

All non-Microsoft drivers as the driver verifier link describes.

The real difference between the tutorial and what I provided is the options to choose for verification in driver verifier, everything else is just the same, really.

Glad to hear you're up and running with driver verifier enabled.

If you get problems with driver verifier, let me know.

Okay, let's see what happens after driver verifier is disabled.