Crash Dump Analysis Patterns (Part 2b)

Here is an additional kernel space example to my old Dynamic Memory Corruption pattern. If kernel pools are corrupt then calls that allocate or free memory result in bugchecks C2 or 19 and in other less frequent bugchecks (from Google stats):

















Bug Checks 0xC2 and 0×19 have parameters in bugcheck arguments that tell the type of detected pool corruption. Refer to WinDbg help for details or use the variant of !analyze command where you can supply optional bugcheck arguments:

1: kd> !analyze -show c2
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arg1: 00000000, The caller is requesting a zero byte pool allocation.
Arg2: 00000000, zero.
Arg3: 00000000, the pool type being allocated.
Arg4: 00000000, the pool tag being used.

1: kd> !analyze -show 19 2 1 1 1
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.
Arg1: 00000002, the verifier pool pattern check failed.  The owner has likely corrupted the pool block
Arg2: 00000001, the pool entry being checked.
Arg3: 00000001, size of the block.
Arg4: 00000001, 0.

If we enable special pool on suspected drivers we might get these bugchecks too with the following Google frequency:







Here is one example of nonpaged pool corruption detected during free operation with the following !analyze -v output:

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.
Arg1: 00000020, a pool block header size is corrupt.
Arg2: a34583b8, The pool entry we were looking for within the page.
Arg3: a34584f0, The next pool entry.
Arg4: 0a270001, (reserved)

POOL_ADDRESS:  a34583b8 Nonpaged pool

PROCESS_NAME:  process.exe


b80a60cc 808927bb nt!KeBugCheckEx+0x1b
b80a6134 80892b6f nt!ExFreePoolWithTag+0x477
b80a6144 b9591400 nt!ExFreePool+0xf
WARNING: Stack unwind information not available. Following frames may be wrong.
b80a615c b957b954 driver+0x38400
b80a617c b957d482 driver+0x22954
b80a61c0 b957abf4 driver+0x24482
b80a6260 b957ccef driver+0x21bf4
b80a62a8 8081df65 driver+0x23cef
b80a62bc f721ac45 nt!IofCallDriver+0x45
b80a62e4 8081df65 fltMgr!FltpDispatch+0x6f
b80a62f8 b99de70b nt!IofCallDriver+0x45
b80a6308 b99da6ee filter!Dispatch+0xfb
b80a6318 8081df65 filter!dispatch+0x6e
b80a632c b9bdebfe nt!IofCallDriver+0x45
b80a6334 8081df65 2ndfilter!Redirect+0x7ea
b80a6348 b9bd1756 nt!IofCallDriver+0x45
b80a6374 b9bd1860 3rdfilter!PassThrough+0x136
b80a6384 8081df65 3rdfilter!Dispatch+0x80
b80a6398 808f5437 nt!IofCallDriver+0x45
b80a63ac 808ef963 nt!IopSynchronousServiceTail+0x10b
b80a63d0 8088978c nt!NtQueryDirectoryFile+0x5d
b80a63d0 7c8285ec nt!KiFastCallEntry+0xfc
00139524 7c8274eb ntdll!KiFastSystemCallRet
00139528 77e6ba40 ntdll!NtQueryDirectoryFile+0xc
00139830 77e6bb5f kernel32!FindFirstFileExW+0x3d5
00139850 6002665e kernel32!FindFirstFileW+0x16
00139e74 60026363 process+0x2665e
0013a328 60027852 process+0x26363
0013a33c 60035b58 process+0x27852
0013b104 600385ff process+0x35b58
0013b224 612cb643 process+0x385ff
0013b988 612cc109 dll!FileDialog+0xc53
0013bba0 612cb47b dll!FileDialog+0x1719
0013c2c0 7739b6e3 dll!FileDialog+0xa8b
0013c2ec 77395f82 USER32!InternalCallWinProc+0x28
0013c368 77395e22 USER32!UserCallDlgProcCheckWow+0x147
0013c3b0 7739c9c6 USER32!DefDlgProcWorker+0xa8
0013c3d8 7c828536 USER32!__fnDWORD+0x24
0013c3d8 808308f4 ntdll!KiUserCallbackDispatcher+0x2e
b80a66b8 8091d6d1 nt!KiCallUserMode+0x4
b80a6710 bf8a2622 nt!KeUserModeCallback+0x8f
b80a6794 bf8a2517 win32k!SfnDWORD+0xb4
b80a67dc bf8a13d9 win32k!xxxSendMessageToClient+0x133
b80a6828 bf85ae67 win32k!xxxSendMessageTimeout+0x1a6
b80a684c bf8847a1 win32k!xxxWrapSendMessage+0x1b
b80a6868 bf8c1459 win32k!NtUserfnNCDESTROY+0x27
b80a68a0 8088978c win32k!NtUserMessageCall+0xc0
b80a68a0 7c8285ec nt!KiFastCallEntry+0xfc
0013c3d8 7c828536 ntdll!KiFastSystemCallRet
0013c3d8 808308f4 ntdll!KiUserCallbackDispatcher+0x2e
b80a6b7c 8091d6d1 nt!KiCallUserMode+0x4
b80a6bd4 bf8a2622 nt!KeUserModeCallback+0x8f
b80a6c58 bf8a23a0 win32k!SfnDWORD+0xb4
b80a6ca0 bf8a13d9 win32k!xxxSendMessageToClient+0x118
b80a6cec bf85ae67 win32k!xxxSendMessageTimeout+0x1a6
b80a6d10 bf8c148c win32k!xxxWrapSendMessage+0x1b
b80a6d40 8088978c win32k!NtUserMessageCall+0x9d
b80a6d40 7c8285ec nt!KiFastCallEntry+0xfc
0013f474 7c828536 ntdll!KiFastSystemCallRet
0013f4a0 7739d1ec ntdll!KiUserCallbackDispatcher+0x2e
0013f4dc 7738cf29 USER32!NtUserMessageCall+0xc
0013f4fc 612d3276 USER32!SendMessageA+0x7f
0013f63c 611add41 dll!SubWindow+0x3dc6
0013f658 7739b6e3 dll!SetWindowText+0x37a1
0013f684 7739b874 USER32!InternalCallWinProc+0x28
0013f6fc 7739ba92 USER32!UserCallWinProcCheckWow+0x151
0013f764 7739bad0 USER32!DispatchMessageWorker+0x327
0013f774 61221ca8 USER32!DispatchMessageW+0xf
0013f7e0 0040156d dll!MainLoop+0x2c8
0013ff24 00401dfa process+0x156d
0013ffc0 77e6f23b process+0x1dfa
0013fff0 00000000 kernel32!BaseProcessStart+0x23


