What DRIVER_VERIFIER_DETECTED_VIOLATION means
Bug check 0xC4 is the general code Windows raises when Driver Verifier, a built-in driver testing tool, detects a fatal violation in a driver. The driver broke a kernel rule such as calling a function at the wrong interrupt level, freeing memory twice or writing past the end of a memory allocation, and Verifier stopped the system at that point so the fault could be found. Driver Verifier is not switched on by default, so this stop code usually means someone, or some tool, turned it on.
Common causes
- Driver Verifier was enabled, by you, a technician or a driver-testing tool, and is checking a driver that breaks kernel rules
- A driver with a real defect, such as memory misuse or incorrect locking, that Verifier caught early
- A third-party or outdated driver that has not been updated for your Windows version
How to fix DRIVER_VERIFIER_DETECTED_VIOLATION
Work through these in order and test after each one. Stopping as soon as the crashes stop tells you which change mattered.
- Check whether Driver Verifier is running. Open Terminal (Admin) and run
verifier /querysettings. If it lists drivers or flags, Driver Verifier is enabled on this PC. - Switch Driver Verifier off. Run
verifier /resetin Terminal (Admin) and restart. If Windows crashes during start-up, open Safe Mode first (hold Shift while choosing Restart, then Troubleshoot, Advanced options, Startup Settings) and run the same command there. - Note the file name on the blue screen. If the screen shows a line such as "What failed" followed by a .sys file, write it down. Searching that file name shows which driver it belongs to, which tells you what to update or remove. The named file is the code that crashed, which is not always the root cause.
- Undo the most recent change. If the blue screens began after a Windows update, a new driver or new software, remove that change first. Uninstall the update from Settings, Windows Update, Update history, or roll a driver back in Device Manager (right-click the device, Properties, Driver, Roll Back Driver). Verifier names the driver it caught, so reverting or updating that specific driver is the real fix.
- Update or remove the driver it named. Install the latest version from the device or PC maker. If no fixed version exists, uninstall the software that installed the driver, or replace the device, because Driver Verifier only reports faults and cannot repair them.
Reading the crash evidence for 0xC4
Microsoft’s reference says the first parameter identifies the type of violation and the remaining parameters depend on it. The same stop code can therefore mean anything from a memory-allocation mistake to a deadlock.
Windows normally saves a small dump in C:\Windows\Minidump. A debugger’s !analyze -v output shows the first parameter and the driver on the stack, which together identify the faulty driver far more precisely than the stop code.
| First parameter | What Microsoft describes | What it suggests |
|---|---|---|
| 0x1 or 0x2 | A pool allocation made at an interrupt level that is too high | Incorrect driver code |
| 0x10 to 0x14 | Freeing memory that was never allocated or was already freed | Incorrect driver code |
| 0x51 to 0x59 | Writing past the end of a pool allocation | Memory corruption by the driver |
| 0x60 to 0x62 | A driver unloaded without freeing its pool allocations | A leak when the driver unloads |
| 0xC0 to 0xC3 | An I/O routine was called or returned with interrupts disabled | Incorrect driver code |
| 0x1000 or 0x1001 | A deadlock detected by Verifier’s deadlock detection | Incorrect locking in the driver |
| 0x2000 to 0x2005 | Code integrity violations such as executable pool | A driver breaking memory protection rules |
Source: Microsoft Learn: Bug Check 0xC4 DRIVER_VERIFIER_DETECTED_VIOLATION ↗
Turning Driver Verifier off hides the symptom, not the faulty driver. If the same driver keeps being named, keep the minidump and report it to the driver’s maker, and avoid turning Verifier back on unless you are deliberately testing.
Not sure this is your code?
The stop code appears as text on the blue screen. If the PC restarted before you could read it, open Event Viewer, then Windows Logs, then System, and look for a BugCheck event with ID 1001. You can also search all stop codes.