UNEXPECTED_KERNEL_MODE_TRAP 0x0000007F – double fault and stack overflow

Fix it now

The processor raised a trap the kernel could not catch. Parameter 1 is the trap number and it decides everything that follows: 0x8 is a double fault, which Microsoft attributes to kernel stack overflow or to a hardware problem, and 0xD is a general protection fault. Microsoft’s stated cause for this bug check is faulty or mismatched hardware, especially memory.

wmic recoveros get DebugInfoType
sfc /scannow
fltmc

1. Read parameter 1 from the BugCheck event in Event Viewer, under Windows Logs then System. Current stop screens do not display the bugcheck parameters, so do not expect to find it there.
2. Enter firmware setup and load defaults. Microsoft’s published advice for this bug check includes returning an overclocked processor to its default clock speed and disabling memory caching in the BIOS if the option exists.
3. Run the Windows Memory Diagnostics tool: in the Control Panel search box enter Memory, then select Diagnose your computer’s memory problems. Read the result afterwards in Event Viewer under the System log, in the MemoryDiagnostics-Results entry.
4. If parameter 1 was 0x8 and the memory tests clean, count the third-party filter drivers with fltmc. Microsoft names filter drivers stacked on one stack, recursing back in, as a documented route to a kernel stack overflow.
5. Remove anything redundant on that stack – a second scanner, a backup agent’s leftover filter, disk software you no longer use – and re-test.

Reset firmware to defaults before you test memory, not after. A memory profile is an overclock, and testing modules at a speed you are about to stop using tells you very little.

If the machine is stable at defaults with clean memory, you have your answer. If it is not, the next section explains what a double fault is and why the stack is where to look.

Why it happens

Microsoft’s description of 0x0000007F is that the CPU generated a trap and the kernel failed to catch it, and that the trap is either a bound trap – one the kernel is not permitted to catch – or a double fault, which always results in a system failure. Parameter 1 carries the trap number, and it is the only part of the record that narrows anything down.

The published trap table is worth knowing because the entries point in different directions. 0x00 is a divide by zero, which Microsoft attributes to memory corruption, other hardware problems or software failures. 0x06 is an invalid opcode, which Microsoft says usually means the instruction pointer has been corrupted, most commonly by hardware memory corruption. 0x08 is the double fault. 0x0D is a general protection fault. A machine that produces 0x06 and 0x0D on alternate crashes is telling you about its memory, not about a driver.

A double fault is what happens when a second exception arrives while the handler for the first is still running, and the processor cannot serialise them. Microsoft gives two causes. The first is kernel stack overflow: the guard page is hit, the kernel tries to push a trap frame, there is no stack left to push it onto, and the double fault follows. Microsoft’s own example is two file system filter drivers attached to the same stack with the file system recursing back in. The second is simply a hardware problem.

0x1000007F is the same bug check under a different number. Microsoft states it has the same meaning and the same parameters as 0x7F, so read it identically. The other companions are separate failures that share a stop screen: 0x00000012 is an unknown exception, with parameter 1 saying whether it was an unexpected interrupt, an unknown floating point exception, or the enabled and asserted status bits. 0x00000111 is an NMI arriving while a previous NMI was in progress, which Microsoft attributes to system management interrupt code in firmware – a firmware update, not a driver hunt. 0x000001AA is exception dispatch crossing into an invalid kernel stack. 0x00000094 is a thread exiting while its kernel stack was marked not swappable.

Full reference

The trap numbers Microsoft publishes

Working a double fault in the debugger

Microsoft’s published sequence is specific and worth following in order rather than staring at !analyze output. Start with !analyze -v. Then run kv for the stack. If kv shows a task gate, use .tss on the selector; if it shows a trap frame, use .trap on that address. Then run kv again – the second stack is the real one. On a double fault the first stack is frequently mangled, which is why the top frame so often resolves to a core Windows component that was merely on the path.

The companion codes, and what each actually means

Reading 0x000001AA when it appears

This one rewards a moment’s attention because its parameters are unusually informative. Parameter 1 points at the current stack. Parameter 2 is the kernel’s best estimate of which kind of stack should have been active – a normal kernel thread stack is 0x3, a processor DPC stack 0x1, an ISR stack 0x6, an NMI handling stack 0x8, a machine check handling stack 0x9. Parameter 3 is the context record and parameter 4 the exception record, so .cxr and .exr on those two values give you the state at the moment of the fault directly.

Software steps Microsoft publishes for this bug check

• Check the System log in Event Viewer for messages identifying the device or driver causing the error.
• Check for updates to the ACPI or system firmware, the disk controller driver, or the network card driver.
• If a new or updated device driver preceded the crashes, remove or replace it, using Safe Mode to rename or delete the file if the machine will not start normally.
• If you are upgrading Windows, remove third-party device drivers and system services and disable virus scanners for the upgrade.
• Install the latest Windows updates.

What the crash pattern is telling you

Every code this article covers

Confirm the fix worked

1. Confirm firmware is at defaults, with any tuning reintroduced deliberately and tested one change at a time.
2. Confirm the Windows Memory Diagnostics result in the System log reports no errors.
3. Run a sustained processor load for at least half an hour and confirm the machine stays up.
4. Run fltmc and confirm every filter listed belongs to a product that is installed and current.
5. Use the machine for several days and confirm no new BugCheck events are written to the System log.

Questions people ask about this