KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
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: 83f74359, The address that the exception occurred at
Arg3: 83a07a54, Trap Frame
Arg4: 00000000
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%08lx
FAULTING_IP:
nt!ExAllocatePoolWithTag+34f
83f74359 66894602 mov word ptr [esi+2],ax
TRAP_FRAME: 83a07a54 -- (.trap 0xffffffff83a07a54)
ErrCode = 00000003
eax=00710600 ebx=00000100 ecx=00000000 edx=000001ff esi=00710054 edi=000001ff
eip=83f74359 esp=83a07ac8 ebp=83a07b14 iopl=0 nv up ei pl nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010206
nt!ExAllocatePoolWithTag+0x34f:
83f74359 66894602 mov word ptr [esi+2],ax ds:0023:00710056=????
Resetting default scope
BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 00000022,
Arg2: 00000000
Arg3: 00000000
Arg4: 00000000