So the story goes...the IT director gets a new Dell D420. We image it with our standard bla bla bla. It's small, it's shiny, it's light. It crashes. Repeatedly and randomly.
Bugcheck is always 8e c000005 Bucket_ID DRIVER_FAULT. Great. There's only, what, 40 or 50 devices in device mgr? It's not hardware - rebuilt the system on a different D420 with the same exact result. Of course, he reports it happens 'no matter what i'm doing' so that's no help. WinDbg follows:
0: 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: bf804902, The address that the exception occurred at
Arg3: a6c39908, 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:
win32k!HmgShareCheckLock+8e
bf804902 f60702 test byte ptr [edi],2
TRAP_FRAME: a6c39908 -- (.trap ffffffffa6c39908)
ErrCode = 00000000
eax=00000001 ebx=e180e858 ecx=e6fe41e8 edx=e6fe41e8 esi=e5190008 edi=018e0930
eip=bf804902 esp=a6c3997c ebp=a6c3998c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!HmgShareCheckLock+0x8e:
bf804902 f60702 test byte ptr [edi],2 ds:0023:018e0930=??
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: explorer.exe
LAST_CONTROL_TRANSFER: from bf806148 to bf804902
STACK_TEXT:
a6c3998c bf806148 e5190008 01900010 e7696418 win32k!HmgShareCheckLock+0x8e
a6c399c0 bf80607f a6c399e0 bf803e57 e5190008 win32k!XDCOBJ::bCleanDC+0x198
a6c399c8 bf803e57 e5190008 00000039 022af32c win32k!XDCOBJ::bCleanDC+0x3b
a6c399e0 bf803ee0 bd01093c 00000000 a6c39a04 win32k!_GetDCEx+0xdc
a6c399f0 bf8010ca bd01093c a6c39a14 022af32c win32k!_GetDCEx+0x305
a6c39a04 804dd99e bd01093c 00000039 022af32c win32k!TimersProc+0xe
a6c39a08 bd01093c 00000039 022af32c 7c90eb94 nt!ZwQueryEvent+0x13
WARNING: Frame IP not in any known module. Following frames may be wrong.
a6c39a14 7c90eb94 badb0d00 022af324 100a1870 0xbd01093c
a6c39a18 badb0d00 022af324 100a1870 00001f80 0x7c90eb94
a6c39a1c 022af324 100a1870 00001f80 bf805bb7 0xbadb0d00
a6c39a20 100a1870 00001f80 bf805bb7 bf805be9 0x22af324
a6c39a24 00000000 bf805bb7 bf805be9 000000a8 0x100a1870
STACK_COMMAND: kb
FOLLOWUP_IP:
win32k!HmgShareCheckLock+8e
bf804902 f60702 test byte ptr [edi],2
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: win32k!HmgShareCheckLock+8e
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: win32k
IMAGE_NAME: win32k.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 43446a58
FAILURE_BUCKET_ID: 0x8E_win32k!HmgShareCheckLock+8e
BUCKET_ID: 0x8E_win32k!HmgShareCheckLock+8e
Followup: MachineOwner
Bugcheck is always 8e c000005 Bucket_ID DRIVER_FAULT. Great. There's only, what, 40 or 50 devices in device mgr? It's not hardware - rebuilt the system on a different D420 with the same exact result. Of course, he reports it happens 'no matter what i'm doing' so that's no help. WinDbg follows:
0: 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: bf804902, The address that the exception occurred at
Arg3: a6c39908, 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:
win32k!HmgShareCheckLock+8e
bf804902 f60702 test byte ptr [edi],2
TRAP_FRAME: a6c39908 -- (.trap ffffffffa6c39908)
ErrCode = 00000000
eax=00000001 ebx=e180e858 ecx=e6fe41e8 edx=e6fe41e8 esi=e5190008 edi=018e0930
eip=bf804902 esp=a6c3997c ebp=a6c3998c iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!HmgShareCheckLock+0x8e:
bf804902 f60702 test byte ptr [edi],2 ds:0023:018e0930=??
Resetting default scope
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0x8E
PROCESS_NAME: explorer.exe
LAST_CONTROL_TRANSFER: from bf806148 to bf804902
STACK_TEXT:
a6c3998c bf806148 e5190008 01900010 e7696418 win32k!HmgShareCheckLock+0x8e
a6c399c0 bf80607f a6c399e0 bf803e57 e5190008 win32k!XDCOBJ::bCleanDC+0x198
a6c399c8 bf803e57 e5190008 00000039 022af32c win32k!XDCOBJ::bCleanDC+0x3b
a6c399e0 bf803ee0 bd01093c 00000000 a6c39a04 win32k!_GetDCEx+0xdc
a6c399f0 bf8010ca bd01093c a6c39a14 022af32c win32k!_GetDCEx+0x305
a6c39a04 804dd99e bd01093c 00000039 022af32c win32k!TimersProc+0xe
a6c39a08 bd01093c 00000039 022af32c 7c90eb94 nt!ZwQueryEvent+0x13
WARNING: Frame IP not in any known module. Following frames may be wrong.
a6c39a14 7c90eb94 badb0d00 022af324 100a1870 0xbd01093c
a6c39a18 badb0d00 022af324 100a1870 00001f80 0x7c90eb94
a6c39a1c 022af324 100a1870 00001f80 bf805bb7 0xbadb0d00
a6c39a20 100a1870 00001f80 bf805bb7 bf805be9 0x22af324
a6c39a24 00000000 bf805bb7 bf805be9 000000a8 0x100a1870
STACK_COMMAND: kb
FOLLOWUP_IP:
win32k!HmgShareCheckLock+8e
bf804902 f60702 test byte ptr [edi],2
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: win32k!HmgShareCheckLock+8e
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: win32k
IMAGE_NAME: win32k.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 43446a58
FAILURE_BUCKET_ID: 0x8E_win32k!HmgShareCheckLock+8e
BUCKET_ID: 0x8E_win32k!HmgShareCheckLock+8e
Followup: MachineOwner
