Code:
[COLOR=#ff0000]BugCheck 101[/COLOR], {19, 0, [COLOR=#008000]fffff880030a5180[/COLOR], [COLOR=#0000cd]5[/COLOR]}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
I've highlighted the most interesting parameters of the bugcheck.
Code:
0: kd> [COLOR=#008000]r $bug_param3[/COLOR]
$bug_param3=[COLOR=#ff0000]fffff880030a5180[/COLOR]
The address of the PRCB of the hung processor, we'll use the !prcb extension with this address in a moment.
Code:
0: kd> [COLOR=#008000]r $bug_param4[/COLOR]
$bug_param4=[URL="tel:000000000000000"]000000000000000[/URL][COLOR=#ff0000]5[/COLOR]
The processor index which has become hung, the PRCB will have the same index number.
Let's dump the call stack and examine what is happening:
Code:
0: kd> [COLOR=#008000]knL[/COLOR]
# Child-SP RetAddr Call Site
00 fffff880`0334d3e8 fffff800`02ee0b79 nt!KeBugCheckEx
01 fffff880`0334d3f0 fffff800`02e90be7 nt! ?? ::FNODOBFM::`string'+0x4e3e
02 fffff880`0334d480 fffff800`03407895 nt!KeUpdateSystemTime+0x377
03 fffff880`0334d580 fffff800`02e82953 [COLOR=#ff0000]hal!HalpHpetClockInterrupt+0x8d[/COLOR]
04 fffff880`0334d5b0 fffff800`02e8bee0 nt!KiInterruptDispatchNoLock+0x163
05 fffff880`0334d740 fffff800`02ecbb6c [COLOR=#ff0000]nt!KeFlushMultipleRangeTb+0x260[/COLOR]
06 fffff880`0334d810 fffff800`02ec89a1 nt!MmSetAddressRangeModified+0x2b0
07 fffff880`0334d910 fffff800`02ecc2f6 [COLOR=#ff0000]nt!CcFlushCache+0x561[/COLOR]
08 fffff880`0334da10 fffff800`02ecccc4 nt!CcWriteBehind+0x1c6
09 fffff880`0334dac0 fffff800`02e90749 nt!CcWorkerThread+0x1c8
0a fffff880`0334db70 fffff800`0311ebc6 nt!ExpWorkerThread+0x111
0b fffff880`0334dc00 fffff800`02e786a6 nt!PspSystemThreadStartup+0x5a
0c fffff880`0334dc40 00000000`00000000 nt!KxStartSystemThread+0x16
The call stack is a standard call stack where you would see a TLB flush take place. The cache is requested to be flushed, this in turn results in the TLB of each processor core to be flushed as well. This activity is typically handled by an inter-processor interrupt. The inter-processor interrupt was sent by Processor 0 to all the other processors in the system. We can examine this using the
!ipi debugger extension:
Code:
5: kd> [COLOR=#008000]!ipi[/COLOR]
IPI State for Processor 0
As a sender, awaiting IPI completion from processor(s) 4, [COLOR=#ff0000]5[/COLOR], 6, 7.
TargetCount 4 PacketBarrier 1 IpiFrozen 0 [Running]
IPI State for Processor 1
As a sender, awaiting IPI completion from processor(s) 6, 7.
TargetCount 2 PacketBarrier 1 IpiFrozen 2 [Frozen]
IPI State for Processor 2
As a sender, awaiting IPI completion from processor(s) 6, 7.
TargetCount 2 PacketBarrier 1 IpiFrozen 2 [Frozen]
IPI State for Processor 3
TargetCount 0 PacketBarrier 0 IpiFrozen 2 [Frozen]
IPI State for Processor 4
As a receiver, unhandled requests are pending from processor(s) 0.
TargetCount 0 PacketBarrier 0 IpiFrozen 5 [Target Freeze]
From processor 0, active request of type: flush multiple range
Flush Count 1 Flush List fffff8800334d838 (dp fffff8800334d838 l1)
IPI State for Processor 5
As a receiver, unhandled requests are pending from processor(s) 0.
TargetCount 0 PacketBarrier 0 IpiFrozen 5 [Target Freeze]
From processor 0, active request of type: [COLOR=#ff0000]flush multiple range[/COLOR]
Flush Count 1 Flush List fffff8800334d838 (dp fffff8800334d838 l1)
IPI State for Processor 6
As a receiver, unhandled requests are pending from processor(s) 0, 1, 2.
TargetCount 0 PacketBarrier 0 IpiFrozen 5 [Target Freeze]
From processor 0, active request of type: flush multiple range
Flush Count 1 Flush List fffff8800334d838 (dp fffff8800334d838 l1)
From processor 1, active request of type: packet ready
WorkerRoutine fffff80002e78bd0 (nt!xHalReferenceHandler)
Parameter[0] 0 Parameter[1] 0 Parameter[2] 0
From processor 2, active request of type: flush all
IPI State for Processor 7
As a receiver, unhandled requests are pending from processor(s) 0, 1, 2.
TargetCount 0 PacketBarrier 0 IpiFrozen 5 [Target Freeze]
From processor 0, active request of type: flush multiple range
Flush Count 1 Flush List fffff8800334d838 (dp fffff8800334d838 l1)
From processor 1, active request of type: packet ready
WorkerRoutine fffff80002e78bd0 (nt!xHalReferenceHandler)
Parameter[0] 0 Parameter[1] 0 Parameter[2] 0
From processor 2, active request of type: flush all
As we can see, Processor 5 still has a pending request from Processor 0. Let's dump the current IRQL level of Processor 5:
Code:
5: kd> [COLOR=#008000]!irql[/COLOR]
Debugger saved IRQL for processor 0x5 -- 0 ([COLOR=#ff0000]LOW_LEVEL[/COLOR])
The IRQL level doesn't appear to be saved for this processor, otherwise the interrupt should have been handled easily.
Let's dump the currently executing thread on the processor:
Code:
5: kd> [COLOR=#008000]!thread[/COLOR]
THREAD fffffa801084aad0 Cid 0758.1a1c Teb: 000007ffffecc000 Win32Thread: fffff900c223f660 RUNNING on processor 5
Not impersonating
DeviceMap fffff8a0018f1750
Owning Process fffffa8011f52a30 Image: [COLOR=#ff0000]TslGame.exe[/COLOR]
Attached Process N/A Image: N/A
Wait Start TickCount [URL="tel:1251225"]1251225[/URL] Ticks: 408 (0:00:00:06.364)
Context Switch Count 21104743 IdealProcessor: 0 LargeStack
UserTime 04:13:50.096
KernelTime 00:03:01.210
Win32 Start Address 0x000000013fbb53f0
Stack Init fffff880086d9c70 Current fffff880086d9960
Base [COLOR=#800080]fffff880086da000[/COLOR] Limit [COLOR=#0000cd]fffff880086d2000[/COLOR] Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
We'll use the dps command to dump the raw stack of the thread.
I've attempted to reconsruct parts of the raw stack into a call stack, however, it may be incomplete or just wrong:
Code:
5: kd> [COLOR=#008000]k= fffff880`086d63b0 fffff880`0ff6f749 10[/COLOR]
# Child-SP RetAddr Call Site
00 fffff880`086d63b0 fffff880`0ff69411 dxgmms1!VidSchiUpdateCurrentIsrFrameTime+0x95
01 fffff880`086d63e0 fffff880`0ff69097 dxgmms1!VidSchiProcessIsrVSync+0xc9
02 fffff880`086d6470 fffffa80`10757010 dxgmms1!VidSchDdiNotifyInterruptWorker+0xef
03 fffff880`086d64c0 fffff880`086d6740 0xfffffa80`10757010
04 fffff880`086d64c8 fffff880`0ff69097 0xfffff880`086d6740
05 fffff880`086d64d0 fffff880`0ff68f96 dxgmms1!VidSchDdiNotifyInterruptWorker+0xef
06 fffff880`086d6520 fffff880`03c0313f dxgmms1!VidSchDdiNotifyInterrupt+0x9e
07 fffff880`086d6550 fffff880`0f14d233 dxgkrnl!DxgNotifyInterruptCB+0x83
08 fffff880`086d6580 fffff880`0f14df37 nvlddmkm+0xfc233
09 fffff880`086d6610 fffff880`0f0aa808 nvlddmkm+0xfcf37
0a fffff880`086d66c0 fffffa80`10757010 nvlddmkm+0x59808
0b fffff880`086d67a0 fffff880`086d6a20 0xfffffa80`10757010
0c fffff880`086d67a8 fffff880`0ff69097 0xfffff880`086d6a20
0d fffff880`086d67b0 fffff880`0ff68f96 dxgmms1!VidSchDdiNotifyInterruptWorker+0xef
0e fffff880`086d6800 fffff880`03c0313f dxgmms1!VidSchDdiNotifyInterrupt+0x9e
0f fffff880`086d6830 fffff880`0f14d233 dxgkrnl!DxgNotifyInterruptCB+0x83
I made another attempt in a different part of the stack too:
Code:
5: kd> [COLOR=#008000]k= fffff880`086d93f8 fffff800`02ea9fe0 10[/COLOR]
# Child-SP RetAddr Call Site
00 fffff880`086d93f8 fffff880`07e5a4dc nt!PsGetCurrentProcessId
01 fffff880`086d9400 00000000`00000000 [COLOR=#ff0000]BEDaisy+0x4a4dc[/COLOR]
I would consider removing the following driver from your system or finding an update for it.
Code:
5: kd> [COLOR=#008000]lmvm BEDaisy[/COLOR]
start end module name
fffff880`07e10000 fffff880`07ebf000 BEDaisy (no symbols)
Loaded symbol image file: BEDaisy.sys
Image path: \??\C:\Program Files (x86)\Common Files\BattlEye\BEDaisy.sys
Image name: BEDaisy.sys
Timestamp: [COLOR=#ff0000]Wed Jan 11 03:01:10 2017 [/COLOR](58759FF6)
CheckSum: [URL="tel:00071812"]00071812[/URL]
ImageSize: 000AF000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
The driver belongs to your Battleeye anti-cheat program.
The Interrupt Flag was disabled, although, are IPIs maskable?
Code:
5: kd> [COLOR=#008000]r @if[/COLOR]
if=[COLOR=#ff0000]0[/COLOR]