IMAGE_NAME:  driver.sys

We see that WinDbg pointed to driver.sys by using a procedure described in one of my old minidump analysis posts: BugCheck C2 Minidump Analysis

However any OS component could corrupt the pool prior to detection as the bugcheck description says: “The pool is already corrupt at the time of the current request.”. What other evidence can reinforce our belief in driver.sys? Let’s look at our pool entry tag first:

1: kd> !pool a34583b8
Pool page a34583b8 region is Nonpaged pool
 a3458000 size:  270 previous size:    0  (Allocated)  Thre (Protected)
 a3458270 size:   10 previous size:  270  (Free)       RxIr
 a3458280 size:   40 previous size:   10  (Allocated)  Vadl
 a34582c0 size:   98 previous size:   40  (Allocated)  File (Protected)
 a3458358 size:    8 previous size:   98  (Free)       Vadl
 a3458360 size:   50 previous size:    8  (Allocated)  Gsem
 a34583b0 size:    8 previous size:   50  (Free)       CcSc
*a34583b8 size:  138 previous size:    8  (Allocated) *DRIV
  Owning component : Unknown (update pooltag.txt)
a34584f0 is not a valid large pool allocation, checking large session pool…
a34584f0 is freed (or corrupt) pool
Bad allocation size @a34584f0, zero is invalid

*** An error (or corruption) in the pool was detected;
*** Attempting to diagnose the problem.
*** Use !poolval a3458000 for more details.

Pool page [ a3458000 ] is __inVALID.

