⚠ CrashDecoder

0x0000007E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

A thread running inside the kernel hit an error condition and no handler existed to deal with it, so Windows stopped. What makes this code more approachable than most is that it frequently names the responsible file on the blue screen itself - and when it does, that name is usually correct rather than a guess.

Updated 2026-07-28Stop errorAlso written: 0x7E, SYSTEM THREAD EXCEPTION NOT HANDLED, system_thread_exception_not_handled, 0x1000007E

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED

What failed: nvlddmkm.sys

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000007e (0xffffffffc0000005, 0xfffff8036a4c1e10, 0xffffb80f2c1a4530, 0xffffb80f2c1a3d70).

What the error actually means

When code raises an exception, the system looks for a handler prepared to deal with it. In user mode, a missing handler kills the application and nothing else. In kernel mode there is no outer layer to catch it, so an unhandled exception in a system thread leaves Windows with no way to continue.

The important consequence is that the exception itself tells you the category of failure. Parameter 1 holds the exception code, and it distinguishes a bad pointer from a misaligned access from a debug breakpoint - three very different problems that would otherwise all present identically.

Where Windows can attribute the fault to a specific file, it prints that name under What failed. Unlike some stop codes where the named component is usually a bystander, here the exception address genuinely identifies the code that faulted - Microsoft's own guidance says parameter 2 should identify the driver or function responsible.

Reading the parameters

Parameter 1 is the one to read first. It is an NTSTATUS exception code, and the common values are documented.

ParameterWhat it holds
1The exception code that was not handled. 0xC0000005 is STATUS_ACCESS_VIOLATION - a memory access violation, and by far the most common. 0x80000003 is STATUS_BREAKPOINT, meaning a hardcoded breakpoint or assertion was hit with no kernel debugger attached. 0x80000002 is STATUS_DATATYPE_MISALIGNMENT, an unaligned data reference.
2The address where the exception occurred. Microsoft states this should identify the driver or function that caused the problem - which is why this bugcheck names files more reliably than most.
3The address of the exception record.
4The address of the context record, holding the CPU register state at the moment of the fault.

What actually triggers it

Driver-dominated, with a distinctive secondary pattern around Windows upgrades.

CauseHow oftenDetail
Display driversCommonThe single most common named file on this bugcheck. nvlddmkm.sys, amdkmdag.sys and igdkmd64.sys appear constantly, often after a driver update or a Windows feature update changed something underneath them.
An incompatible driver after a Windows upgradeCommonA distinctive pattern worth recognising: the machine upgrades to a new Windows build and then bugchecks, sometimes into a boot loop. A driver that was fine on the old build is not on the new one. Wireless adapters, audio interfaces and older peripherals are the usual sources.
Network and audio driversCommonEspecially vendor-customised laptop variants that lag the generic release, and Bluetooth stacks.
Corrupt system filesOccasionalA damaged system binary produces exceptions with no handler. Worth ruling out early because it is quick.
Failing RAMOccasionalCorrupted memory turns a valid pointer into a garbage one, producing an access violation in whichever driver read it. This is why a driver named only once should be treated as a hypothesis rather than a verdict.
Unstable memory or CPU settingsOccasionalXMP or EXPO profiles beyond what the controller sustains, or an undervolt that is not stable at light loads.
Firmware and hardware conflictsRareMicrosoft's guidance mentions checking for ACPI and firmware updates, and notes that memory conflicts and IRQ conflicts can generate this error too.

Narrowing it down

The named file does most of the work, so start there and only reach for a debugger if it is missing or unhelpful.

Read the name off the screen

Photograph the blue screen if you can. The What failed line names the file, and on this bugcheck that name is worth acting on directly.

If you missed it, the dump has it - open the newest minidump in WinDbg and run !analyze -v, then read MODULE_NAME and IMAGE_NAME.

What it tells you

A third-party .sys file identifies your suspect. Microsoft's advice for this code is blunt: if a driver is listed by name, disable or remove it.

Read the exception code in parameter 1

Take the first parameter from the bugcheck event or the dump.

What it tells you

0xC0000005 is an access violation - a bad pointer, which means either a driver bug or corrupted memory. 0x80000003 is a breakpoint, which normally means a driver was built or left in a debug state and is unusual on a retail machine. 0x80000002 is a misalignment, where Microsoft notes the trap frame carries extra detail.

Check whether it started after an upgrade

Open Reliability Monitor with perfmon /rel and line the first crash up against Windows Update history.

What it tells you

Crashes beginning immediately after a feature update point at a driver that is not compatible with the new build. That reframes the fix entirely - you want an updated driver, or to roll the update back while you obtain one.

Compare the named file across several crashes

Open three or four dumps and compare which module each blames.

