Using Driver Verifier Safely
Driver Verifier is built into every copy of Windows and it is the most effective tool available for identifying a misbehaving driver. It is also the tool most likely to leave you in a boot loop if you enable it carelessly. Both things are true, and the second is largely avoidable - there is a flag that makes Verifier disable itself if the machine fails to start, and almost nobody uses it.
What it actually does
Most driver bugs cause damage in one place and a crash somewhere else entirely. A driver writes past the end of its buffer, corrupting the block next to it; ten seconds later a completely different component touches that block and the machine stops. The dump names the innocent party.
Driver Verifier closes that gap. It changes how memory is allocated and how driver calls are checked so that violations fault at the moment they occur. A buffer overrun crashes the machine immediately, in the offending driver, with that driver's name in the dump.
So it does not fix anything. What it does is convert an unidentifiable crash into an identifiable one - which, when three dumps have named three different Microsoft components, is exactly what you need.
Verifier makes the machine crash more, and slower. That is the tool working as designed. You are deliberately trading stability for information, for a limited period.
Before you enable it
Three things, and the third is the one people skip.
1. Create a restore point. Search for Create a restore point, select the system drive, and create one. Thirty seconds.
2. Know your route to Safe Mode. Interrupt the boot three times with the power button and Windows enters the recovery environment on the fourth attempt. From there: Troubleshoot, Advanced options, Startup Settings, Restart, then choose Safe Mode. Practise this once before you need it.
3. Use the boot-fail reset flag. This is the important one. Run this in an administrator prompt before enabling any checks:
verifier /bootmode resetonbootfailIt tells Verifier to disable itself automatically if the machine fails to boot. That single command removes most of the risk people worry about with this tool, and it is barely mentioned anywhere.
Back up anything important first. Not because Verifier destroys data, but because you are about to deliberately crash a machine repeatedly and that is a reasonable moment to have a backup.
Which settings to enable
Run verifier as administrator to open Driver Verifier Manager. Choose Create custom settings (for code developers), then Select individual settings from a full list.
Enable these:
| Setting | What it catches |
|---|---|
| Special Pool | Buffer overruns and use-after-free. The single most valuable option and the reason to run Verifier at all. |
| Force IRQL checking | Drivers touching pageable memory at raised interrupt level - the 0xA violation. |
| Pool Tracking | Drivers that leak allocations or free them incorrectly. |
| I/O Verification | Malformed I/O request handling. |
| Deadlock Detection | Lock ordering problems. Worth adding for hangs and 0x101. |
| Security Checks | Various unsafe operations. |
| Miscellaneous Checks | Freeing memory still in use, and similar. |
Leave these off:
- Low Resource Simulation - deliberately fails random allocations to see how drivers cope. It produces crashes that are not real-world bugs, and it will send you chasing something that would never happen in normal use.
- Force Pending I/O Requests - extremely aggressive and prone to false positives on otherwise fine drivers.
- DDI compliance checking - useful to developers testing their own driver, noise to everyone else.
Selecting which drivers to verify
On the next screen choose Select driver names from a list, then sort by Provider and tick everything not supplied by Microsoft.
Do not choose Automatically select all drivers. Verifying Microsoft's own drivers adds substantial overhead, makes the machine much slower, and tells you nothing - those are not the drivers causing your problem.
Microsoft's own guidance is to verify the smallest number of drivers possible, because the checking adds overhead as it runs. If you already suspect a handful of drivers, verify only those - it is faster and the machine stays more usable.
Click Finish and reboot when prompted. Confirm what is active at any time with:
verifier /querysettingsRunning it
Use the machine normally, and do whatever tends to provoke the crashes. If they only happen while gaming, game. If they happen at idle, leave it running overnight.
Expect the machine to feel slower. Expect it to crash - that is the point.
How long to leave it on: at least 24 to 48 hours of normal use, or until it bugchecks. If your crashes normally happen once a week, you may need to leave it a week. Verifier usually accelerates them considerably, though, because it turns silent violations into immediate ones.
If it runs for several days across every non-Microsoft driver and never fires, that result is itself meaningful. It is reasonable evidence that no driver is misbehaving - which points at memory, storage or the machine's stability settings instead.
Reading the result
When it bugchecks, the stop code is often different from the one you started with - Verifier-triggered crashes frequently arrive as DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4) or as a pool or IRQL bugcheck. That is expected and does not mean a new problem.
Open the newest minidump in WinDbg and run:
!analyze -vRead MODULE_NAME and IMAGE_NAME. Because Verifier faults at the moment of the violation rather than later, this name is far more trustworthy than one from an ordinary crash - the usual caveat about the named module being an innocent bystander largely does not apply here.
The dump reading guide covers the rest.
Turning it off
Do not leave Verifier enabled. It costs performance permanently and will keep crashing the machine on violations that may be harmless in practice.
verifier /resetThen reboot. Confirm with verifier /querysettings, which should report that no settings are active.
This is the situation the preparation was for. Interrupt the boot three times with the power button to reach recovery, then Troubleshoot, Advanced options, Startup Settings, Restart, and choose Safe Mode. Open an administrator command prompt, run verifier /reset, and reboot normally.
If Safe Mode will not start either, use Troubleshoot, Advanced options, Command Prompt from the recovery environment and run the same command there. Failing that, System Restore to the point you created before starting.
And if you ran verifier /bootmode resetonbootfail beforehand, you will probably never see this section apply - Verifier disables itself and the machine boots normally.
When not to bother
Verifier is a good tool aimed at a specific class of problem. It is the wrong choice when:
- The dump already names a third-party driver consistently. You have your answer - update or remove it. Verifier confirms what you know at the cost of a day.
- Memory tests fail. Fix the hardware first. Verifier will produce crashes, and they will not mean what you think.
- The stop code is hardware-reported. 0x124 and WHEA events come from the hardware itself. Verifier has nothing to say about them.
- The machine is your only working computer and you need it tomorrow. This is a diagnostic process that involves deliberate crashes. Do it when you can afford the downtime.
It is the right choice when crashes are frequent enough to reproduce, the dumps name Microsoft components or a different module each time, and memory has already tested clean.
Frequently asked
Will Driver Verifier damage my system or my files?
It does not modify drivers or write to your data - it changes how memory is allocated and how driver calls are checked while it is enabled, and verifier /reset reverses all of it. The real risk is practical rather than destructive: a machine that crashes on every boot is unusable until you disable it, and an unexpected crash can lose unsaved work. Create a restore point, use the boot-fail reset flag, and back up first.
It has been running for three days and nothing has crashed. Is it working?
Check with verifier /querysettings - if it lists your settings and drivers, it is active. A long clean run is a genuine result rather than a failure: Verifier is aggressive and specifically designed to catch the mistakes that cause pool and heap bugchecks, so several days across every non-Microsoft driver without firing is reasonable evidence that no driver is at fault. At that point move on to memory testing and stock settings.
The crash it produced names a different stop code than my original problem. Did I break something else?
No - that is normal. Verifier detects violations earlier and reports them through its own bugchecks, commonly DRIVER_VERIFIER_DETECTED_VIOLATION (0xC4) or a pool-related code. The stop code changed because the detection point changed, not because the underlying bug did. What matters is the module name in the dump.
Should I verify Microsoft drivers too?
Generally not. It adds significant overhead, slows the machine considerably, and Microsoft's own driver set is heavily tested - it is very unlikely to be your problem. Microsoft's guidance is to verify as few drivers as possible. The one exception is if you have specific evidence pointing at a Microsoft component, which is rare enough that you would know why.
Can I use Verifier to test a driver before I install it properly?
That is closer to its designed purpose - it exists for driver developers testing their own code. For that use, verify only the driver in question rather than everything, and consider enabling DDI compliance checking, which is noise for troubleshooting but genuinely useful when you own the source.
Related errors
- GuideHow to Read a Windows Crash Dump File with WinDbgInstall WinDbg, open the dump, run one command. Fifteen minutes, and it usually names the driver.
- 0x000000C2BAD_POOL_CALLERA driver misused kernel memory allocation. Verifier with pool options finds it reliably.
- 0x0000013AKERNEL_MODE_HEAP_CORRUPTIONThe kernel heap manager caught corruption. Parameter 1 names which kind, precisely.