http://www.fergo.co/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 Any source
No comments:
Post a Comment