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.

  1. Press Win + R, type verifier, and press Enter.
  2. Select Delete existing settings and click Finish.
  3. 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.
  4. 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.

  1. Make sure minidumps are enabled: Advanced system settings > Startup and Recovery > Settings > Small memory dump.
  2. After the next crash (with Verifier temporarily re-enabled if needed), open %SystemRoot%\Minidump in WinDbg Preview and run !analyze -v.
  3. Note the MODULE_NAME and the specific violation (parameter 1 decodes to the violation type).
  4. 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.

  1. In Device Manager, find the device for the named driver.
  2. First try Update driver > Search automatically for drivers.
  3. 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).
  4. 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.

  1. Run verifier, choose Create custom settings, and select the specific driver you fixed (not all drivers).
  2. Enable the standard checks and restart. Use the laptop normally for a day.
  3. No crash = the driver is fixed. Then run verifier /reset to turn Verifier off again.
  4. 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.

  1. Look for duplicate functionality: two antivirus products, two VPN clients, overlapping disk utilities.
  2. Uninstall all but one of each category, using vendor removal tools for antivirus products.
  3. 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.

  1. Run mdsched.exe, choose Restart now and check for problems, and use Extended mode.
  2. If Verifier keeps blaming different drivers on different crashes — a rotating cast of suspects — that’s the signature of bad RAM, not bad drivers.
  3. 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.

  1. In Terminal (Admin), run sfc /scannow.
  2. Follow with DISM /Online /Cleanup-Image /RestoreHealth.
  3. 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.

  1. Run verifier /reset one final time and confirm in the Verifier GUI that no settings are active.
  2. Restart and use the laptop normally for several days.
  3. 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?
Driver Verifier — Windows’ built-in driver stress-testing tool — caught a driver breaking the rules: accessing freed memory, mishandling IRQL levels, corrupting pool memory, or similar violations. Stop code 0xC4 means Verifier did its job and stopped the system before the bad driver could cause silent damage. The fix is identifying the driver and updating, rolling back, or removing it.
I never turned on Driver Verifier. Why is it running?
Someone or something enabled it: a troubleshooting guide you followed, a technician diagnosing the machine, or occasionally a Windows Insider or driver-development setup. Check by 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?
No. Verifier imposes real performance overhead and will keep crashing the system if any other driver misbehaves. It’s a diagnostic tool, not a protective feature. Turn it off once you’ve identified and fixed the culprit — a healthy system doesn’t need it running.
The dump names a Windows system driver. Is Windows broken?
Rarely. When Verifier blames 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.