0x0000001E KMODE_EXCEPTION_NOT_HANDLED — Windows Error Code

Q: What does the Windows error code 0x0000001E mean?

It is the Win32 / NTSTATUS code KMODE_EXCEPTION_NOT_HANDLED (decimal 30). Kernel mode exception was not handled. Check minidump for offending driver.

Q: How do I decode 0x0000001E in PowerShell?

Run [ComponentModel.Win32Exception]::new(30).Message in any PowerShell session. For HRESULT-style codes, use err.exe from the Windows SDK or the WinDbg !error command.

Q: Where does Windows typically log this error?

It depends on the originating subsystem (Windows Update → %WinDir%\WindowsUpdate.log; AD/Kerberos → Security event log on the DC; BSOD → minidump under C:\Windows\Minidump; MSI → %TEMP%\msi*.log; WMI → Microsoft-Windows-WMI-Activity). Always cross-reference the timestamp and module name with the Application and System event logs.

Description

KMODE_EXCEPTION_NOT_HANDLED (hex code 0x0000001E, decimal 30) is a Windows critical-level error code in the BSOD Stop Codes family. Microsoft surfaces this code through the Win32 API, the Common Language Runtime, the kernel, the event log, PowerShell, command-line tools (sfc, dism, gpupdate, sc), and Windows-side applications such as Outlook, Teams, Office, and System Center.

Kernel mode exception was not handled. Check minidump for offending driver.

This page documents what triggers 0x0000001E, the most common scenarios where it appears, the likely root causes, and a step-by-step troubleshooting workflow you can run against affected endpoints. It is intended for system administrators, MSP technicians, helpdesk engineers, and anyone diagnosing Windows behavior in a managed environment.

In-depth explanation

This is a critical-severity Windows error. It typically indicates a kernel-mode failure, an unrecoverable security violation, hardware failure, or a fatal driver bug. Treat any occurrence as a P1 incident: isolate the host, capture a memory dump if available, and pull the latest minidump from C:\Windows\Minidump for analysis.

It is a kernel bug check code. Windows bluescreens with this stop code, writes a minidump, and reboots. The exact failing module is captured in the dump and can be analyzed with WinDbg or BlueScreenView.

The code can be looked up programmatically in PowerShell with [ComponentModel.Win32Exception]::new(30).Message (for Win32 / NTSTATUS codes that map cleanly), or with net helpmsg 30 for the legacy decimal range. For HRESULT-style codes, decode the facility and code with err.exe from the SDK or via the WinDbg !error command.

Common causes

Faulty or out-of-date kernel-mode driver (storage, GPU, NIC, USB controller).
Defective RAM — run MemTest86 to confirm.
Failing storage (SSD/NVMe firmware bug, SATA cable, or media wear).
Overclocking or unstable XMP / DOCP profile.
Corrupted system file or NTFS metadata — repair with sfc /scannow + chkdsk /f.

Troubleshooting steps

Capture the latest minidump under C:\Windows\Minidump and open it with WinDbg (or BlueScreenView for a faster overview).
Use !analyze -v in WinDbg to identify the failing module, then update or roll back that driver.
Run Driver Verifier (verifier.exe) on third-party drivers if the failing module is not obvious.
Validate hardware: MemTest86 for RAM, chkdsk /f /r for storage, manufacturer diagnostics for CPU/GPU.
If recent: roll back the latest Windows Update or feature update via Settings > Recovery > Go back.

Decode in PowerShell

# Decode 0x0000001E (30) in PowerShell
[ComponentModel.Win32Exception]::new(30).Message

# Or via WinDbg / err.exe (Windows SDK)
# err 0x0000001E

# Or net helpmsg (legacy decimal range only)
# net helpmsg 30

Frequently asked questions

What does the Windows error code 0x0000001E mean?

It is the Win32 / NTSTATUS code KMODE_EXCEPTION_NOT_HANDLED (decimal 30). Kernel mode exception was not handled. Check minidump for offending driver.

How do I decode 0x0000001E in PowerShell?

Run [ComponentModel.Win32Exception]::new(30).Message in any PowerShell session. For HRESULT-style codes, use err.exe from the Windows SDK or the WinDbg !error command.

Where does Windows typically log this error?

It depends on the originating subsystem (Windows Update → %WinDir%\WindowsUpdate.log; AD/Kerberos → Security event log on the DC; BSOD → minidump under C:\Windows\Minidump; MSI → %TEMP%\msi*.log; WMI → Microsoft-Windows-WMI-Activity). Always cross-reference the timestamp and module name with the Application and System event logs.

Is this code recoverable?

Critical-severity codes usually require kernel-level investigation (driver, hardware, system file repair). Error and warning codes are typically recoverable through the troubleshooting workflow on this page — start with the elevated-shell + log review steps.

Should I open a Microsoft support case for this?

Open a case if the error reproduces after applying the troubleshooting steps, particularly if it blocks production workloads, occurs across multiple endpoints, or is associated with a security boundary (BitLocker recovery, Kerberos failure, DCOM hardening, SmartScreen / WDAC). Have a fresh CBS log, minidump, or Get-WinEvent export ready before opening the case.