DRIVER_VERIFIER_DETECTED_VIOLATION is a blue screen with a silver lining: Windows was actively hunting for bad drivers, found one misbehaving, and stopped the system before it could do quiet damage. Stop code 0xC4 is Driver Verifier’s way of saying “caught you.”
This error only appears when Driver Verifier is enabled — it’s not something Windows does on its own in normal operation. So the fix has two parts: deal with Verifier itself, then deal with whatever driver it caught.
Why this happens
- A genuinely buggy third-party driver. Audio, network, VPN, and antivirus filter drivers are the usual offenders Verifier catches.
- Verifier was left enabled after troubleshooting. A previous diagnostic session turned it on and nobody turned it off.
- A driver update introduced a violation. A new driver version with a bug Verifier now trips over on every boot.
- Overly aggressive Verifier settings. Verifying all drivers with all checks creates crashes from minor issues and massive slowdowns.
- Corrupted driver files. A damaged driver binary behaving in ways its code never intended.
- Conflicting low-level software. Two products’ drivers fighting over the same resources, with Verifier catching the fallout.
- Faulty RAM mimicking driver bugs. Bad memory can corrupt driver data structures, making innocent drivers look guilty to Verifier.
- Verifier enabled by policy. On managed or former-work laptops, a group policy or MDM setting can enable Verifier without any local user action — check with your IT admin if the settings reappear after a reset.
How to fix it
Work through these in order — Verifier control first, then the driver hunt.
Fix 1: Turn off Driver Verifier
If you’re not actively debugging, Verifier should not be running.
- Press Win + R, type
verifier, and press Enter. - Select Delete existing settings and click Finish.
- Restart. If the crashes stop, Verifier was the immediate problem — but remember it was catching a real driver bug, so don’t stop here. Continue to Fix 2 to find the driver.
- If Windows crashes too fast to open the dialog, boot into Safe Mode (Verifier doesn’t apply there the same way) or use the recovery Command Prompt:
verifier /reset.
Fix 2: Identify the guilty driver from the dump
Don’t guess — read the evidence.
- Make sure minidumps are enabled: Advanced system settings > Startup and Recovery > Settings > Small memory dump.
- After the next crash (with Verifier temporarily re-enabled if needed), open
%SystemRoot%\Minidumpin WinDbg Preview and run!analyze -v. - Note the MODULE_NAME and the specific violation (parameter 1 decodes to the violation type).
- If a third-party driver is named, that’s your target for Fix 3. If only Microsoft modules appear, examine the stack for third-party drivers — or suspect RAM (Fix 6).
Fix 3: Update, roll back, or remove the driver
Act on what the dump told you.
- In Device Manager, find the device for the named driver.
- First try Update driver > Search automatically for drivers.
- Better: download the latest version from the hardware or laptop manufacturer’s site. For graphics, use NVIDIA or AMD directly (Intel owners: use Intel’s driver support tool).
- If the violation started with a driver update, use Properties > Driver > Roll Back Driver instead. If the driver belongs to software you don’t need (old VPN client, abandoned utility), uninstall the software entirely.
Fix 4: Re-enable Verifier surgically to confirm the fix
Verify the fix actually worked rather than hoping.
- Run
verifier, choose Create custom settings, and select the specific driver you fixed (not all drivers). - Enable the standard checks and restart. Use the laptop normally for a day.
- No crash = the driver is fixed. Then run
verifier /resetto turn Verifier off again. - If it still crashes on the same driver, the “fix” didn’t take — try an older driver version or a replacement product.
Fix 5: Check for conflicting software
Two drivers fighting looks like one driver misbehaving.
- Look for duplicate functionality: two antivirus products, two VPN clients, overlapping disk utilities.
- Uninstall all but one of each category, using vendor removal tools for antivirus products.
- Restart and test. Driver conflicts that Verifier flags often vanish once only one product owns the subsystem.
Fix 6: Test the RAM
Bad memory frames innocent drivers.
- Run
mdsched.exe, choose Restart now and check for problems, and use Extended mode. - If Verifier keeps blaming different drivers on different crashes — a rotating cast of suspects — that’s the signature of bad RAM, not bad drivers.
- Confirm with MemTest86 overnight if needed, and replace faulty sticks.
Fix 7: Repair system files
Corrupted driver binaries fail in ways that look like bugs.
- In Terminal (Admin), run
sfc /scannow. - Follow with
DISM /Online /Cleanup-Image /RestoreHealth. - Restart. Then re-verify with the surgical Verifier test from Fix 4.
Fix 8: Keep Verifier off and monitor normally
Return the system to a normal, uninstrumented state.
- Run
verifier /resetone final time and confirm in the Verifier GUI that no settings are active. - Restart and use the laptop normally for several days.
- If crashes return without Verifier, the driver bug is still there — capture a regular (non-Verifier) dump and analyze it; the faulting driver usually still shows. See Microsoft’s driver guidance for next steps.
For the closely related special-pool variant, see our Special Pool Detected Memory Corruption guide , and for the step-by-step Verifier workflow, the driver verifier detected violation 24H2 walkthrough .
Closing
DRIVER_VERIFIER_DETECTED_VIOLATION means the watchdog barked — now you check the yard. Turn Verifier off to stop the immediate crashes, read the dump to name the driver, fix that driver properly, and leave Verifier off when you’re done. It’s a diagnostic tool, not a roommate. Document which driver was at fault; if it recurs after a future update, you’ll know exactly where to look.
Frequently asked questions
What does DRIVER_VERIFIER_DETECTED_VIOLATION mean?
I never turned on Driver Verifier. Why is it running?
verifier — if it shows active settings, it was turned on deliberately at some point. Turning it off with verifier /reset is safe if you’re not actively debugging a driver.Should I leave Driver Verifier on after fixing the driver?
The dump names a Windows system driver. Is Windows broken?
ntoskrnl.exe or another Microsoft driver, it usually means a third-party driver corrupted memory that the system driver later tripped over. Look at the full stack in WinDbg rather than just the blamed module — the real culprit is typically the third-party driver in the call chain.