Analyzing linked list...
[ a34583b8 --> a34583d8 (size = 0x20 bytes)]: Corrupt region
[ a34583f8 --> a34585e8 (size = 0x1f0 bytes)]: Corrupt region

Scanning for single bit errors...

None found

We see that the tag is DRIV and we know either from association or from similar problems in the past that it belongs to driver.sys. Let’s dump our pool entry contents to see if there are any symbolic hints in it:

1: kd> dps a34583b8
a34583b8 0a270001
a34583bc 5346574e
a34583c0 00000000
a34583c4 00000000
a34583c8 b958f532 driver+0×36532
a34583cc a3471010
a34583d0 0000012e
a34583d4 00000001
a34583d8 00041457
a34583dc 05af0026
a34583e0 00068002
a34583e4 7b9ec6f5
a34583e8 ffffff00
a34583ec 73650cff
a34583f0 7461445c
a34583f4 97a10061
a34583f8 ff340004
a34583fc c437862a
a3458400 6a000394
a3458404 00000038
a3458408 00000000
a345840c bf000000
a3458410 bf0741b5
a3458414 f70741b5
a3458418 00000000
a345841c 00000000
a3458420 00000000
a3458424 00000000
a3458428 05000000
a345842c 34303220
a3458430 31323332
a3458434 ff322d36

Indeed we see the possible code pointer driver+0×36532 and the code around this address looks normal:

3: kd> .asm no_code_bytes
Assembly options: no_code_bytes

3: kd> u b958f532
b958f532 push    2Ch
b958f534 push    offset driver+0x68d08 (b95c1d08)
b958f539 call    driver+0x65c50 (b95bec50)
b958f53e mov     byte ptr [ebp-19h],0
b958f542 and     dword ptr [ebp-24h],0
b958f546 call    dword ptr [driver+0x65f5c (b95bef5c)]
b958f54c mov     ecx,dword ptr [ebp+0Ch]
b958f54f cmp     eax,ecx

3: kd> ub b958f532
b958f528 leave
b958f529 ret     18h
b958f52c int     3
b958f52d int     3
b958f52e int     3
b958f52f int     3
b958f530 int     3
b958f531 int     3

- Dmitry Vostokov @ -

