Using Driver Verifier: identify driver bugs precisely

Driver Verifier is one of the most powerful Windows tools for finding driver bugs — but it's also one of the most dangerous. Used incorrectly, Driver Verifier triggers more BSODs than it solves. Used correctly, it identifies the exact driver causing problems. We explain when, how, and (most importantly) when not to use Driver Verifier.

What does Driver Verifier do?

Driver Verifier (verifier.exe) is built into every Windows Pro/Enterprise installation since Vista. It deliberately stresses the selected drivers under stricter conditions than normal operation: tighter memory checks, IRQL violations, race-condition simulations, and many more.

The result: a buggy driver triggers a BSOD much faster — but with a clear stop-code that identifies the culprit. In normal operation the same driver might run for weeks with rare crashes; under Driver Verifier it crashes within minutes.

When to use Driver Verifier

Good scenarios:

• Repeated BSODs whose source isn't identifiable via WhoCrashed/WinDbg
• Suspicion of multiple driver issues running concurrently
• Validation of self-developed drivers
• After a firmware/driver mass change to ensure stability

Bad scenarios:

• Single, isolated BSOD — overkill
• System under productive use — Driver Verifier slows the system noticeably
• No backup created — risk of being unable to boot

Step-by-step: running Driver Verifier safely

Preparation (mandatory!)

1. Restore point: Win + R → "rstrui" → Configure → activate protection → Create restore point now
2. Drive image backup — for paranoid cases. Macrium Reflect Free does the job.
3. Familiarise with Safe Mode: know how to boot Windows into Safe Mode (typically: Settings → System → Recovery → Advanced startup)
4. Driver list ready — Driver Verifier needs to know which drivers to test

Run Driver Verifier

1. cmd as administrator → verifier
2. "Create custom settings (for code developers)" → Next
3. "Select individual settings from a full list" → Next
4. Select these flags:
   • Special Pool (always)
   • Pool Tracking (always)
   • Force IRQL Checking (always)
   • Deadlock Detection (always)
   • Security Checks (always)
   • Miscellaneous Checks (always)
   • DDI Compliance Checking (always)
   • SKIP: "Low Resources Simulation" — too aggressive
5. Next → "Select driver names from a list"
6. Choose only third-party drivers (sort by Provider — skip "Microsoft Corporation"). For typical scenarios: Nvidia, Realtek, Intel etc. — all "non-Microsoft".
7. Finish → reboot

Observe

The system now runs under Driver Verifier mode. You'll notice:

• Slight slowdown
• Higher memory usage
• BSODs at problem drivers — usually within minutes to hours

Each BSOD has a stop-code (e.g. DRIVER_VERIFIER_DETECTED_VIOLATION). The minidump in C:\Windows\Minidump\ identifies the specific driver.

Disable Driver Verifier

After analysis is complete:

verifier /reset

(in cmd as administrator), then reboot. The system runs normally again.

If you can't boot

If Driver Verifier finds a serious bug right at boot, the system might no longer start. Solution:

1. Boot Windows into Safe Mode (Shift + restart → Troubleshoot → Advanced options → Startup Settings → 4 for Safe Mode)
2. cmd as administrator → verifier /reset
3. Reboot

If Safe Mode doesn't boot either: Windows Recovery → Command Prompt → manually disable verifier:

bcdedit /deletevalue {default} bootlog
del C:\Windows\System32\drivers\verifier.sys

(very rare scenario — typically the simple verifier /reset in Safe Mode is enough)

Analysing the BSOD with WinDbg

For each BSOD that Driver Verifier triggers, the minidump contains the exact problem driver. To read:

1. Install WinDbg (Microsoft Store)
2. File → Open Crash Dump → C:\Windows\Minidump\latest_dump.dmp
3. !analyze -v
4. Look for "FAILURE_BUCKET_ID" or "MODULE_NAME" — the file name of the culprit

The output names the exact driver and the rule violation. With this info you can precisely update or roll back the affected driver — no more guessing.

False positives

Sometimes Driver Verifier flags drivers that aren't actually buggy — they just don't comply 100% with Microsoft's stricter rules. Examples:

• Older Realtek audio drivers — flagged but stable
• Some VPN drivers — flagged due to network-stack interactions
• Antivirus drivers — frequently flagged

Rule of thumb: a driver that crashes under Verifier within minutes and shows a clear violation is the actual culprit. A driver that only crashes occasionally and only with low-priority flags is more likely a Verifier artifact.