What it tells you

The same file every time is a genuine driver problem. A different file each time is memory corruption wearing a driver's name, and no amount of driver work will help - go to memory testing instead.

Fixes, cheapest first

If you have a name, the first fix is the only one you probably need.

  1. Replace the named driver

    Effort: 20 minutes · Risk: Low

    Identify the device that owns the named file, then remove the driver properly rather than upgrading over it.

    1. Find the device in Device Manager, open Properties, then the Driver tab, and check Driver Details to confirm which device owns the file.
    2. Uninstall the device, ticking Delete the driver software for this device.
    3. Reboot and install the vendor's current package, downloaded directly rather than through Windows Update.
    4. For display drivers specifically, use DDU from Safe Mode instead - an in-place removal leaves too much behind.
    Watch out

    If the crashes began after a driver update, install the previous release rather than the newest. Regressions are common and newer is not automatically better.

  2. Get out of a boot loop

    Effort: 30 minutes · Risk: Low

    This bugcheck frequently loops, particularly after an upgrade, because the offending driver loads during startup. You need Safe Mode, which loads a minimal driver set.

    1. Interrupt the boot three times with the power button to trigger the recovery environment.
    2. Troubleshoot, Advanced options, Startup Settings, Restart, then choose Safe Mode.
    3. In Safe Mode, uninstall the named driver, or the device it belongs to, from Device Manager.
    4. If the crashes started after a Windows update, use Troubleshoot, Advanced options, Uninstall Updates instead.
    5. Reboot normally.
    Watch out

    If you cannot read the file name because the machine reboots too fast, disable automatic restart: in Startup Settings choose Disable automatic restart after failure. The blue screen then stays on screen long enough to read.

  3. Verify system files

    Effort: 30 minutes · Risk: None

    Quick to rule out. Run in order from an administrator terminal:

    1. sfc /scannow
    2. DISM /Online /Cleanup-Image /RestoreHealth
    3. sfc /scannow once more

  4. Return memory and CPU to stock

    Effort: 10 minutes · Risk: Low

    Disable XMP, EXPO, any manual memory tuning, and any CPU overclock or undervolt. Run at stock for several days. If the crashes stop, the settings were not stable rather than the hardware being faulty.

  5. Test the memory

    Effort: Overnight · Risk: None

    Particularly worth doing if the named file changes between crashes. MemTest86 from USB, at least four passes, with profiles disabled.

  6. Update firmware

    Effort: 30 minutes · Risk: Medium

    Microsoft's guidance for this code mentions checking with the hardware vendor for ACPI or other firmware updates, noting that system incompatibilities and resource conflicts can generate it. Worth doing when a driver replacement has not helped and the machine is older.

    Watch out

    If the drive is protected by BitLocker or Device Encryption, a firmware update can change TPM measurements and trigger a recovery-key prompt on the next boot. Check with manage-bde -status and save your key from account.microsoft.com/devices/recoverykey first - Windows 11 enables Device Encryption by default on much consumer hardware.

    Run the update on mains power and do not interrupt it.

When it is the hardware, not Windows

Mostly software, so these need to be clear before switching direction:

The first item is the one that matters. A driver bug is repetitive - the same file, the same exception code, every time. Corruption moves around, because what gets damaged depends on what was stored where. Three dumps naming three different files is a stronger signal than any single dump could give you.

Frequently asked

The screen names a file but I cannot find what it belongs to.

Search the filename directly - most driver files are identifiable and the common ones are well documented. If that fails, look in C:\Windows\System32\drivers, right-click the file, open Properties and read the Details tab, which usually carries the vendor and product name. In WinDbg, lm t n lists every loaded module with its timestamp, which also helps spot a driver that is years out of date.

What is 0x1000007E? Is it a different bug?

Same bugcheck. The 0x1000 prefix indicates the same condition reported through a slightly different path, and the parameters carry the same meanings. Troubleshoot it identically - nothing about the diagnosis changes.

It started right after a Windows feature update. Should I roll the update back?

Rolling it back is a legitimate way to confirm the connection and to get a working machine while you find an updated driver. It is a poor permanent answer, since you will eventually have to take the update and will be in the same position. The better sequence is: roll back if you need the machine now, obtain the current driver from the vendor, then reapply the update. If no compatible driver exists for that device, that is worth knowing before you upgrade again.

Parameter 1 is 0x80000003. What does that actually mean?

A hardcoded breakpoint or assertion was hit while no kernel debugger was attached. Microsoft notes this should not occur frequently on a normal system - it generally means a driver shipped with debug code left in, or was built expecting a debugger to be present. On a retail machine it points fairly directly at whichever third-party driver is named. It is unusual enough that seeing it repeatedly is itself informative.