Exit a Driver Verifier blue-screen boot loop and preserve the offending-driver evidence

Driver Verifier was intentionally enabled and Windows now crashes during every normal start. This is not proof that Driver Verifier damaged Windows. Verifier adds checks to selected kernel drivers and deliberately stops the system when it detects a violation so that a dump can identify the faulty code. The immediate repair is to preserve any dump, disable Verifier, regain a stable boot, and then act only on the driver the evidence identifies.

Searchable Windows error codes and exact messages

The blue screen may also display What failed: <driver>.sys. Preserve that exact filename and the dump. ntoskrnl.exe, VerifierExt.sys, or a Microsoft framework at the top of a stack is not automatically the faulty third-party driver.

Use this procedure when Driver Verifier was knowingly enabled shortly before the loop or verifier /querysettings had shown active rules. It also applies when the stop screen or dump explicitly reports Verifier activity.

Do not assume Driver Verifier is active merely because the code is 0xD1, 0x7E, or 0x139. Those codes occur without Verifier. Use the general named-driver procedure when Verifier was never enabled and the evidence points to a driver.

The precise defective code path and Windows build may remain unknown initially. Whether Verifier is active, which drivers it was configured to verify, the stop code, and whether a dump was written may not remain unknown.

• Windows Recovery Environment and Startup Settings
• Administrator credentials for Safe Mode
• A destination for copied dump files
• The computer or device manufacturer's supported replacement driver, if one is identified
• A restore point is strongly preferred before any future Verifier session

Stop repeated normal boot attempts. Enter WinRE, select Troubleshoot > Advanced options > Startup Settings > Restart, and choose Enable Safe Mode. If Safe Mode immediately crashes, proceed to the System Restore branch rather than editing the offline registry blindly.

1. Photograph the complete blue screen and record the named .sys file.

2. If Safe Mode starts, open an elevated Command Prompt and query Verifier:

   verifier /querysettings
   

3. Save the output before resetting it:

   md C:\VerifierRecovery
   verifier /querysettings > C:\VerifierRecovery\verifier-settings-before-reset.txt
   

4. Preserve dumps if present:

   copy C:\Windows\Minidump\*.dmp C:\VerifierRecovery\
   copy C:\Windows\MEMORY.DMP C:\VerifierRecovery\
   

   It is normal for one of these locations not to exist. Do not erase dumps during cleanup.

5. Record the selected drivers from the query. If all drivers were selected, note that the test was unnecessarily broad and may produce noise or an immediate loop.

6. If Safe Mode does not start, enter WinRE Command Prompt, detect the Windows volume as W:, and copy dumps to another writable volume before restoring:

   dir W:\Windows\Minidump
   copy W:\Windows\Minidump\*.dmp <destination>\
   copy W:\Windows\MEMORY.DMP <destination>\
   

Branch A — Safe Mode starts

1. Preserve the evidence as described above.

2. Reset all Driver Verifier settings from the Safe Mode installation:

   verifier /reset
   

3. Restart normally. The reset takes effect after restart.

4. Once Windows starts, confirm that no driver remains selected:

   verifier /querysettings
   

5. Analyze the preserved dump with WinDbg. Use !analyze -v, then record MODULE_NAME, IMAGE_NAME, FAILURE_BUCKET_ID, the violated rule, and the stack. A named third-party driver plus a coherent stack is stronger than the stop screen alone.

6. Identify the owning package:

   driverquery /v /fo csv > C:\VerifierRecovery\driverquery.csv
   pnputil /enum-drivers > C:\VerifierRecovery\third-party-driver-packages.txt
   

7. Prefer this repair order for the demonstrated driver:

   1. Roll back a driver installed immediately before the problem.
   2. Install the computer or device vendor's corrected driver.
   3. Uninstall the owning third-party application when it installs a filter driver.
   4. Remove the specific package only after its published oem#.inf identity is confirmed.

8. If removal is necessary, export the package first:

   pnputil /export-driver <oem-number.inf> C:\VerifierRecovery\DriverBackup
   pnputil /delete-driver <oem-number.inf> /uninstall
   

9. Restart twice and confirm stability before considering a narrowly targeted Verifier retest.

Branch B — Safe Mode does not start

1. Use Troubleshoot > Advanced options > System Restore and select the restore point created before Driver Verifier was enabled.

2. Let System Restore complete and restart normally.

3. If no restore point exists, use WinRE's Uninstall Updates only when an update—not the act of enabling Verifier—immediately preceded the loop.

4. Do not rely on verifier /reset typed at an arbitrary WinRE command prompt as proof the offline Windows installation was reset; WinRE is a separate running Windows environment.

5. If neither Safe Mode nor System Restore is available, escalate to an offline-registry recovery performed against the detected control set with a full hive backup. That specialist operation is not included here because deleting guessed Verifier values from the wrong control set can leave the loop unchanged or damage unrelated configuration.

Branch C — Plan a safer diagnostic retest

1. Do not re-enable Verifier until Windows is stable and all dumps are archived.

2. Create a restore point and confirm that WinRE and Safe Mode work.

3. Select only the demonstrated or genuinely suspect non-Microsoft driver or the smallest relevant set.

4. Configure a crash dump and confirm free space before restarting.

5. Never use a broad Verifier session on a production-only computer without a tested recovery path.

• verifier /reset followed by restart ends the loop: Verifier was the trigger. The dump still matters; reset does not exonerate the driver.
• The loop continues but the stop code changes: Driver Verifier may have exposed a driver that now fails without Verifier, or a second failure exists. Analyze the new dump.
• No dump exists: Confirm page-file and dump configuration after recovery; do not rerun Verifier until dump capture works.
• The dump consistently names one third-party module: Update, roll back, or remove its owning package.
• Different modules fail in different dumps: Suspect unstable RAM, overclocking, storage corruption, or a lower filter before removing many unrelated drivers.

• Do not delete .sys files manually.
• Do not enable every Verifier option for every driver on a daily-use computer.
• Do not blame ntoskrnl.exe merely because it appears in the crash stack.
• Do not discard the dump before resetting Verifier.
• Do not use /force when deleting a driver package unless a separately reviewed recovery plan requires it.
• Do not leave safeboot set persistently in BCD.

System Restore is the primary rollback for changes made by a driver update or removal. An exported third-party package can be re-added if it is known good and still appropriate:

pnputil /add-driver C:\VerifierRecovery\DriverBackup\<driver.inf> /install

Do not restore a demonstrated faulty driver merely to reproduce the loop on the only usable installation.

• Windows starts normally twice and once from a cold start.
• verifier /querysettings shows that no unintended Verifier configuration is active.
• Dumps and the pre-reset query are preserved.
• The named third-party driver has been updated, rolled back, or removed through its package.
• Device Manager shows no unexplained critical device loss.
• A new Verifier run is not started until a restore point and working dump configuration are verified.

Confidence is high when Verifier is shown active and resetting it ends the loop. Confidence that a particular driver is defective is high only when the dump identifies it coherently, preferably more than once. Stop if Safe Mode crashes, no restore path exists, the dump implicates a boot-critical storage driver, or different modules fail randomly.