Recover a startup blue screen caused by a proven third-party boot driver or filter

A specific non-Microsoft boot-start driver, file-system filter, antivirus filter, VPN/network filter, storage filter, virtualization driver, monitoring utility, RGB/control utility, or similar kernel component causes Windows to crash during startup. This writeup applies only after the driver identity is supported by the blue screen, repeated dumps, Startup Repair log, or a very tight install/uninstall timeline.

Searchable Windows error codes and exact messages

Search the stop code and exact What failed: <driver>.sys name together. The same stop code can have non-driver causes. A Windows component in the stack may be the victim of earlier corruption.

Use this procedure when one third-party driver is consistently identified, Safe Mode changes the behavior, or the failure began immediately after installing or updating the exact owning device/application.

Do not use it when different dumps name unrelated drivers, the only named module is a generic Windows kernel component, memory is unstable, the disk has I/O errors, or the candidate is a boot-critical storage driver required to see the Windows volume. RAID/VMD/IRST and specialist storage filters remain deferred.

The defective source line may remain unknown. The exact .sys name, owning vendor/product, driver-store published name, service name, current Start value, and rollback package may not remain unknown before offline removal or disablement.

• Preserved crash dumps or equivalent causal evidence
• WinRE and Safe Mode
• Administrator access
• A verified backup or restore point
• The supported replacement package or an exported copy of the current package
• Exact identification of the driver and owning service

Try Safe Mode first. If it starts, use supported application/device uninstall and driver-package tools. Offline service disablement is a last-resort branch for one proven non-Microsoft component, not a discovery method.

1. Preserve at least the newest dump and preferably two or more:

   md C:\BootCrashEvidence
   copy C:\Windows\Minidump\*.dmp C:\BootCrashEvidence\
   copy C:\Windows\MEMORY.DMP C:\BootCrashEvidence\
   

2. Analyze dumps with !analyze -v. Record the named image, module, failure bucket, stack, and whether the same third-party module recurs.

3. Enumerate third-party packages and services:

   pnputil /enum-drivers > C:\BootCrashEvidence\third-party-drivers.txt
   driverquery /v /fo csv > C:\BootCrashEvidence\driverquery.csv
   sc query type= driver state= all > C:\BootCrashEvidence\driver-services.txt
   

4. Match the .sys file to its product, provider, service, and published oem#.inf. Confirm digital-signature and file-version information.

5. Review the install/update timeline. A driver installed immediately before the first failed boot strengthens the mapping but does not replace dump evidence.

6. If Safe Mode does not start, detect W: in WinRE and inspect offline packages:

   dism /Image:W:\ /Get-Drivers /Format:Table
   

7. Stop if the candidate package is Microsoft inbox, its identity is ambiguous, it controls access to the boot disk, or multiple unrelated modules fail.

Branch A — Remove or roll back through the owning product in Safe Mode

1. Disconnect from the network temporarily if Windows Update would immediately reinstall the same driver.

2. If Device Manager offers Roll Back Driver and the failure began with that update, use it.

3. For antivirus, VPN, backup, encryption, virtualization, RGB, monitoring, or filter software, prefer the vendor's supported uninstaller. Removing only the visible device can leave the boot filter service registered.

4. Restart normally once.

5. Install a corrected vendor-supported version only after normal startup is stable.

Branch B — Remove one exact third-party driver package in Safe Mode

1. Export the identified package:

   md C:\BootCrashEvidence\DriverBackup
   pnputil /export-driver <oem-number.inf> C:\BootCrashEvidence\DriverBackup
   

2. Confirm the export succeeded and contains the expected INF and files.

3. Remove the exact published package and uninstall it from devices:

   pnputil /delete-driver <oem-number.inf> /uninstall
   

4. Do not add /force by default.

5. Restart and test. Windows may use an inbox fallback driver for the device.

Branch C — Remove the exact package from the offline Windows image

1. In WinRE, detect the Windows volume as W:.

