Resolve SYSTEM_THREAD_EXCEPTION_NOT_HANDLED during Windows startup

A kernel system thread raised an exception that Windows did not handle. The useful evidence is not just SYSTEM_THREAD_EXCEPTION_NOT_HANDLED; it is the exception code in parameter 1, the faulting address in parameter 2, the named driver if shown, and the dump's stack. Startup cases are commonly caused by a driver loaded early in boot, but memory corruption and hardware instability can produce misleading module names.

Searchable Windows error codes and exact messages

Search the bug-check name, parameter 1, and the exact What failed: filename together. A named driver is a lead, not proof, unless the faulting instruction and stack support it.

Use this procedure when Windows reaches kernel startup and displays 0x7E or 0x1000007E, especially when a driver, recent device, driver update, security product, virtualization product, or low-level utility is named.

Do not use it for a Recovery-screen status code that only resembles a bug check, for 0x7B INACCESSIBLE_BOOT_DEVICE, or when the same crash occurs while booting independent Windows installation media. A crash in independent media moves RAM, CPU, firmware, and motherboard instability ahead of the installed Windows driver set.

The exact source line and Windows build may remain unknown. The full bug-check parameters, named module, recent change, whether Safe Mode starts, and whether independent media also crashes may not remain unknown.

• WinRE and Startup Settings
• A destination for dump and log backups
• Administrator access if Safe Mode starts
• WinDbg or equivalent dump-analysis capability
• Supported replacement drivers from the computer or device manufacturer

Enter WinRE and try Startup Settings > Enable Safe Mode once. Preserve crash dumps before uninstalling or updating anything. Disconnect only nonessential external devices; do not disconnect the keyboard, required input, system disk, or a device needed to access recovery.

1. Photograph the screen and record all four parameters plus What failed:.

2. If Safe Mode starts, create an evidence folder and copy dumps:

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

3. Record recent driver packages and system information:

   pnputil /enum-drivers > C:\BootCrashEvidence\third-party-drivers.txt
   driverquery /v /fo csv > C:\BootCrashEvidence\driverquery.csv
   msinfo32 /nfo C:\BootCrashEvidence\system.nfo
   

4. Analyze the newest dump with WinDbg and run:

   !analyze -v
   

5. Record the exception code, faulting instruction address, MODULE_NAME, IMAGE_NAME, FAILURE_BUCKET_ID, and the first non-Microsoft driver in the relevant stack.

6. Compare at least two dumps when available. The same third-party module and similar stack increase confidence. Changing modules and changing codes reduce confidence and move memory or general instability higher.

7. If Safe Mode does not start, detect the offline Windows volume in WinRE and copy dumps from W:\Windows\Minidump or W:\Windows\MEMORY.DMP.

8. Boot current Windows installation media once. If the media itself produces 0x7E, stop altering the installed Windows copy and test hardware and firmware defaults.

Branch A — One third-party driver is coherently identified

1. Determine the device or application that owns the .sys file. Use the dump, file properties, Device Manager, and pnputil /enum-drivers; do not identify by filename resemblance alone.

2. In Safe Mode, first roll back a driver installed immediately before the failure, or uninstall the owning application when it installed a file-system, network, antivirus, VPN, RGB, monitoring, virtualization, or other filter driver.

3. If an updated driver is appropriate, obtain it from the computer, motherboard, or device manufacturer and install it.

4. If the exact published package must be removed, export it first:

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

5. Restart twice and collect a new dump if the crash returns.

Branch B — Safe Mode does not start after a recent driver or application change

1. Use System Restore to return to the restore point before the change.

2. If there is no restore point but the exact third-party package is known, inspect the offline driver store:

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

3. Confirm provider, class, date, version, and published name. Remove only the demonstrated third-party package:

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

4. Do not remove an inbox driver or a boot-critical storage driver through this general branch.

Branch C — No stable driver identity

1. Restore firmware CPU and memory settings to documented defaults. Disable XMP/EXPO and CPU/GPU overclocking for diagnosis.

2. Run the memory-isolation procedure in FIX-028 if modules or bug checks vary.

3. Check the system disk and file system without immediately forcing repairs:

   chkdsk W: /scan
   

   From WinRE, if /scan is unavailable, begin with read-only chkdsk W:.

4. When storage is stable, run offline SFC:

   sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows
   

5. Re-test after each single change. Do not combine a firmware update, five driver updates, memory changes, and file repairs into one untraceable attempt.

• Removing or rolling back one named driver stops the crash: The driver path is the probable cause.
• Safe Mode works but normal mode fails: A nonessential driver or service loaded only in normal mode is likely.
• Different dumps name unrelated modules: Test RAM and firmware defaults before deleting more drivers.
• Independent media also crashes: Treat this as hardware or firmware instability until disproven.
• The code changes to a stable, more specific bug check: Follow that code and its parameters rather than forcing the 0x7E theory.

• Do not manually delete the named .sys file.
• Do not assume the first module listed is the cause.
• Do not download individual driver files from third-party DLL/SYS sites.
• Do not enable Driver Verifier broadly on an already unstable production system.
• Do not update firmware while memory or power is demonstrably unstable.
• Do not interpret 0xc0000005 as a file-permission error.

Use System Restore or reinstall the exported driver package if the targeted removal was incorrect and the driver is known good:

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

Restore only documented firmware settings. Do not restore an unstable memory profile merely to reproduce the failure.

• Windows starts normally twice and cold-starts once.
• No new 0x7E or 0x1000007E dump is created.
• Device Manager has no unexplained critical device errors.
• The repaired or removed component's function is tested.
• Event Viewer and Reliability Monitor show no related recurrence under normal workload.
• The evidence folder contains the original dumps and change record.

Confidence is high when repeated dumps identify the same third-party driver and removing or correcting it ends the crash. Confidence is moderate with one coherent dump. Stop if independent media crashes, storage is unstable, the named module changes repeatedly, or the only implicated component is a boot-critical storage driver without a tested replacement.