Windows® Internals, Sixth Edition, Part 2

Viewing the stack trace of the crashed thread can give an indication of the driver or function that caused the problem. If there’s nothing that looks suspicious, viewing the address where the exception occurred should provide more details. The stack trace from a crashed system looks like this:STACK_TEXT: 9444f6b4 828ba08c 0000008e 80000003 92c70a78 nt!KeBugCheckEx+0x1e 9444fadc 82843dd6 9444faf8 00000000 9444fb4c nt!KiDispatchException+0x1ac 9444fb44 82844678 9444fbc4 92c70a79 badb0d00 nt!CommonDispatchException+0x4a 9444fb44 92c70a79 9444fbc4 92c70a79 badb0d00 nt!KiTrap03+0xb8 WARNING: Stack unwind information not available. Following frames may be wrong. 9444fbc4 92c70b1c 8730f980 00000001 00000000 myfault+0xa79 9444fbfc 8283c593 87314a08 87279950 87279950 myfault+0xb1c 9444fc14 82a3099f 8730f980 87279950 872799c0 nt!IofCallDriver+0x63 9444fc34 82a33b71 87314a08 8730f980 00000000 nt!IopSynchronousServiceTail+0x1f8 9444fcd0 82a7a3f4 87314a08 87279950 00000000 nt!IopXxxControlFile+0x6aa 9444fd04 828431ea 000000c4 00000000 00000000 nt!NtDeviceIoControlFile+0x2a 9444fd04 772c70b4 000000c4 00000000 00000000 nt!KiFastCallEntry+0x12a 0012f2ac 00000000 00000000 00000000 00000000 0x772c70b4

The second bugcheck parameter contains the location in memory that the exception occurred at. In the case of a STATUS_BREAKPOINT exception, unassembling the address will confirm the presence of a breakpoint instruction. The processor instruction INT 3 is called the trap to debugger instruction. An INT 3 instruction, when executed, causes the system to call the kernel’s debugger exception handler. If a debugger is attached to the computer, the system will break in.0: kd> u 92c70a78 myfault+0xa78: 92c70a78 cc int 3 ...

Breakpoints shouldn’t usually appear in retail versions of device drivers. Using the lm command, it’s sometimes possible to determine which environment a device driver was targeted for. When compiling a driver for release (and unless overridden by the developer), a flag is set indicating the release type. When viewing the File flags property, the presence of the word Debug indicates that the driver was built using a checked (or debug) environment:0: kd> lm kv m myfault start end module name 92c70000 92c71880 myfault (no symbols) Loaded symbol image file: myfault.sys Image path: \??\C:\Windows\system32\drivers\myfault.sys Image name: myfault.sys Timestamp: Sat Apr 07 09:34:40 2012 (4F806CA0) CheckSum: 00004227 ImageSize: 00001880 File version: 4.0.0.0 Product version: 4.0.0.0 File flags: 1 (Mask 3F) Debug File OS: 40004 NT Win32 ...

A breakpoint in a debug version of a driver could also indicate the failure of an ASSERT macro. If a kernel debugger is attached to the system, a message would be displayed followed by a prompt asking the user what to do about the assertion failure.

0x7F - UNEXPECTED_KERNEL_MODE_TRAP

An UNEXPECTED_KERNEL_MODE_TRAP (0x7F) stop code indicates that the CPU generated a trap that the Windows kernel failed to handle. The trap could be the result of a bound trap (which the kernel is not permitted to catch) or a double fault (a fault that occurs while the kernel is processing an earlier fault). The first bugcheck parameter defines the type of trap.UNEXPECTED_KERNEL_MODE_TRAP (7f) This means a trap occurred in kernel mode, and it's a trap of a kind that the kernel isn't allowed to have/catch (bound trap) or that is always instant death (double fault). The first number in the bugcheck params is the number of the trap (8 = double fault, etc) Consult an Intel x86 family manual to learn more about what these traps are. Here is a *portion* of those codes: If kv shows a taskGate use .tss on the part before the colon, then kv. Else if kv shows a trapframe use .trap on that value Else .trap on the appropriate frame will show where the trap was taken (on x86, this will be the ebp that goes with the procedure KiTrap) Endif kb will then show the corrected stack. Arguments: Arg1: 00000008, EXCEPTION_DOUBLE_FAULT Arg2: 801db000 Arg3: 00000000 Arg4: 00000000

Most traps in this category are the result of faulty or failed hardware. If you recently added new hardware to the computer, try removing it to see whether the problem no longer occurs. Remove any existing hardware that may have failed and have it replaced. It’s also recommended to run any manufacturer-supplied hardware-diagnostic tools to determine which components may have failed.