Debugging Stop 0x1E - KMODE_EXCEPTION_NOT_HANDLED

[x BlueRobot]

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: ffffffffc0000005, The exception code that was not handled
Arg2: fffff803796082b6, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: ffffffffffffffff, Parameter 1 of the exception

The debugging methodology for this bugcheck is very the same as Stop 0x7E and Stop 0x3B. Although, this time, the bugcheck parameters do not provide us with a context record or an exception record. However, we can easily obtain this information from the call stack, but first of all, let's examine the parameters for the crash. The first parameter again highlights the exception which has been thrown, in this case, it is a access violation or general protection fault.

15: kd> !error c0000005
Error code: (NTSTATUS) 0xc0000005 (3221225477) - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

The second parameter contains the address of the function where the exception was thrown. We can use the ln command to find out which function the address is associated to. The third and fourth parameters are the arguments passed to our exception record which we'll obtain shortly.

15: kd> ln fffff803796082b6
Browse module
Set bu breakpoint

(fffff803`79608290)   nt!ObfDereferenceObjectWithTag+0x26   |  (fffff803`79608380)   nt!ObfReferenceObject

It seems the the debugger has decided to give us two possible functions. Let's examine the call stack to confirm which one it is.

15: kd> knL
 # Child-SP          RetAddr           Call Site
00 ffffbc81`fae92158 fffff803`798f5a6e nt!KeBugCheckEx
01 ffffbc81`fae92160 fffff803`7980006f nt!HvlpVtlCallExceptionHandler+0x22
02 ffffbc81`fae921a0 fffff803`796e6dd7 nt!RtlpExecuteHandlerForException+0xf
03 ffffbc81`fae921d0 fffff803`796e59d6 nt!RtlDispatchException+0x297
04 ffffbc81`fae928f0 fffff803`797f8042 nt!KiDispatchException+0x186
05 ffffbc81`fae92fb0 fffff803`797f8010 nt!KxExceptionDispatchOnExceptionStack+0x12
06 ffffa881`9570f348 fffff803`798092a5 nt!KiExceptionDispatchOnExceptionStackContinue
07 ffffa881`9570f350 fffff803`79804fe0 nt!KiExceptionDispatch+0x125
08 ffffa881`9570f530 fffff803`796082b6 nt!KiGeneralProtectionFault+0x320
09 ffffa881`9570f6c0 fffff803`7960827e nt!ObfDereferenceObjectWithTag+0x26
0a ffffa881`9570f700 fffff803`9047b1e8 nt!HalPutDmaAdapter+0xe
0b ffffa881`9570f730 fffff803`9047b160 afd!AfdDerefPollInfoFileObjects+0x48
0c ffffa881`9570f760 fffff803`9047bdbe afd!AfdCompletePollIrp+0x74
0d ffffa881`9570f7b0 fffff803`79681612 afd!AfdTimeoutPoll+0x2e
0e ffffa881`9570f7e0 fffff803`7969991d nt!KiProcessExpiredTimerList+0x172
0f ffffa881`9570f8d0 fffff803`797fad1e nt!KiRetireDpcList+0x5dd
10 ffffa881`9570fb60 00000000`00000000 nt!KiIdleLoop+0x9e

It seems that the function where the exception was thrown is ObfDeferenceObjectWithTag. This immediately followed up a general protection fault which is the exception which was thrown. To confirm our findings are definitely correct, let's dump the exception record; we can find this information by checking the first parameter of the RtlDispatchException function. There is two ways of accomplishing this: use a third-party extension like !stack -p or by using kV. I'll show the latter method since most of you won't have CMKD.dll installed.

15: kd> kV
 # Child-SP          RetAddr           : Args to Child                                                           : Call Site
00 ffffbc81`fae92158 fffff803`798f5a6e : 00000000`0000001e ffffffff`c0000005 fffff803`796082b6 00000000`00000000 : nt!KeBugCheckEx
01 ffffbc81`fae92160 fffff803`7980006f : fffff803`798f5a4c 00000000`00000000 00000000`00000000 00000000`00000000 : nt!HvlpVtlCallExceptionHandler+0x22
02 ffffbc81`fae921a0 fffff803`796e6dd7 : ffffbc81`fae92710 00000000`00000000 ffffa881`9570fb60 fffff803`797fad1e : nt!RtlpExecuteHandlerForException+0xf
03 ffffbc81`fae921d0 fffff803`796e59d6 : ffffa881`9570f488 ffffbc81`fae92e20 ffffa881`9570f488 ffffab05`986ece28 : nt!RtlDispatchException+0x297
04 ffffbc81`fae928f0 fffff803`797f8042 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchException+0x186
05 ffffbc81`fae92fb0 fffff803`797f8010 : fffff803`798092a5 00000000`0000ffff 00000000`0000002f 00000000`fae40180 : nt!KxExceptionDispatchOnExceptionStack+0x12 (TrapFrame @ ffffbc81`fae92e70)
06 ffffa881`9570f348 fffff803`798092a5 : 00000000`0000ffff 00000000`0000002f 00000000`fae40180 fffff803`79723b80 : nt!KiExceptionDispatchOnExceptionStackContinue
07 ffffa881`9570f350 fffff803`79804fe0 : 00000000`00000000 00000000`00000001 00000000`00000011 00000000`00000000 : nt!KiExceptionDispatch+0x125
08 ffffa881`9570f530 fffff803`796082b6 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiGeneralProtectionFault+0x320 (TrapFrame @ ffffa881`9570f530)
09 ffffa881`9570f6c0 fffff803`7960827e : ffffab05`986ecd10 00000000`00000002 00000000`00000000 00000000`00000000 : nt!ObfDereferenceObjectWithTag+0x26
0a ffffa881`9570f700 fffff803`9047b1e8 : 00000000`00000001 ffffbc81`fae40180 00000000`0000001c ffffab05`968a70c0 : nt!HalPutDmaAdapter+0xe
0b ffffa881`9570f730 fffff803`9047b160 : 00000000`00000000 ffffab05`98279810 00000000`00000000 ffffab05`00000002 : afd!AfdDerefPollInfoFileObjects+0x48
0c ffffa881`9570f760 fffff803`9047bdbe : 00000000`00000008 ffffab05`986ecd30 ffffbc81`fae40180 ffffa881`9570fa10 : afd!AfdCompletePollIrp+0x74
0d ffffa881`9570f7b0 fffff803`79681612 : ffffab05`986ecd70 ffffbc81`fae40180 ffffbc81`fae40180 00000000`00000002 : afd!AfdTimeoutPoll+0x2e
0e ffffa881`9570f7e0 fffff803`7969991d : 00000000`00000000 00000000`00000000 00000000`00140001 00000000`000e7f9c : nt!KiProcessExpiredTimerList+0x172
0f ffffa881`9570f8d0 fffff803`797fad1e : ffffffff`00000000 ffffbc81`fae40180 ffffbc81`fae4b540 ffffab05`98c10080 : nt!KiRetireDpcList+0x5dd
10 ffffa881`9570fb60 00000000`00000000 : ffffa881`95710000 ffffa881`95709000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x9e

We can then use the .exr command:

15: kd> .exr ffffa881`9570f488
ExceptionAddress: fffff803796082b6 (nt!ObfDereferenceObjectWithTag+0x0000000000000026)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

Notice the exception parameters from the third and fourth bugcheck arguments? It would seem that the address being referenced is invalid and certainly does not point to any valid address, hence why the general protection fault exception was thrown. In this circumstance, the best course of action would be to either run Driver Verifier or run MemTest86.