| Previous | Next |
| INSTALL_MORE_MEMORY | UNEXPECTED_KERNEL_MODE_TRAP |
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED
The SYSTEM_THREAD_EXCEPTION_NOT_HANDLED bug check has a value of 0x0000007E. This bug check indicates that a system thread generated an exception that the error handler did not catch.
Important
This topic is for programmers. If you are a customer who has received a blue screen error code while using your computer, see Troubleshoot blue screen errors.
SYSTEM_THREAD_EXCEPTION_NOT_HANDLED parameters
| Parameter | Description |
|---|---|
1 |
The exception code that was not handled. |
2 |
The address where the exception occurred. |
3 |
The address of the exception record. |
4 |
The address of the context record. |
Cause
This bug check indicates that a system thread generated an exception that the error handler did not catch. To interpret it, you must identify which exception was generated.
Common exception codes include the following:
0x80000002: STATUS_DATATYPE_MISALIGNMENT indicates an unaligned data reference was encountered.
0x80000003: STATUS_BREAKPOINT indicates a breakpoint or ASSERT was encountered when no kernel debugger was attached to the system.
0xC0000005: STATUS_ACCESS_VIOLATION indicates a memory access violation occurred.
For a complete list of exception codes, see NTSTATUS values. The exception codes are defined in ntstatus.h, a header file provided by the Windows Driver Kit. (For more info, see Header files in the Windows Driver Kit).
Resolution
If you plan to debug this problem, the exception address (parameter 2) should identify the driver or function that caused this problem.
If a driver is listed by name within the bug check message, disable or remove that driver. If the issue is narrowed down to a single driver, set breakpoints and single-step forward in code to locate the failure and gain insight into events leading up to the crash.
The !analyze debugger extension displays information about the bug check and can be helpful in determining the root cause.
Additional analysis can be done by using the !thread extension, as well as the dds, dps, and dqs (display words and symbols) commands. This can be a reasonable technique when WinDbg reports "Probably caused by : ntkrnlmp.exe."
If exception code 0x80000003 occurs, a hard-coded breakpoint or assertion was hit, but the system was started with the /NODEBUG switch. This problem should not occur frequently. If it occurs repeatedly, make sure that a kernel debugger is connected and the system is started with the /DEBUG switch.
If exception code 0x80000002 occurs, the trap frame supplies additional information.
For more information about WinDbg and !analyze, see the following topics:
Analyzing a kernel-mode dump file with WinDbg
Using the !analyze extension and !analyze
Remarks
If you are not equipped to use the Windows debugger to work on this problem, you should use some basic troubleshooting techniques:
Check the System Log in Event Viewer for additional error messages that might help identify the device or driver that is causing bug check 0x7E.
If a driver is identified in the bug check message, disable the driver or check with the manufacturer for driver updates.
Check with your hardware vendor for any ACPI or other firmware updates. Hardware issues, such as system incompatibilities, memory conflicts, and IRQ conflicts can also generate this error.
You can also disable memory caching/shadowing of the BIOS to try to resolve the error. Also run hardware diagnostics that the system manufacturer supplies.
Confirm that any new hardware that is installed is compatible with the installed version of Windows. For example, you can get information about required hardware at Windows 10 Specifications.
For additional general troubleshooting information, see Blue screen data.