Code:
BugCheck 101, {19, 0, fffff88002f65180, 2}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
The bugcheck indicates that a processor interrupt wasn't received within the time interval, and thus lead to undefined system behavior. The processor interrupt time elapse is monitored by a hardware watchdog. This is a form of timer which ensures that processor activity is correct, and if it isn't, it sends the kernel into a bugcheck to prevent data corruption etc.
The fourth parameter contains the processor number of the hung processor. By examining the Interrupt Flag stored within the EFLAGS register, we can check if the processor is able to receive interrupts, and it seems from the dump file that this is not possible.
Code:
0: kd> ~2
2: kd> r @if
if=0
There is no activity on the call stack too, which indicates that this processor is definitely hung.
Code:
2: kd> knL
# Child-SP RetAddr Call Site
00 00000000`00000000 00000000`00000000 0x0
The third parameter contains the address of the PRCB (Processor Region Control Block) of the hung processor.
Code:
2: kd> !prcb 2
PRCB for Processor 2 at fffff88002f65180:
Current IRQL -- 0
Threads-- Current fffff88002f700c0 Next 0000000000000000 Idle fffff88002f700c0
Processor Index 2 Number (0, 2) GroupSetMember 4
Interrupt Count -- 02b7a85f
Times -- Dpc 00000005 Interrupt 0000008f
Kernel 002a5000 User 0001c56c
The current thread address is the same thread which we produced the call stack for earlier. Let's switch back to Processor 0, and check what was meant to be received.
Code:
2: kd> ~0
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff880`0287e328 fffff800`032e8a3a nt!KeBugCheckEx
01 fffff880`0287e330 fffff800`0329b6e7 nt! ?? ::FNODOBFM::`string'+0x4e3e
02 fffff880`0287e3c0 fffff800`0380c895 nt!KeUpdateSystemTime+0x377
03 fffff880`0287e4c0 fffff800`0328e153 hal!HalpHpetClockInterrupt+0x8d <-- Clock Interrupt, used for synchronization purposes
04 fffff880`0287e4f0 fffff800`032c74af nt!KiInterruptDispatchNoLock+0x163
05 fffff880`0287e680 fffff800`032c63cd nt!KxFlushEntireTb+0xbf <-- TLB Cache Cleanup, usually after a context switch or page table structure change
06 fffff880`0287e6c0 fffff800`032ea9a0 nt!KeFlushTb+0x119
07 fffff880`0287e740 fffff800`032a178f nt! ?? ::FNODOBFM::`string'+0xada2
08 fffff880`0287e780 fffff800`032aebfe nt!MiResolveDemandZeroFault+0x1ff <-- Caused TLB FLush
09 fffff880`0287e870 fffff800`0329ee9a nt!MiDispatchFault+0x8ce
0a fffff880`0287e980 fffff800`0328fd2e nt!MmAccessFault+0x107a
0b fffff880`0287eae0 000007fe`fddb11fd nt!KiPageFault+0x16e
0c 00000000`0a4cc928 00000000`00000000 0x000007fe`fddb11fd
By looking at the call stack, we can see that some TLB (Translation Lookaside Buffer) Cache flush routines occured, the TLB Cache is used to improve performance with virtual to physical memory address translations and to prevent page walks. Any changes to the page table structure will result in a TLB Flush. This is usually acheived with the reloading of the CR3 register, which contains the base address of the Page Directory. The flushing of the TLB requires the use of a IPI (Inter Processor Interrupt). We'll investigate these later.
As a side note to anyone reading this, notice how the IPI occurs before the Clock Interrupt? That's because of IRQL masking lower priority interrupts.
Code:
0: kd> r @cr3
cr3=00000001b6089000
So, we know a Clock Interrupt has occured and a TLB flusing was required, but let's dig deeper into the dump file, and find more evidence to support our findings.
Code:
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 13
The IRQL Level has been set to Clock Interrupt level, which is 13 on x64 systems.
Code:
0: kd> !idt e1
Dumping IDT: fffff80000b95080
b0b7eae9000000e1: fffff8000329b960 nt!KiIpiInterrupt
The IPI is stored at interrupt vector e1 in the IDT (Interrupt Descriptor Table). Our Clock Interrupt is stored at the d1 interrupt vector:
Code:
0: kd> !idt d1
Dumping IDT: fffff80000b95080
b0b7eae9000000d1: fffff800038324f0 hal!HalpHpetClockInterrupt (KINTERRUPT fffff80003832460)
Code:
0: kd> !ipi
IPI State for Processor 0
TargetCount 0 PacketBarrier 0 IpiFrozen 0 [Running]
IPI State for Processor 1
As a sender, awaiting IPI completion from processor(s) 2, 3.
TargetCount 2 PacketBarrier 1 IpiFrozen 2 [Frozen]
IPI State for Processor 2
As a receiver, unhandled requests are pending from processor(s) 1, 5, 6.
TargetCount 0 PacketBarrier 0 IpiFrozen 5 [Target Freeze]
From processor 1, active request of type: flush all
From processor 5, active request of type: packet ready
WorkerRoutine fffff80003282e30 (nt!FsRtlpNopStackOverflowRoutine)
Parameter[0] 0 Parameter[1] 0 Parameter[2] 0
From processor 6, active request of type: packet ready
WorkerRoutine fffff80003282e30 (nt!FsRtlpNopStackOverflowRoutine)
Parameter[0] 0 Parameter[1] 0 Parameter[2] 0
As we can see, our hung processor has three pending requests from the other processors in the system. The flush operation is also waiting too.
Code:
1: kd> !sysinfo machineid
Machine ID Information [From Smbios 2.6, DMIVersion 38, Size=3718]
BiosMajorRelease = 4
BiosMinorRelease = 6
BiosVendor = American Megatrends Inc.
BiosVersion = 3701
BiosReleaseDate = 11/30/2012
SystemManufacturer = System manufacturer
SystemProductName = System Product Name
SystemFamily = To be filled by O.E.M.
SystemVersion = System Version
SystemSKU = SKU
BaseBoardManufacturer = ASUSTeK COMPUTER INC.
BaseBoardProduct = P8P67-M PRO
BaseBoardVersion = Rev X.0x
Stop 0x101's are usually caused by hardware, I would suggest checking for a BIOS update from your motherboard update page. Please read the BIOS updating instructions carefully, and don't attempt to update the BIOS if your not comfortable with it. I would also recommend checking for chipset updates from the same motherboard update page.
The motherboard model is highlighted in the red text.
