Three crash dumps, and what the debugger actually showed
We ran three crash dumps from our lab through DumpTriage: a Windows kernel crash, a Windows application crash and a Linux kernel panic. Each one has an obvious reading, and in the two Windows cases the obvious reading is wrong.
All three dumps were made on purpose, from test drivers and test programs, so none of this is customer data. We uploaded them on 4 November 2026 the way a customer would. All three reports came back without an engineer stepping in. Every debugger line quoted below is from those runs. Want the three full reports as DumpTriage delivered them? Email us and we'll send them to you.
| Dump | The obvious reading | What the report found | Upload to report |
|---|---|---|---|
| Windows kernel, ARM64 | 0x139 with Windows on the stack: Windows is broken | A stack overrun in a third-party driver, HEVD.sys | 11 min 18 s |
| Windows application, x86 | 0xC0000409, a stack buffer overrun | An uncaught C++ exception; nothing was overrun | 10 min 04 s |
| Linux kernel vmcore | A NULL pointer dereference | Right, and the oops shows the exact instruction in an out-of-tree module | 2 min 26 s |
1. A 0x139 that Windows didn't cause
Stop code 0x139, KERNEL_SECURITY_CHECK_FAILURE, means the kernel caught something breaking one of its own safety checks. The stack at the moment of the crash is the kernel's own, so a quick look blames ntoskrnl.exe. A free analyzer we tried, which reads the dump without running a debugger, did exactly that: it named ntoskrnl.exe and suggested updating the virtualization tools and running sfc.
WinDbg's !analyze -v says otherwise. Argument 1 is 2, a failed stack cookie, and the image it names is a driver:
Arg1: 0000000000000002, Stack cookie instrumentation code detected a stack-based
buffer overrun.
PROCESS_NAME: powershell.exe
IMAGE_NAME: HEVD.sys
FAILURE_BUCKET_ID: 0x139_MISSING_GSFRAME_HEVD!unknown_functionThe first pass flagged possible memory corruption, so DumpTriage ran a second pass with more debugger commands. That pass read the trap frame, whose program counter is at HEVD+0x10dc, and dumped the stack just above it. Of the 32 entries it printed, 26 were the same value:
ffff860d`17ea1528 fffff802`e6988d30 HEVD+0x88d30
ffff860d`17ea1530 41414141`41414141
ffff860d`17ea1538 41414141`41414141
ffff860d`17ea1540 41414141`41414141
… 22 more lines of 41414141`41414141 …0x41 is the letter A, the usual filler a test sends to overrun a buffer. HEVD is the HackSys Extreme Vulnerable Driver, a test driver built to contain bugs for exploit practice, and this stack looks like that practice. The report said to take the driver off any machine that isn't used for exploit testing, and to find out what in the PowerShell session sent the input.
What it couldn't tell: the dump holds neither the driver's code page nor the request that reached it, so the report can't show the exact instruction or the IOCTL. Without the driver's symbols it gives an offset, not a function name, and says so.
2. A 0xC0000409 that wasn't a buffer overrun
0xC0000409 is STATUS_STACK_BUFFER_OVERRUN, so it is tempting to go looking for memory corruption. But Windows uses the same code for every fast-fail, the instruction a program uses to end itself on purpose, and the subcode says why. In this dump the subcode is 7, FAST_FAIL_FATAL_APP_EXIT: the C runtime ending the process after abort() or std::terminate.
The exception record shows the cause, a C++ exception (e06d7363) that nothing caught. A second pass disassembled the crash site and found the program loading 7 into ecx right before int 29h, the fast-fail itself:
ExceptionCode: e06d7363 (C++ EH exception)
FAILURE_BUCKET_ID: FAIL_FAST_FATAL_APP_EXIT_CPP_EXCEPTION_c0000409_cppthrow32.exe!Unknown
0045b0f1 6a07 push 7
0045b0f3 59 pop ecx
0045b0f4 cd29 int 29hThe report called it an ordinary application bug. It suggested uploading the program's PDB so the frames get names, reading the exception object for the C++ type and its message, and catching exceptions at the top of the thread routine so the next one is logged.
We tried an AI assistant built into an error tracker on the same file. It called this a /GS stack-cookie overrun caused by writing past a stack buffer, which would send a developer hunting for corruption that isn't there.
We got this wrong too. On 22 October our own pipeline treated every 0xC0000409 as memory corruption and sent this dump to an engineer instead of answering. That was the safe kind of wrong, but still wrong, and we fixed it the same week. This run read the subcode and answered without an engineer.
3. A Linux panic where the oops already says it
Not every dump is a puzzle. This kdump vmcore came from an Ubuntu 24.04 machine whose kernel log ends in a NULL pointer dereference. The log names the module, the taint flags show it is out-of-tree and unsigned (OE), and the instruction bytes at the fault decode to one store:
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
RIP: 0010:crashme_null+0x6/0x20 [crashme]
Code: … 55 <c7> 04 25 00 00 00 00 2a 00 00 00 48 89 e5 5d c3 …c7 04 25 00 00 00 00 2a 00 00 00 is movl $0x2a, 0x0: write 42 to address 0. The backtrace shows how it got there, from a write() system call through proc_reg_write into the module's own write handler. The first pass had everything it needed, so the report came back in under two and a half minutes. It said to send the oops to the module's maintainer and to unload or blacklist the module until it is fixed, since one write to its /proc entry is enough to panic the machine.
What it couldn't tell is why the pointer was NULL. That needs the module's source. We haven't run a free tool on this vmcore, so there's no comparison here.
Why the Windows reports took ten minutes
The times above run from upload to delivered report. Most of each Windows time went on starting a Windows worker VM: 9 min 07 s of the 11 min 18 s for the kernel dump, and 8 min 16 s of the 10 min 04 s for the application crash. Each worker VM is created for its job and deleted afterwards, and we don't keep one running between dumps, so a dump that arrives when none is up waits for one to boot. The Linux worker started in 1 min 12 s.
What the three have in common
- The stop code is where you start, not the answer. 0x139 and 0xC0000409 each cover several quite different failures. The arguments and subcodes say which one you have.
- The second look is where the evidence is. Both Windows answers came from follow-up commands (the trap frame, the stack memory, a disassembly), not from the first
!analyze -v. - Saying what's missing is part of the report. No symbols means offsets, not function names, and no source means no "why". Each report says which.
Want reports like these on your own dumps?
We're taking five design partners: three months free, an engineer's review included, and a 20-minute call each month to tell us what the reports got right and wrong.
See the terms