Our companion guide covers the emergency: turning off Driver Verifier and stopping the crash loop . This one is for after the bleeding stops — the methodical work of proving which driver is guilty, understanding what it did wrong, and verifying the fix. Think of it as the detective work that turns a one-time recovery into a permanent resolution.

You’ll need the crash dump files from C:\Windows\Minidump and, ideally, WinDbg Preview from the Microsoft Store. None of this requires a debugger expert — just patience.

Why this happens

  • A driver completes the same IRP twice. Double-completion corrupts the I/O manager’s state.
  • A driver never completes an IRP. Leaked requests hang the I/O path.
  • A driver touches an IRP after completing it. Use-after-free in the I/O stack.
  • Incorrect stack location handling. The driver mismanages the next driver’s stack slot.
  • Filter driver conflicts. Antivirus and disk-utility filters intercepting IRPs incorrectly.
  • Legacy drivers on modern Windows. Old drivers predate current I/O rules.
  • Verifier’s special pool exposing buffer bugs. Overruns that silently corrupt memory normally get caught under Verifier.

How to fix it

Work through these in order — each step builds evidence.

Fix 1: Preserve and examine the crash dumps

Evidence first — dumps get overwritten.

  1. Open C:\Windows\Minidump and copy the .dmp files from the C9 crashes to a safe folder (dumps recycle, keeping only the most recent few).
  2. Note the timestamps — match them to the crash events in Event Viewer > Windows Logs > System (source BugCheck).
  3. Record the BugCheck parameters shown in Event Viewer: parameter 1 identifies the specific violation type.
  4. Common parameter-1 values: 0x1 (IRP completed twice), 0x3 (IRP not completed), 0x7 (freed IRP touched) — these tell you what the driver did wrong.
  5. Install WinDbg Preview from the Microsoft Store for the deep analysis in Fix 2.
  6. Keep at least two dumps — one to analyze, one as a backup in case symbols misbehave.

Fix 2: Analyze the dump in WinDbg

Get the definitive answer.

  1. Open WinDbg Preview and use File > Open dump file to load your saved .dmp.
  2. Wait for the initial analysis, then run: !analyze -v
  3. Read the output: MODULE_NAME and IMAGE_NAME name the faulting driver, and the stack trace shows the exact call path.
  4. Run lmvm <drivername> (e.g., lmvm rtwlane) to see the driver’s version, timestamp, and vendor.
  5. An old timestamp (several years) on a currently-crashing driver is a strong signal — that driver predates modern I/O expectations.
  6. Screenshot or save the analysis — you’ll want it when contacting the vendor or comparing after a fix.

Fix 3: Map the driver to its device and vendor

Turn a file name into an actionable target.

  1. Take the IMAGE_NAME from WinDbg (e.g., somefilter.sys).
  2. In Device Manager, use View > Devices by driver or search the driver’s .inf name.
  3. For filter drivers, check fltmc in an elevated terminal — it lists all file-system filter drivers and their altitudes.
  4. Identify the owning software: antivirus, disk encryption, backup tools, and peripheral utilities are the usual filter-driver sources.
  5. Check the vendor’s support site for a newer version — specifically look for release notes mentioning I/O, IRP, or Verifier fixes.
  6. If the vendor is obscure or the driver is abandoned, plan to remove the software rather than patch it.

Fix 4: Update, replace, or remove the guilty driver

Act on the evidence.

  1. Install the vendor’s latest driver for the exact device and Windows build.
  2. For filter drivers, update the parent application (antivirus, encryption, backup) — the driver ships with it.
  3. If no update exists, uninstall the owning software and test with Windows’ built-in alternatives (Defender, BitLocker).
  4. For inbox Windows drivers flagged by Verifier (rare), run: DISM /Online /Cleanup-Image /RestoreHealth sfc /scannow then reinstall the latest servicing updates.
  5. Hardware vendors’ driver portals (Intel , NVIDIA ) — plus your laptop maker’s support site for validated builds.
  6. Restart and run normally for several days before declaring victory.

Fix 5: Verify the fix with a targeted Verifier run

Prove the fix — don’t just hope.

  1. With the system stable for days, run verifier.exe.
  2. Choose Create custom settings, tick only I/O Verification (and optionally Special Pool).
  3. Choose Select driver names from a list and tick ONLY the previously-guilty driver.
  4. Finish, restart, and exercise the driver hard — copy large files for storage filters, run scans for antivirus filters.
  5. No crash after thorough exercise = verified fix. Any C9 = the bug persists; return to Fix 4.
  6. Immediately run verifier /reset and restart afterward. Targeted verification is still Verifier — don’t leave it on.

Fix 6: Harden against recurrence

Make sure the next update doesn’t reintroduce the bug.

  1. Note the exact working driver version (Device Manager > Properties > Driver).
  2. In Settings > Windows Update > Advanced options, consider pausing driver updates via optional updates if Windows Update previously installed the bad driver.
  3. For critical machines, use the Show or hide updates troubleshooter approach to block the specific bad driver version.
  4. Keep a copy of the known-good driver installer — vendors remove old versions.
  5. Document the whole episode: driver name, versions, dump analysis summary. Future-you will thank present-you.
  6. Microsoft’s driver guidance on support.microsoft.com covers managing driver updates on Windows 11.

Fix 7: Escalate to the vendor with evidence

When the vendor needs to fix their driver.

  1. Collect: WinDbg !analyze -v output, driver version, Windows build (winver), and repro steps.
  2. File a bug with the hardware/software vendor’s support — attach the analysis, not just “it crashes.”
  3. Mention the specific violation (double IRP completion, etc.) — it tells their engineers exactly where to look.
  4. Ask whether a beta driver with the fix exists.
  5. Meanwhile, keep the workaround from Fix 4 in place.
  6. If the vendor is unresponsive and the driver is non-essential, permanent removal is a valid engineering decision — a missing feature beats a crashing system. For related driver-crash diagnosis, our DRIVER_IRQL guide covers the non-Verifier side.

Closing

Troubleshooting a Verifier crash properly means treating the dump as evidence, not noise: preserve it, read it, map the driver, fix it, then prove the fix with a targeted Verifier run. Most people stop at “Verifier off, crashes gone” — and most of the time that’s fine. But when the same driver bites again after an update, the hour you spent in WinDbg pays for itself ten times over. Verifier caught a real bug; finishing the job means making sure it stays caught.

Frequently asked questions

I already disabled Verifier and the crashes stopped. Do I need this guide?
If the system is stable, the immediate emergency is over. But Verifier flagged a genuine driver bug — this guide shows you how to confirm which driver, verify the fix actually addressed it, and make sure it doesn’t resurface with the next driver update.
Do I need WinDbg to troubleshoot this properly?
For a definitive answer, yes — WinDbg Preview (free in the Microsoft Store) reads the crash dump and names the exact driver and IRP violation. Event Viewer’s BugCheck entry gives you a strong hint, but the dump gives you proof.
What does 'IOMANAGER_VIOLATION' actually check?
Verifier’s I/O Verification watches how drivers handle I/O Request Packets: completing requests twice, forgetting to complete them, touching freed IRPs, or mismanaging the I/O stack. A C9 crash means the driver broke one of these hard rules.
Can Verifier produce false positives?
Rarely for I/O violations — the checks are precise. What happens more often is that Verifier’s stress exposes timing bugs that don’t manifest in normal use. The driver is still buggy; it’s just buggy in a way you’d rarely hit without Verifier.