2. List third-party packages and record the candidate's published name, provider, class, date, and version:

   dism /Image:W:\ /Get-Drivers /Format:Table
   dism /Image:W:\ /Get-DriverInfo /Driver:<oem-number.inf>
   

3. Remove only the proven package:

   dism /Image:W:\ /Remove-Driver /Driver:<oem-number.inf>
   

4. Record DISM's result and restart once.

5. If the same crash returns, do not remove additional packages without new evidence.

Branch D — Disable one proven non-Microsoft driver service offline

Use this only when the owning application cannot be uninstalled offline, the service identity is exact, the driver is not required for boot-disk access, and a full SYSTEM-hive backup exists.

1. Back up the offline SYSTEM hive:

   md W:\BootRepairBackup\DriverFilter
   copy W:\Windows\System32\Config\SYSTEM W:\BootRepairBackup\DriverFilter\SYSTEM.before-driver-disable
   

2. Load the hive:

   reg load HKLM\OFFSYS W:\Windows\System32\Config\SYSTEM
   

3. Find the active control set number:

   reg query HKLM\OFFSYS\Select
   

   If Current is 0x1, use ControlSet001; if 0x2, use ControlSet002.

4. Query and export the exact service key:

   reg query HKLM\OFFSYS\ControlSet00<number>\Services\<service-name> /s
   reg export HKLM\OFFSYS\ControlSet00<number>\Services\<service-name> W:\BootRepairBackup\DriverFilter\<service-name>.reg
   

5. Confirm ImagePath names the demonstrated third-party driver and record the original Start value. 0 means boot-start, 1 system-start, 2 automatic, 3 demand, and 4 disabled.

6. Disable only that service:

   reg add HKLM\OFFSYS\ControlSet00<number>\Services\<service-name> /v Start /t REG_DWORD /d 4 /f
   

7. Unload the hive before restarting:

   reg unload HKLM\OFFSYS
   

8. Start Windows, preserve new evidence, and uninstall or update the owning product properly. Offline disablement is containment, not final package cleanup.

• The system starts after product uninstall or package removal: The driver path is strongly implicated.
• The device loses functionality but Windows starts: Install a corrected supported package after stability is verified.
• The crash persists with the same module: The package may not have been the loaded copy, another service may load it, or the module may be the victim. Re-analyze.
• The crash changes to 0x7B: Restore the driver/service immediately; a storage-path dependency was removed.
• Different modules now fail: Stop driver removals and test RAM/storage.

• Do not rename or delete .sys files manually.
• Do not remove every old oem#.inf package.
• Do not disable Microsoft inbox services through this procedure.
• Do not disable a storage, encryption, or volume filter without proving Windows can access the boot volume without it.
• Do not use pnputil /force merely because normal removal refuses.
• Do not use the offline-registry branch when the service name or active control set is uncertain.

If offline disablement causes a new failure, reload the hive and restore the recorded Start value:

reg load HKLM\OFFSYS W:\Windows\System32\Config\SYSTEM
reg add HKLM\OFFSYS\ControlSet00<number>\Services\<service-name> /v Start /t REG_DWORD /d <original-value> /f
reg unload HKLM\OFFSYS

Alternatively restore the backed-up SYSTEM hive only when no other registry changes must be retained. Re-add an exported package with pnputil /add-driver <path-to-inf> /install after Windows starts.

• Windows starts normally twice and cold-starts once.
• No new dump names the removed or corrected driver.
• The owning application's services and filters are no longer left in a broken partial state.
• Device functionality is tested with the corrected or inbox driver.
• Event Viewer and Reliability Monitor show no recurrence.
• The original dumps, package export, service key, and change log remain archived.

Confidence is high with repeated coherent dumps plus a successful targeted removal or rollback. It is moderate with one strong dump and an exact install timeline. Stop when the candidate is boot-storage-critical, its identity is ambiguous, dumps vary randomly, hardware is unstable, or specialist RAID/VMD/IRST components are involved.