Seeing DRIVER_VERIFIER_IOMANAGER_VIOLATION means Driver Verifier — Windows’ driver stress-test tool — caught a driver breaking I/O rules and crashed the system on purpose. That’s actually good news: instead of a mystery crash, you have a tool pointing directly at a misbehaving driver.
The catch: Verifier stays on until you turn it off, and it’ll keep crashing your laptop until you do. So the order here matters: identify the driver, disable Verifier, then fix the driver. Our Verifier reference has more detail if you need it.
Why this happens
Driver Verifier was enabled (by you, a technician, or a troubleshooting guide) and is now doing its job — crashing on the bad driver it found.
A third-party driver violating I/O manager rules: improper IRP handling, bad buffer usage, or illegal calls.
The offending driver is often storage, network, or USB-related, since those live in the I/O path.
Verifier was left on after a previous troubleshooting session and forgotten.
An outdated driver that was always buggy, now exposed by Verifier’s strict checks.
Running Verifier on all drivers at once, which makes the system unstable and the culprit harder to isolate.
How to fix it
Work through these in order, starting with Fix 1. Most of these crashes are resolved by one of the first three fixes, so don’t skip ahead.
Fix 1: Boot into Safe Mode
Driver Verifier doesn’t run in Safe Mode, so this gets you to a stable desktop where you can turn it off and investigate.
Force-power-off twice during boot to reach the recovery environment.
Go to Troubleshoot > Advanced options > Startup Settings > Restart and press 4 for Safe Mode.
Confirm the laptop is stable in Safe Mode.
Everything below happens from here.
Fix 2: Turn off Driver Verifier
This is the urgent step — with Verifier off, the intentional crashes stop and you can work normally while fixing the real driver.
In Safe Mode, press Win + R, type
verifier, and press Enter.Choose Delete existing settings and click Finish.
Alternatively, open an admin Command Prompt and run
verifier /reset.Restart normally and confirm the blue screens stop. (The underlying driver bug remains — keep going.)
Fix 3: Identify the caught driver from the dump
Verifier’s crash dump names the driver that broke the rules. Reading it tells you exactly what to fix.
Open Event Viewer > Windows Logs > System and find the BugCheck entry — it often names the driver.
For the full picture, open the minidump in WinDbg (our dump analysis guide shows how) and run
!verifierand!analyze -v.Note the driver file name — that’s your target.
If no dump was saved, check Settings > System > About > Advanced system settings > Startup and Recovery settings to enable dumps for next time.
Fix 4: Replace the offending driver
The driver Verifier caught is buggy — update it, roll it back, or remove it, depending on what changed recently.
Open Device Manager and find the device tied to the named driver.
If the driver updated recently, use Properties > Driver > Roll Back Driver.
Otherwise Uninstall device (tick Attempt to remove the driver), restart, and install the manufacturer’s latest version.
For Intel components, the Intel Driver & Support Assistant finds the right one automatically.
Fix 5: Re-run Verifier narrowly to confirm the fix
Before declaring victory, verify the replacement driver actually passes Verifier’s checks — narrowly, so a different bug doesn’t crash you again.
Press Win + R, type
verifier, and choose Create standard settings.Select Select driver names from a list and tick ONLY the replacement driver.
Restart and use the laptop normally for several hours.
If no crash occurs, run
verifier /resetfrom an admin prompt and restart — leave Verifier off for daily use.
Fix 6: Check for firmware updates
Sometimes the ‘driver bug’ is really the driver working around buggy firmware. A BIOS or device firmware update resolves the underlying issue.
Check your laptop maker’s support site for BIOS and firmware updates for your exact model.
Also check the device maker’s site (SSD, Wi-Fi card, dock) for firmware updates.
Apply on AC power without interruption.
Re-test stability after updating. Microsoft’s guidance on driver troubleshooting is on their Windows support pages .
Fix 7: Recover with System Restore if you can’t reach Safe Mode
If Verifier crashes the boot too early for Safe Mode, System Restore from the recovery environment rolls back to before Verifier was enabled. And for next time, there’s a flag that makes Verifier disable itself after a boot failure.
Boot into the recovery environment (force-power-off twice during the Windows logo).
Go to Troubleshoot > Advanced options > System Restore.
Pick a restore point from before you enabled Driver Verifier and complete the wizard.
Once you’re back in Windows, open an admin Command Prompt.
For future Verifier sessions, first run
verifier /bootmode resetonbootfail— this makes Verifier automatically disable itself if the next boot fails.Then configure Verifier as before, knowing a bad session can never lock you out again.
Closing
DRIVER_VERIFIER_IOMANAGER_VIOLATION looks alarming, but it’s Verifier doing exactly what you asked: catching a bad driver in the act. Turn Verifier off first so you can think straight, read the dump to name the driver, replace that driver, and confirm with a narrow re-run. And when you’re done, leave Verifier off — it’s a diagnostic tool, not a bodyguard, and running it permanently just manufactures crashes. The resetonbootfail flag is the seatbelt for Driver Verifier: set it before every session and a bad run can never lock you out again. Verifier is a power tool — respect it the way you’d respect any tool that deliberately crashes your PC, and it keeps handing you driver names instead of headaches.
