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