http://www.fergo.co/2011/11/windows-crash-dump-analysis.html
0x1000001E KMODE_EXCEPTION_NOT_HANDLED is a common bug check (BSOD) that occurs on Windows systems (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and Windows 8). Similar to 0x8E KERNEL_MODE_EXCEPTION_NOT_HANDLED, this error indicates that an error occurred in privileged mode (kernel mode) without any associated code to handle the error. Like 8E, there are a couple of variations, some that are due to other drivers (caused by memory corruption, often with a sub-status of 0xc0000005 STATUS_ACCESS_VIOLATION), and those that are due to the drivers in which they are detected.
Troubleshooting these bug checks are fairly straightforward, starting with a !analyze -v. If there is no memory corruption and a driver is identified, alternate versions of the identified driver should be tested, along with upgraded/downgraded BIOS versions. The same approach should be taken with memory corruption issues, but in addition, hardware problems should be ruled out and the driver verifier should be enabled to see if more informative dumps can be generated (specifically implicating a driver that is reading or writing invalid memory).
Below are a few debugging examples for this blue screen of death,
Example 1: Sloppy Programming/Development Practices
During the development processes, programmers insert breakpoints into specific sections of code so that they can use a debugger to see what the driver/application state is at a specific point of execution. Before an application/driver is released, the breakpoints should be removed, otherwise they will generate an exception. In kernel mode, this crashes the system. In user mode, this simply crashes the application (unless a debugger is attached and the command is given to continue past the breakpoint). Allowing a breakpoint to be shipped into production code is a sloppy practice that is the result of a poorly controlled and audited development process.In this dump, the silabser.sys driver is implicated and the exception is clearly due to a breakpoint in the code that shipped with the final release.
5: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception
Debugging Details:
------------------
EXCEPTION_CODE: (Win32) 0 (0) - The operation completed successfully.
FAULTING_IP:
+3132323761623761
00000000`00000000 ?? ???
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: 0000000000000000
ERROR_CODE: (NTSTATUS) 0 - STATUS_WAIT_0
BUGCHECK_STR: 0x1E_0
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 2
EXCEPTION_RECORD: fffff880030b08a8 -- (.exr 0xfffff880030b08a8)
ExceptionAddress: fffff800030d4a70 (nt!DbgBreakPoint)
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 1
Parameter[0]: 0000000000000000
TRAP_FRAME: fffff880030b0950 -- (.trap 0xfffff880030b0950)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=fffff88000f60f70
rdx=fffffa8007ad26b0 rsi=0000000000000000 rdi=0000000000000000
rip=fffff800030d4a71 rsp=fffff880030b0ae8 rbp=0000000000000000
r8=fffffa8007ad26b0 r9=fffff88000f60f40 r10=7efefeff71647261
r11=fffff880030b0ad0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!DbgBreakPoint+0x1:
fffff800`030d4a71 c3 ret
Resetting default scope
LAST_CONTROL_TRANSFER: from fffff800030d45fe to fffff800030dcc10
STACK_TEXT:
... : nt!KeBugCheck
... : nt!KiKernelCalloutExceptionHandler+0xe
... : nt!RtlpExecuteHandlerForException+0xd
... : nt!RtlDispatchException+0x415
... : nt!KiDispatchException+0x135
... : nt!KiExceptionDispatch+0xc2
... : nt!KiBreakpointTrap+0xf4
... : nt!DbgBreakPoint+0x1
... : Wdf01000!FxRequest::VerifierVerifyRequestIsCancelable+0x80
... : Wdf01000!FxIoQueue::RequestCancelable+0xe7
... : Wdf01000!imp_WdfRequestUnmarkCancelable+0xbc
... : silabser+0x7319
... : 0xfffffa80`0878b880
... : 0xfffffa80`0878ba10
... : 0x57f`f7874778
... : 0x57f`f7874778
... : 0x1
... : 0xfffffa80`07038d28
... : 0xc0000120
... : silabser+0x804e
... : 0xfffffa80`0878ba10
STACK_COMMAND: kb
FOLLOWUP_IP:
silabser+7319
fffff880`04dbf319 ?? ???
SYMBOL_STACK_INDEX: b
SYMBOL_NAME: silabser+7319
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: silabser
IMAGE_NAME: silabser.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 4e83514f
FAILURE_BUCKET_ID: X64_0x1E_0_silabser+7319
BUCKET_ID: X64_0x1E_0_silabser+7319
Followup: MachineOwner
---------
Example 2: Memory Corruption
This is a particularly interesting case of memory corruption because the symbols and state that was dumped was corrupted enough to make the symbols unrecognizable from a debugger perspective. Even though we can obviously tell that the problem was detected in the NT kernel, the debugger has difficulty analyzing the dump and complains (incorrectly) about missing symbols.kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80002e7c1d1, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: ffffffffffffffff, Parameter 1 of the exception
Debugging Details:
------------------
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
ADDITIONAL_DEBUG_TEXT:
Use '!findthebuild' command to search for the target build information.
If the build information is available, run '!findthebuild -s ; .reload'
to set symbol path and load symbols.
MODULE_NAME: nt
FAULTING_MODULE: fffff80002e0c000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc600
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 -
The instruction at 0x%08lx referenced memory at 0x%08lx.
The memory could not be %s.
FAULTING_IP:
nt+701d1
fffff800`02e7c1d1 0fae55ac ldmxcsr dword ptr [rbp-54h]
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: ffffffffffffffff
READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
ffffffffffffffff
ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced
memory at 0x%08lx. The memory could not be %s.
BUGCHECK_STR: 0x1E_c0000005
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
CURRENT_IRQL: 0
LAST_CONTROL_TRANSFER: from fffff80002ebda17 to fffff80002e7df00
STACK_TEXT:
... : nt+0x71f00
... : nt+0xb1a17
... : 0x1e
... : 0xffffffff`c0000005
... : nt+0x701d1
STACK_COMMAND: kb
FOLLOWUP_IP:
nt+701d1
fffff800`02e7c1d1 0fae55ac ldmxcsr dword ptr [rbp-54h]
SYMBOL_STACK_INDEX: 4
SYMBOL_NAME: nt+701d1
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: ntoskrnU.exe
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner
---------
See Also,
Windows Crash Dump Analysis
Troubleshooting Memory ErrorsAny source
No comments:
Post a Comment