9 Responses to “Crash Dump Analysis Patterns (Part 2b)”

  1. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 71) Says:

    […] memory corruption patterns in user and kernel spaces are specializations of one big parent pattern called Corrupt Structure […]

  2. Adolfo Guzman Says:

    Hello All
    I have the same problem with a BAD POOL HEADER
    following all your post , I could find the problem
    the pool header e173c1d8 is corrupted allocated *Ppen (Could you help me to know what is that??)
    Let me attached the results for a better explanation of the problem.
    I hope you or any other people can help me , I am a newbie on this.
    Thank you so much.

    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.
    Arg1: 00000020, a pool block header size is corrupt.
    Arg2: e173c1d8, The pool entry we were looking for within the page.
    Arg3: e173c1f8, The next pool entry.
    Arg4: 0c040404, (reserved)

    Debugging Details:

    BUGCHECK_STR: 0×19_20

    POOL_ADDRESS: e173c1d8



    PROCESS_NAME: System

    LOCK_ADDRESS: 8055b4e0 — (!locks 8055b4e0)

    Resource @ nt!PiEngineLock (0×8055b4e0) Available

    WARNING: SystemResourcesList->Flink chain invalid. Resource may be corrupted, or already deleted.

    WARNING: SystemResourcesList->Blink chain invalid. Resource may be corrupted, or already deleted.

    1 total locks

    Lock address : 0×8055b4e0
    Thread Count : 0
    Thread address: 0×00000000
    Thread wait : 0×0

    LAST_CONTROL_TRANSFER: from 8054b583 to 804f9f33

    f79f392c 8054b583 00000019 00000020 e173c1d8 nt!KeBugCheckEx+0×1b
    f79f397c 8058fc05 e173c1e0 00000000 00000000 nt!ExFreePoolWithTag+0×2a3
    f79f39dc 8059161d 85804dd0 e10f29a8 f79f3a48 nt!PipMakeGloballyUniqueId+0×3a9
    f79f3ad0 8059222b 8593a7c8 861d33e8 8593a7c8 nt!PipProcessNewDeviceNode+0×185
    f79f3d24 805927fa 8593a7c8 00000001 00000000 nt!PipProcessDevNodeTree+0×16b
    f79f3d54 804f698e 00000003 8055b5c0 8056485c nt!PiRestartDevice+0×80
    f79f3d7c 8053876d 00000000 00000000 863c1da8 nt!PipDeviceActionWorker+0×168
    f79f3dac 805cff64 00000000 00000000 00000000 nt!ExpWorkerThread+0xef
    f79f3ddc 805460de 8053867e 00000001 00000000 nt!PspSystemThreadStartup+0×34
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0×16


    8054b583 8b45f8 mov eax,dword ptr [ebp-8]


    SYMBOL_NAME: nt!ExFreePoolWithTag+2a3

    FOLLOWUP_NAME: MachineOwner


    IMAGE_NAME: ntkrpamp.exe


    FAILURE_BUCKET_ID: 0×19_20_nt!ExFreePoolWithTag+2a3

    BUCKET_ID: 0×19_20_nt!ExFreePoolWithTag+2a3

    Followup: MachineOwner

    0: kd> !IRP 000000020
    00000020: Could not read Irp
    0: kd> !POOL 00000020
    The pool page you have specified is not in this dump.
    0: kd> !pool e173c1d8
    Pool page e173c1d8 region is Unknown
    e173c000 size: 28 previous size: 0 (Allocated) CMVa
    e173c028 size: 8 previous size: 28 (Free) 0…
    e173c030 size: 10 previous size: 8 (Allocated) MmSt
    e173c040 size: 48 previous size: 10 (Allocated) ScSh
    e173c088 size: 68 previous size: 48 (Allocated) ScNc
    e173c0f0 size: 8 previous size: 68 (Free) Ntf0
    e173c0f8 size: 10 previous size: 8 (Allocated) ObDi
    e173c108 size: 28 previous size: 10 (Allocated) CMVa
    e173c130 size: 80 previous size: 28 (Allocated) IoNm
    e173c1b0 size: 8 previous size: 80 (Free) Sect
    e173c1b8 size: 20 previous size: 8 (Allocated) CMVa
    *e173c1d8 size: 20 previous size: 20 (Allocated) *Ppen
    Pooltag Ppen : routines to perform device enumeration, Binary : nt!pnp
    GetUlongFromAddress: unable to read from 80565d50
    e173c1f8 is not a valid small pool allocation, checking large pool…
    unable to get pool big page table - either wrong symbols or pool tagging is disabled
    e173c1f8 is freed (or corrupt) pool
    Bad previous allocation size @e173c1f8, last size was 4

    *** An error (or corruption) in the pool was detected;
    *** Pool Region unknown (0xFFFFFFFFE173C1F8)
    *** Use !poolval e173c000 for more details.

    0: kd> !poolval e173c000
    Pool page e173c000 region is Unknown

    Validating Pool headers for pool page: e173c000

    Pool page [ e173c000 ] is __inVALID.

    Analyzing linked list…
    [ e173c1d8 –> e173c2c0 (size = 0xe8 bytes)]: Corrupt region

    Scanning for single bit errors…

    None found

    0: kd> dps e173c1d8
    e173c1d8 0c040404
    e173c1dc 6e657050
    e173c1e0 00260032
    e173c1e4 00370061
    e173c1e8 00360035
    e173c1ec 00370035
    e173c1f0 00260032
    e173c1f4 004e0030
    e173c1f8 00520054
    e173c1fc 004c004f
    e173c200 002e0053
    e173c204 0055004d
    e173c208 005c0049
    e173c20c 002e0036
    e173c210 002e0030
    e173c214 00360032
    e173c218 00300030
    e173c21c 0c12040a
    e173c220 e24e4d43
    e173c224 00010001
    e173c228 7224c689
    e173c22c e17b53a4
    e173c230 23230077
    e173c234 4448233f
    e173c238 49445541
    e173c23c 5546234f
    e173c240 305f434e
    e173c244 45562631
    e173c248 31315f4e
    e173c24c 44264431
    e173c250 375f5645
    e173c254 26353036

  3. Dmitry Vostokov Says:

    > Pooltag Ppen : routines to perform device enumeration, Binary : nt!pnp

    Ppen is from PnP manager

    If we search for this stack trace frame:


    we find a discussion of similar BSOD and perhaps a solution:

  4. Crash Dump Analysis » Blog Archive » Reflecting on 2008 (Part 1) Says:

    […] memory dump userdump windbg !analyze zwusergetmessage memory dump analysis anthology, volume 1 pool corruption windbg windows vista crash dump failure_bucket_id frame ip not in any known module kiswapcontext […]

  5. Crash Dump Analysis » Blog Archive » Icons for Memory Dump Analysis Patterns (Part 4) Says:

    […] we introduce an icon for Dynamic Memory Corruption (kernel pool) […]

  6. Martin Maletti Says:


    I have a similar problem with a Citrix server running windows 2003 R2 Standar x64 edition SP2.Today morning it crashed and left a 4gb size memory.dmp file.

    I used Winddebug and could get this information:
    I’m new in this field so if someone has a an explanation or a work around please go slow with details.

    Memory was referenced after it was freed.
    This cannot be protected by try-except.
    When possible, the guilty driver’s name (Unicode string) is printed on
    the bugcheck screen and saved in KiBugCheckDriver.
    Arg1: fffff97fc2872d4c, memory referenced
    Arg2: 0000000000000000, value 0 = read operation, 1 = write operation
    Arg3: fffff97fff1a730d, if non-zero, the address which referenced memory.
    Arg4: 0000000000000000, (reserved)

    Debugging Details:

    Page 89c8d not present in the dump file. Type “.hh dbgerr004″ for details
    Page 905da not present in the dump file. Type “.hh dbgerr004″ for details
    Page 905da not present in the dump file. Type “.hh dbgerr004″ for details
    Page 905da not present in the dump file. Type “.hh dbgerr004″ for details
    Page 905da not present in the dump file. Type “.hh dbgerr004″ for details
    PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type “.hh dbgerr001″ for details
    PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type “.hh dbgerr001″ for details

    READ_ADDRESS: fffff97fc2872d4c

    fffff97f`ff1a730d 0fba600c16 bt dword ptr [rax+0Ch],16h


    IMAGE_NAME: win32k.sys


    MODULE_NAME: win32k

    FAULTING_MODULE: fffff97fff000000 win32k





    TRAP_FRAME: fffffaddcbbaaea0 — (.trap 0xfffffaddcbbaaea0)
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=fffff97fc2872d40 rbx=0000000000000000 rcx=fffff97fc42b0eb0
    rdx=fffff97fc3ea8fa0 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff97fff1a730d rsp=fffffaddcbbab030 rbp=fffffaddcbbab5b0
    r8=fffffaddcbbab100 r9=0000000000000000 r10=fffffaddcbbaa760
    r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0 nv up ei pl nz na pe nc
    fffff97f`ff1a730d 0fba600c16 bt dword ptr [rax+0Ch],16h ds:b250:2d4c=????????
    Resetting default scope

    LAST_CONTROL_TRANSFER: from fffff800010a699d to fffff8000102eb50

    fffffadd`cbbaadc8 fffff800`010a699d : 00000000`00000050 fffff97f`c2872d4c 00000000`00000000 fffffadd`cbbaaea0 : nt!KeBugCheckEx
    fffffadd`cbbaadd0 fffff800`0102d719 : 00000000`00000000 00000000`00000201 fffffadd`cbbaaf00 fffff97f`f8443e60 : nt!MmAccessFault+0xa1f
    fffffadd`cbbaaea0 fffff97f`ff1a730d : 00000000`00030078 00000000`00002001 00000000`00000000 fffff97f`ff000000 : nt!KiPageFault+0×119
    fffffadd`cbbab030 fffff97f`ff0a0d98 : fffff97f`c3cacd80 fffffadd`cbbab458 00000000`00000000 00000000`00000100 : win32k!xxxScanSysQueue+0×3984
    fffffadd`cbbab360 fffff97f`ff0a5dd2 : 00000000`00000000 fffffadd`00000000 fffffaae`00000100 fffffaae`00000100 : win32k!xxxRealInternalGetMessage+0×483
    fffffadd`cbbab420 fffff800`0102e5fd : 00000000`00000000 fffff6fb`7dbed000 fffffaae`96d6cf90 fffffadd`cbbab5b0 : win32k!NtUserPeekMessage+0xad
    fffffadd`cbbab4c0 00000000`6b2b5e2a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0×3
    00000000`0013bf58 fffff800`010267d0 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0×6b2b5e2a
    fffffadd`cbbab8c0 00000000`00000000 : 00000000`00000000 00000000`00000001 00000000`00000000 00000000`00000001 : nt!KiCallUserMode


    fffff97f`ff1a730d 0fba600c16 bt dword ptr [rax+0Ch],16h


    SYMBOL_NAME: win32k!xxxScanSysQueue+3984

    FOLLOWUP_NAME: MachineOwner

    FAILURE_BUCKET_ID: X64_0xD5_VRF_win32k!xxxScanSysQueue+3984

    BUCKET_ID: X64_0xD5_VRF_win32k!xxxScanSysQueue+3984

    Followup: MachineOwner

    I had a similar problem once related with Symantec, where Symantec’s KB said the following:

    A blue screen appears with the error message “STOP: 0×000000c4 DRIVER_VERIFIER_DETECTED_VIOLATION.” Driver Verifier points to Spbbcdrv.sys as the offending driver with either Symantec AntiVirus or Symantec Endpoint Protection installed and tamper protection enabled.


    To fix the problem, disable Driver Verifier and then restart the computer.

    To disable Driver Verifier

    On the Windows taskbar, click Start > Run.
    In the Run box, type verifier and click OK.
    Click Delete existing settings and then click Finish.
    Click Yes.
    Click OK.
    Restart the computer.

    I performed those steps and worked, but know i have another dump i want to hear opinions of people who know more about this field and check If I can apply any of those sugestions.

    Thanks in advance

  7. Dmitry Vostokov Says:

    Hi Martin,

    You can contact Memory Dump Analysis Services for an audit of memory dump analysis: and choose an SLA:


  8. Dmitry Vostokov Says:

    VolatilePool Enabler:

  9. Dmitry Vostokov Says:

    Pool corruption may cause access violations in pool management with general bugchecks such as KMODE_EXCEPTION_NOT_HANDLED (1e):

    0: kd> k
    # Child-SP RetAddr Call Site
    00 fffff802`d2afe568 fffff802`d103db86 nt!KeBugCheckEx
    01 fffff802`d2afe570 fffff802`d0fc652d nt!KiFatalExceptionHandler+0×22
    02 fffff802`d2afe5b0 fffff802`d0e83139 nt!RtlpExecuteHandlerForException+0xd
    03 fffff802`d2afe5e0 fffff802`d0e815a8 nt!RtlDispatchException+0×429
    04 fffff802`d2afece0 fffff802`d0fcb0c2 nt!KiDispatchException+0×144
    05 fffff802`d2aff3c0 fffff802`d0fc957d nt!KiExceptionDispatch+0xc2
    06 fffff802`d2aff5a0 fffff802`d10af119 nt!KiGeneralProtectionFault+0xfd
    *** ERROR: Module load completed but symbols could not be loaded for vmci.sys
    07 fffff802`d2aff730 fffff800`84456159 nt!ExAllocatePoolWithTag+0×7c9
    08 fffff802`d2aff810 fffff800`84457131 vmci+0×6159
    09 fffff802`d2aff840 fffff800`8445398b vmci+0×7131
    0a fffff802`d2aff890 fffff802`d0eec3c0 vmci+0×398b
    0b fffff802`d2aff8c0 fffff802`d0eebad9 nt!KiExecuteAllDpcs+0×270
    0c fffff802`d2affa10 fffff802`d0fc323a nt!KiRetireDpcList+0xe9
    0d fffff802`d2affc60 00000000`00000000 nt!KiIdleLoop+0×5a

Leave a Reply

You must be logged in to post a comment.