SYSTEM_THREAD_EXCEPTION_NOT_HANDLED 0x0000007E on Windows 10 and 11

Fix it now

0x0000007E means a system thread generated an exception the error handler did not catch. Parameter 1 is the exception code and parameter 2 is the address it happened at, which is why two machines showing the same stop code can have entirely different causes. If a .sys file is named on the screen, that is where you start.

!analyze -v
sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

1. Photograph the blue screen. The driver name, if there is one, and parameter 1 are both worth more than anything you can work out afterwards.
2. Get into Safe Mode: reach the Windows Recovery Environment, then Troubleshoot, Advanced options, Startup Settings, Restart, and press 4 for Safe Mode or 5 for Safe Mode with Networking.
3. In Safe Mode open Device Manager, find the device that owns the named driver – display adapters first – open Properties, Driver, and use Roll Back Driver if it is available.
4. If Roll Back is greyed out, uninstall the device with ‘Attempt to remove the driver for this device’ ticked, reboot, then install the current driver from the hardware vendor rather than letting Windows Update choose.
5. If no driver was named, open the newest file in %SystemRoot%\Minidump with WinDbg and run !analyze -v.

To get out of Safe Mode if the machine stays there: Windows key + R, run msconfig, Boot tab, and clear the Safe boot checkbox.

If the machine is stable after the driver is replaced, stop here. If a different module is blamed every time, the next section explains what parameter 1 is telling you.

Why it happens

Kernel-mode code uses structured exception handling just as user-mode code does, but the consequences differ. In user mode an unhandled exception kills one process. In kernel mode there is no containing boundary, so the kernel raises a bug check rather than continue past a fault it cannot reason about.

Microsoft’s instruction for 0x7E is unusually direct: to interpret it, you must identify which exception was generated. Parameter 1 is that exception code. Three appear repeatedly and Microsoft lists them on every one of these pages – 0x80000002 STATUS_DATATYPE_MISALIGNMENT, an unaligned data reference; 0x80000003 STATUS_BREAKPOINT, a breakpoint or ASSERT hit with no kernel debugger attached; and 0xC0000005 STATUS_ACCESS_VIOLATION, a memory access violation. Parameter 2 is the address where the exception occurred, which is what resolves the crash back to a loaded module.

The companions are the same event caught at different points, and their parameters differ. 0x0000008E is KERNEL_MODE_EXCEPTION_NOT_HANDLED, where parameter 3 is the trap frame. 0x0000001E is KMODE_EXCEPTION_NOT_HANDLED, where parameters 3 and 4 carry exception information from the exception record, and for a 0xC0000005 parameter 4 is the address the driver tried to access. 0x0000003B is different in kind: SYSTEM_SERVICE_EXCEPTION, an exception while executing a routine that transitions from non-privileged code to privileged code.

Full reference

The four bug checks and their parameters

Exception codes worth recognising

Microsoft points at Ntstatus.h in the Windows Driver Kit for the full list. In practice 0xC0000005 covers the large majority and tells you the fault is a bad address rather than anything exotic.

Getting into Safe Mode, and out again

1. Reach the Windows Recovery Environment – from Settings where Windows still starts, or by letting a failing machine fall into it.
2. Troubleshoot, then Advanced options, then Startup Settings, then Restart.
3. Press 4 for Safe Mode, or 5 for Safe Mode with Networking if you need to download a driver.
4. To leave Safe Mode if the machine keeps returning to it: Windows key + R, msconfig, Boot tab, clear the Safe boot checkbox, and restart.

Getting a dump you can read

• Settings, System, About, Advanced system settings, Startup and Recovery: set Write debugging information to a small memory dump or an automatic memory dump.
• Minidumps land in %SystemRoot%\Minidump. Take the newest one, and keep the older ones – a pattern across several dumps is worth more than one reading.
• !analyze -v first, then the stack. The module !analyze blames is a starting point, not a verdict.
• If the machine reboots too fast to read the screen, turn off automatic restart in the same Startup and Recovery dialog.

When it is not a single driver

• Repair the system files and the component store, then retest before doing anything else.
• Test memory with the built-in Windows Memory Diagnostic and with the manufacturer’s diagnostics where they exist.
• Take any overclock or memory profile back to defaults for the duration of the test.
• Check the System log for storage or firmware errors in the same window – a failing disk produces exceptions in whichever driver happens to be reading at the time.
• Check for firmware updates for the machine itself. Microsoft lists BIOS incompatibility among the causes for this family.

Every code this article covers

Confirm the fix worked

1. The machine survives the workload that used to crash it, with no new file in %SystemRoot%\Minidump.
2. Device Manager shows the driver at the version you installed rather than one Windows Update replaced.
3. fltmc no longer lists a minifilter from a product you removed.
4. The System log is clean for the same period, not just the desktop.

Questions people ask about this