0x0000001E KMODE_EXCEPTION_NOT_HANDLED
A program running in kernel mode generated an exception and no handler existed to deal with it. Because kernel mode has no outer layer to catch a fault, Windows stops. The diagnosis starts with the exception code in parameter 1, which distinguishes a bad pointer from a misaligned access from a debug breakpoint - three problems that would otherwise look identical.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: KMODE_EXCEPTION_NOT_HANDLED
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: 0x0000001e (0xffffffffc0000005, 0xfffff8036a1c4e10, 0x0000000000000000, 0xffffb80f2c1a4530).What the error actually means
When code raises an exception, the system looks for a handler prepared to deal with it. Applications get away with missing handlers because the process dies and nothing else is affected. Kernel-mode code does not have that luxury - there is nothing above it to contain the failure.
So an unhandled exception in kernel mode stops the machine. The code itself is broad, covering any kernel-mode program rather than a specific subsystem, which is why the exception code carries most of the diagnostic weight.
Microsoft's guidance is direct about where to look: the exception address in parameter 2 should identify the driver or function that caused the problem. Where Windows can attribute it, the driver name is printed on the blue screen.
Reading the parameters
Parameter 1 first, then parameter 2. On access violations, parameter 4 is unusually informative.
| Parameter | What it holds |
|---|---|
| 1 | The exception code that was not handled. 0xC0000005 is STATUS_ACCESS_VIOLATION - a memory access violation, and the most common by far. 0x80000003 is STATUS_BREAKPOINT, meaning a breakpoint or assertion was hit with no kernel debugger attached. 0x80000002 is STATUS_DATATYPE_MISALIGNMENT, an unaligned data reference. |
| 2 | The address where the exception occurred. Microsoft states this should identify the driver or function responsible, and a debugger resolves it to a module name. |
| 3 | Exception information from the exception record. |
| 4 | Further exception information - and on an access violation (0xC0000005), Microsoft documents this as the address the driver attempted to access. A small value near zero indicates a null pointer dereference; a large, wild-looking address suggests corrupted data instead. |
What actually triggers it
Driver-dominated, with a firmware angle Microsoft calls out specifically.
| Cause | How often | Detail |
|---|---|---|
| A faulty device driver or system service | Common | Microsoft names this directly. Display, network and audio drivers lead, along with anything installed recently. If a driver is named on the blue screen, that name is worth acting on. |
| Anti-virus and filter drivers | Common | Security products hook kernel operations by design, and a mismatch after a Windows update produces unhandled exceptions reliably. |
| Failing RAM | Occasional | Corrupted memory turns a valid pointer into a garbage one, and the driver that dereferences it takes the blame. Microsoft's guidance recommends running the system manufacturer's hardware diagnostics, especially the memory scanner. |
| BIOS and firmware incompatibility | Occasional | Microsoft is explicit that this error can occur after the first restart during Windows Setup or after Setup finishes, and that a system BIOS incompatibility is a possible cause resolved by updating the BIOS. Worth knowing if this appeared on a fresh install. |
| Hardware incompatibility or resource conflicts | Occasional | Microsoft mentions memory conflicts and IRQ conflicts as possible causes, and recommends confirming new hardware is compatible with the installed Windows version. |
| Unstable memory or CPU settings | Occasional | XMP or EXPO beyond what the controller sustains, or an undervolt unstable at light loads. |
Narrowing it down
Two values do most of the work: the exception code and, on access violations, the address that was touched.
Read the exception code
Take parameter 1 from the bugcheck event or from !analyze -v.
0xC0000005 is an access violation, meaning a bad pointer - either a driver bug or corrupted memory. 0x80000003 is a breakpoint, which Microsoft says should occur rarely and normally means a driver shipped with debug code left in. 0x80000002 is a misalignment, where Microsoft notes the trap frame supplies more information.
On an access violation, read parameter 4
When parameter 1 is 0xC0000005, parameter 4 holds the address the driver tried to access.
A value under about 0x1000 is a null pointer with an offset - a plain logic bug in a driver, and hardware is not implicated. A large, random-looking address means the pointer itself was corrupted, which moves memory into scope.
Check the module name across several dumps
Open three or four dumps and compare MODULE_NAME.
The same driver every time is a genuine bug in that driver. A different one each time is memory corruption wearing a driver's name.
Check whether it started with a fresh install or new hardware
Microsoft notes this error can appear after the first restart during Windows Setup, and points at BIOS incompatibility in that case.
Crashes beginning on a new installation, or immediately after adding hardware, shift the investigation toward firmware and compatibility rather than toward a specific driver bug.
Fixes, cheapest first
If a driver is named, start and probably finish there.
Remove or update the named driver
Microsoft's advice for this code is blunt: if a driver is listed by name in the bug check message, disable or remove it, along with any drivers or services added recently.
- Identify the device that owns the named file via Device Manager, Properties, Driver, Driver Details.
- Uninstall the device, ticking Delete the driver software for this device.
- Reboot and install the vendor's current package, downloaded directly rather than via Windows Update.
- For display drivers use DDU from Safe Mode instead - an in-place removal leaves too much behind.
Watch outMicrosoft also notes that if the error occurs during startup and the system partition is NTFS, Safe Mode may let you disable the driver in Device Manager. That is the route out of a boot loop.
Verify system files
Run in order from an administrator terminal:
sfc /scannow, thenDISM /Online /Cleanup-Image /RestoreHealth, thensfc /scannowonce more.Return memory and CPU to stock
Disable XMP, EXPO, any manual memory timings, and any CPU overclock or undervolt. Run at stock for several days before drawing conclusions.
Test the memory
MemTest86 from USB, at least four passes, with profiles disabled. Particularly worth doing if parameter 4 held a wild address or if the named module changes between crashes.
Update the system BIOS
Microsoft specifically names BIOS incompatibility as a cause of this bugcheck and says it can be resolved by upgrading the BIOS version. Most relevant if the machine is newly built, newly installed, or has had hardware added.
Watch outIf 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 -statusand 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.
Run Driver Verifier
If no driver is named and the dumps are unhelpful, Verifier will force the issue by making a misbehaving driver crash identifiably. See the Driver Verifier guide for settings and the Safe Mode escape route.
Watch outVerifier deliberately increases crashes and can cause a boot loop. Run
verifier /bootmode resetonbootfailbefore enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed byverifier /reset. Full settings and the escape route are in the Driver Verifier guide.
When it is the hardware, not Windows
Mostly software, so these need to be clear before switching direction:
- The named module differs between crashes.
- Parameter 4 is consistently a large random-looking address rather than a small offset.
- MemTest86 reports errors at stock settings.
- Other unrelated stop codes appear in the same period.
- Crashes continue after a clean Windows install with minimal drivers.
WHEA-Loggerentries appear around the same timestamps.
As with the other exception-based codes, consistency is the discriminator. A driver bug repeats exactly - same module, same exception code, same shape of faulting address. Memory corruption produces variety, because what gets damaged depends on what happened to be stored where.
Frequently asked
What is the difference between 0x1E and 0x7E?
Both mean an unhandled exception in kernel mode, and the troubleshooting is nearly identical. 0x7E SYSTEM_THREAD_EXCEPTION_NOT_HANDLED is raised specifically when the exception came from a system thread; 0x1E covers kernel-mode code generally. The parameter layouts differ slightly - 0x7E gives you the exception record and context record addresses, while 0x1E gives you the exception's own information parameters. In practice: read the exception code, read the named module, and treat them the same.
The blue screen does not name any driver. Now what?
Read the dump - the exception address in parameter 2 should resolve to a module even when the screen shows nothing. If !analyze -v also comes back with only kernel components, Microsoft documents a procedure using .exr and .cxr on the exception and context records to recover a usable stack trace. Failing that, Driver Verifier is the practical route: it makes a misbehaving driver fail identifiably rather than anonymously.
It appeared right after installing Windows on a new build. Is my hardware faulty?
Not necessarily, and this is a case Microsoft calls out specifically - it notes the error can occur after the first restart during Setup and names BIOS incompatibility as a possible cause. On a new build, update the motherboard BIOS to the current version before assuming a component is bad, and confirm the memory is on the board's qualified vendor list. New builds also frequently ship with XMP enabled by default, which is worth disabling while you establish a baseline.
What is 0x1000001E?
The same bugcheck reported through a slightly different path. The parameters carry the same meanings and the diagnosis is unchanged. The same pattern exists for 0x7E and 0x1000007E.
Related errors
- 0x0000007ESYSTEM_THREAD_EXCEPTION_NOT_HANDLEDA system thread faulted with no handler. Usually prints the guilty driver right on the screen.
- 0x0000003BSYSTEM_SERVICE_EXCEPTIONA kernel fault during a system call. Usually a driver, sometimes memory, occasionally a dying board.
- GuideHow to Read a Windows Crash Dump File with WinDbgInstall WinDbg, open the dump, run one command. Fifteen minutes, and it usually names the driver.