The stop code 0x000000C9 — DRIVER_VERIFIER_IOMANAGER_VIOLATION — is an oddity among blue screens because it is not really an accident — it is Driver Verifier pulling the emergency brake on purpose. Verifier is a driver stress-testing harness built into Windows: it watches drivers run and forces a crash the instant one mishandles an I/O request, so the defect cannot quietly corrupt your data. In this case, the rule being broken concerns how drivers issue and complete I/O operations.

Running into it right after a Windows 11 update points to one of two situations. Either a testing session left Verifier switched on and the new build simply judges drivers by stricter rules, so a driver that behaved acceptably before is now being graded harder. Or Verifier is doing exactly what it was built for and has caught a genuinely defective driver. The walkthrough below helps you determine which situation you are in and brings the crashes to an end.

Why this happens

  • Verifier left running after an earlier session. Driver packages, manufacturer utilities, and past troubleshooting can all switch it on without an obvious sign, and the setting carries over through feature updates.
  • The new build enforces I/O rules more strictly. An update can tighten request-handling checks that older builds overlooked, so a borderline driver that previously escaped attention gets flagged.
  • Buggy replacement drivers shipped with the update. The update may have swapped in newer storage, network, or USB drivers that contain real defects in how they handle I/O requests.
  • Filter drivers from security products. Antivirus, encryption, and backup tools hook into the I/O path with filter drivers — among the most commonly flagged modules after any update.
  • Driver files damaged by a rough update. An interrupted or corrupted update can leave driver binaries with broken I/O logic that Verifier then exposes.
  • Misbehaving USB and peripheral drivers. A faulty device driver issuing malformed requests becomes visible to Verifier the moment monitoring is active.
  • Failing storage hardware. Uncommon, but a dying storage controller can generate erratic I/O patterns that Verifier reads as a driver violation.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Check whether Verifier is running — and switch it off

This ends the problem outright when Verifier was enabled by mistake.

  1. Press Win + R, type verifier, and press Enter.
  2. If the dialog reports “No drivers are currently verified,” Verifier is idle — skip ahead to Fix 3, since the violation is genuine or something switched it back on.
  3. If drivers appear as verified, choose Delete existing settings, click Finish, and restart. Alternatively, launch an elevated Command Prompt, run verifier /reset, and restart.
  4. Use the laptop normally for a while. If no more crashes occur, Verifier was the whole story — a testing harness accidentally left running on a production machine, failing drivers that run perfectly well in normal use.

Fix 2: Reach Safe Mode when boot loops block the desktop

Since Verifier monitors drivers from startup, its crashes can trap you in a boot loop.

  1. Interrupt the boot three times in a row — press and hold the power button while the logo is showing — to force the Windows Recovery Environment.
  2. Open Troubleshoot, pick Advanced options, then Startup Settings; after the restart, press 4 for Safe Mode. Verifier’s monitoring is effectively dormant there, so you should reach a stable desktop.
  3. Once inside, open an elevated Command Prompt, run verifier /reset, and restart into normal mode.

Fix 3: Identify the offending driver

If Verifier was enabled on purpose — or crashes persist with it off — hunt down the guilty module.

  1. Press Win + X, open Event Viewer, and look under Windows Logs > System.
  2. Open the BugCheck entry from the crash. Its parameters and the “What failed: something.sys” line on the blue screen itself name the module.
  3. Match that filename to its product. I/O filter drivers from security or backup tools, network stacks, and USB drivers top the list of repeat offenders.
  4. The 24H2-focused guide for this violation carries extra build-specific driver notes if that is the build you are running.

Fix 4: Update, roll back, or uninstall the culprit driver

Address the actual violation rather than the messenger.

  1. Press Win + X, open Device Manager, and locate the device tied to your suspect .sys file.
  2. Right-click the entry, select Update driver, and choose Search automatically for drivers. If the trouble began with the update itself, go to Properties > Driver and pick Roll Back Driver instead.
  3. When the driver ships with third-party software (antivirus, VPN, disk utilities), remove the entire application from Settings > Apps > Installed apps — filter drivers rarely recover from a plain driver update.
  4. Download the newest release from the vendor or your laptop maker’s support site, install it, and restart.
  5. Related Verifier-caught faults such as driver verifier detected violation on 24H2 respond to the same identify-and-replace approach.

Fix 5: Briefly uninstall the latest update as a diagnostic

Prove that the update is what altered the driver’s behavior.

  1. Open Settings, go to Windows Update > Update history > Uninstall updates.
  2. Take out the latest update and restart.
  3. If the violations cease, get the newest driver release from the manufacturer’s site before putting the Windows update back.

Fix 6: Repair system files and assess the drive’s health

Make sure the I/O stack itself is free of corruption.

  1. Start a Command Prompt with administrator rights.
  2. Run sfc /scannow, followed by DISM /Online /Cleanup-Image /RestoreHealth.
  3. Scan the disk with chkdsk C: /f (answer Y to schedule it, then restart to let it run).
  4. In PowerShell (Admin), check physical health: Get-PhysicalDisk | Select FriendlyName, HealthStatus, OperationalStatus. Persistent I/O violations on a degraded drive point at the storage hardware rather than any driver.

Fix 7: Reset Windows when the violations refuse to stop

The final software-side step.

  1. Back up your personal files first.
  2. In Settings, open System > Recovery > Reset PC, then choose Remove everything with a Cloud download.
  3. After setup completes, pull the latest drivers from the laptop manufacturer’s support site and test stability before reinstalling third-party software — especially the security or encryption product whose filter driver was implicated.
  4. If Verifier-style crashes appear even on a pristine system, suspect the storage controller or the motherboard. Microsoft’s Windows support hub has full documentation on the reset and recovery options.

Closing

Most of the time this entire ordeal ends the moment you discover Verifier was left switched on and turn it off with verifier /reset. When the violation is authentic, the crash itself hands you the driver’s name — refresh it, revert it, or remove the software that shipped it. Treat this blue screen as a thorough inspector rather than a mystery: it is pointing at something concrete, and the remedy sits on the software side in nearly every case.

Frequently asked questions

What is DRIVER_VERIFIER_IOMANAGER_VIOLATION?
It is stop code 0x000000C9, a blue screen that appears only while Driver Verifier — Windows’ built-in driver stress-testing tool — is actively monitoring your drivers. Verifier deliberately crashes the machine when a driver breaks the I/O manager’s rules. After an update, it usually means Verifier was left switched on and is now grading an older driver against the new build’s stricter rules.
I never turned on Driver Verifier. Why am I getting this error?
Verifier can be enabled silently by driver installers, manufacturer utilities, or earlier troubleshooting sessions, and the setting survives across updates. Begin by running verifier to open the dialog and see whether any drivers are being monitored. If so, choose Delete existing settings — or run verifier /reset from an elevated Command Prompt — and restart. Most people find the crashes stop immediately.
Should I just disable Driver Verifier and ignore it?
Only when Verifier was switched on by accident. If a technician or diagnostic tool enabled it on purpose to hunt crashes, the violation it reports is genuine — a driver really is mishandling I/O requests. In that case, switching Verifier off merely hides the evidence while the bug survives; note the named .sys file and repair or replace that driver instead of blaming the tool.
Which drivers usually cause this violation?
Antivirus, disk-encryption, and backup software install I/O filter drivers, and those are the most frequently flagged modules — network adapter and USB device drivers come next. The blue screen typically names the failing .sys file, and the BugCheck entry in Event Viewer records the same detail. That filename identifies exactly which vendor’s product you need to update, roll back, or uninstall.