Thursday, December 8, 2011

Troubleshooting 0x8E KERNEL_MODE_EXCEPTION_NOT_HANDLED

The Debugging Tools for Windows are required to analyze crash dump files. If you do not have the Debugging Tools for Windows installed or dump files are not being generated on system crash, see this post for installation/configuration instructions:
http://mikemstech.blogspot.com/2011/11/windows-crash-dump-analysis.html

Case 1: Parameter 1 is not 0xc0000005

This error indicates that an exception was thrown, but not caught in a kernel mode driver. This error typically provides meaningful output when analyzed with the debugger and usually reports an accurate faulting driver. Typically, only a !analyze -v is needed.


1: 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: ffffffffc0000047, The exception code that was not handled
Arg2: fffff80003108590, The address that the exception occurred at
Arg3: 000000011b766100, Parameter 0 of the exception
Arg4: fffffa801b00ff02, Parameter 1 of the exception

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000047 - An attempt was made to release 
a semaphore such that its maximum count would have been exceeded.

FAULTING_IP: 
nt!RtlRaiseStatus+18
fffff800`03108590 488b8424b8010000 mov     rax,qword ptr [rsp+1B8h]

EXCEPTION_PARAMETER1:  000000011b766100

EXCEPTION_PARAMETER2:  fffffa801b00ff02

ERROR_CODE: (NTSTATUS) 0xc0000047 - An attempt was made to release a 
semaphore such that its maximum count would have been exceeded.

BUGCHECK_STR:  0x1E_c0000047

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80003126588 to fffff800030dac40

STACK_TEXT:  
 ... : nt!KeBugCheckEx
 ... : nt! ?? ::FNODOBFM::`string'+0x4977d
 ... : nt!KiRaiseException+0x1b4
 ... : nt!NtRaiseException+0x7b
 ... : nt!KiSystemServiceCopyEnd+0x13
 ... : nt!RtlRaiseStatus+0x18
 ... : nt! ?? ::FNODOBFM::`string'+0xf5a9
 ... : Arctosa+0x11b7
 ... : 0xfffffa80`1bbaddc0
 ... : 0xfffff800`00000000
 ... : 0xfffffa80`1badb010
 ... : 0xfffffa80`1badb200
 ... : 0xfffffa80`00000000
 ... : 0xfffffa80`1bbadf10


STACK_COMMAND:  kb

FOLLOWUP_IP: 
Arctosa+11b7
fffff880`06a561b7 ??              ???

SYMBOL_STACK_INDEX:  7

SYMBOL_NAME:  Arctosa+11b7

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Arctosa

IMAGE_NAME:  Arctosa.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a8bb060

FAILURE_BUCKET_ID:  X64_0x1E_c0000047_Arctosa+11b7

BUCKET_ID:  X64_0x1E_c0000047_Arctosa+11b7 
 
In this case, the error was caused by arctosa.sys (Google identifies this as some sort of keyboard driver). For those who are interested, the exact location of the error can be identified using parameter 2 of the bug check and the "list nearest symbol," ln, command can be used to identify what call resulted in the crash


1: kd> ln fffff80003108590
(fffff800`03108578)   nt!RtlRaiseStatus+0x18   |  (fffff800`031085ec)   nt!IopGetFileObjectExtension
 
In this case, the error actually occurred in nt!RtlRaiseStatus+0x18 (nt!IopGetFileObjectExtension is the next symbol defined after the point of exception).

Case 2: Parameter 1 is 0xc0000005 (STATUS_ACCESS_VIOLATION)

This error indicates that there was undetected memory corruption performed by one or more drivers on the system. The corruption is detected when system execution encounters it and crashes the system. This error is similar to PAGE_FAULT_IN_NONPAGED_AREA in that the dumps are not particularly useful because the actual driver that caused the corruption is not typically the driver that causes the exception (by running into the corrupted memory). When the first parameter indicates that an access violation occurred, the next step is to enable the driver verifier and see if more informative dumps can be produced. The !analyze -v output does not typically show the faulty driver, and there is not enough information in a minidump to perform more meaningful analysis.

1: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_MODE_EXCEPTION_NOT_HANDLED_M (1000008e)
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.
Some common problems are exception code 0x80000003.  This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG.  This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG.  This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 81a8c323, The address that the exception occurred at
Arg3: 9c535840, Trap Frame
Arg4: 00000000

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP: 
nt!RtlInitUnicodeString+1b
81a8c323 f266af          repne scas word ptr es:[edi]

TRAP_FRAME:  9c535840 -- (.trap 0xffffffff9c535840)
ErrCode = 00000000
eax=00000000 ebx=fe608fd8 ecx=ffffffec edx=9c535914 esi=fe6052f8 edi=fe609000
eip=81a8c323 esp=9c5358b4 ebp=9c535924 iopl=0         nv up ei pl zr na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
nt!RtlInitUnicodeString+0x1b:
81a8c323 f266af          repne scas word ptr es:[edi]
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  DRIVER_FAULT_SERVER_MINIDUMP

BUGCHECK_STR:  0x8E

PROCESS_NAME:  FH.EXE

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from 92869bb5 to 81a8c323

STACK_TEXT:  
9c5358cc 92869bb5 ffa8a020 ffa8a380 00000000 nt!RtlInitUnicodeString+0x1b
9c535924 92a2f1b5 370101b0 00000006 00000002 RDPDD!OEEncodeOpaqueRect+0xeb
9c535a0c 92a3ed02 370101b0 00000006 00000002 win32k!xxxRealDrawMenuItem+0x80b
9c535abc 92a1473a 370101b0 0110007e 9c535b04 win32k!xxxDrawState+0x1c9
9c535b2c 92a155c0 370101b0 fe605d80 00c8d0d4 win32k!xxxDrawMenuItem+0x3f8
9c535b98 92a2f71b 370101b0 00000000 fe604ed8 win32k!xxxMenuDraw+0x1f2
9c535bf0 9297d153 00000017 370101b0 00000004 win32k!xxxMenuBarDraw+0x1bf
9c535c38 9299c075 fe604ed8 370101b0 00000001 win32k!xxxDrawWindowFrame+0xf7
9c535cb4 9299d6bd fe604ed8 00000085 5a0401b4 win32k!xxxRealDefWindowProc+0x88b
9c535ccc 929766ed fe604ed8 00000085 5a0401b4 win32k!xxxWrapRealDefWindowProc+0x2b
9c535ce8 9299d674 fe604ed8 00000085 5a0401b4 win32k!NtUserfnDWORD+0x27
9c535d20 81a91a7a 0001005c 00000085 5a0401b4 win32k!NtUserMessageCall+0xc6
9c535d20 77d59a94 0001005c 00000085 5a0401b4 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
0012d05c 00000000 00000000 00000000 00000000 0x77d59a94


STACK_COMMAND:  kb

FOLLOWUP_IP: 
RDPDD!OEEncodeOpaqueRect+eb
92869bb5 833f02          cmp     dword ptr [edi],2

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  RDPDD!OEEncodeOpaqueRect+eb

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: RDPDD

IMAGE_NAME:  RDPDD.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  4791923e

FAILURE_BUCKET_ID:  0x8E_RDPDD!OEEncodeOpaqueRect+eb

BUCKET_ID:  0x8E_RDPDD!OEEncodeOpaqueRect+eb

Followup: MachineOwner
---------
 
See Also
Windows Crash Dump Analysis
Enable Driver Verifier to Help Identify Blue Screen Causes
Troubleshooting Memory Errors

No comments:

Post a Comment