A Clock Interrupt Was Not Received On A Secondary Processor - Windows 7 x64

Stop 0x101's require a Kernel Mode Memory Dump, you'll need to navigate to this directory:

Code: 
C:\Windows\MEMORY.DMP

Copy the file(s) and place them in a zipped folder, upload the zipped folder to a file sharing site like Dropbox or SkyDrive, and then post the link to the uploaded file in your next post.
 
Code: 
[COLOR=#ff0000]BugCheck 101[/COLOR], {19, 0, [COLOR=#008000]fffff88002f65180[/COLOR], [COLOR=#0000cd]2[/COLOR]}

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> [COLOR=#008000]~2[/COLOR]
2: kd> [COLOR=#008000]r @if[/COLOR]
if=[COLOR=#ff0000]0[/COLOR]

There is no activity on the call stack too, which indicates that this processor is definitely hung.

Code: 
2: kd> [COLOR=#008000]knL[/COLOR]
 # 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> [COLOR=#008000]!prcb 2[/COLOR]
PRCB for Processor 2 at [COLOR=#ff0000]fffff88002f65180[/COLOR]:
Current IRQL -- 0
Threads--  Current [COLOR=#0000cd]fffff88002f700c0[/COLOR] 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> [COLOR=#008000]~0[/COLOR]
0: kd> [COLOR=#008000]knL[/COLOR]
 # 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 [COLOR=#ff0000]hal!HalpHpetClockInterrupt+0x8d[/COLOR] <-- Clock Interrupt, used for synchronization purposes 
04 fffff880`0287e4f0 fffff800`032c74af nt!KiInterruptDispatchNoLock+0x163
05 fffff880`0287e680 fffff800`032c63cd [COLOR=#ff0000]nt!KxFlushEntireTb+0xbf[/COLOR] <-- TLB Cache Cleanup, usually after a context switch or page table structure change
06 fffff880`0287e6c0 fffff800`032ea9a0[COLOR=#ff0000] nt!KeFlushTb+0x119[/COLOR]
07 fffff880`0287e740 fffff800`032a178f nt! ?? ::FNODOBFM::`string'+0xada2
08 fffff880`0287e780 fffff800`032aebfe [COLOR=#ff0000]nt!MiResolveDemandZeroFault+0x1ff[/COLOR] <-- 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> [COLOR=#008000]r @cr3[/COLOR]
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> [COLOR=#008000]!irql[/COLOR]
Debugger saved IRQL for processor 0x0 -- [COLOR=#ff0000]13[/COLOR]

The IRQL Level has been set to Clock Interrupt level, which is 13 on x64 systems.

Code: 
0: kd> [COLOR=#008000]!idt e1[/COLOR]

Dumping IDT: fffff80000b95080

b0b7eae9000000[COLOR=#0000cd]e1[/COLOR]:    fffff8000329b960 [COLOR=#ff0000]nt!KiIpiInterrupt[/COLOR]

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> [COLOR=#008000]!idt d1[/COLOR]

Dumping IDT: fffff80000b95080

b0b7eae9000000[COLOR=#0000cd]d1[/COLOR]:    fffff800038324f0 [COLOR=#ff0000]hal!HalpHpetClockInterrupt[/COLOR] (KINTERRUPT fffff80003832460)

Code: 
0: kd> [COLOR=#008000]!ipi[/COLOR]
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 [COLOR=#ff0000]Processor 2[/COLOR]

    As a receiver, unhandled requests are pending from processor(s) [COLOR=#ff0000]1, 5, 6[/COLOR].

    TargetCount          0  PacketBarrier        0  IpiFrozen     5 [Target Freeze]

    From processor 1, active request of type: [COLOR=#ff0000]flush all[/COLOR]
    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> [COLOR=#008000]!sysinfo machineid[/COLOR]
Machine ID Information [From Smbios 2.6, DMIVersion 38, Size=3718]
BiosMajorRelease = 4
BiosMinorRelease = 6
BiosVendor = American Megatrends Inc.
BiosVersion = 3701
BiosReleaseDate = [COLOR=#ff0000]11/30/2012[/COLOR]
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 = [COLOR=#ff0000]P8P67-M PRO[/COLOR]
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.
 
Evening guys ,

let me firstly say , you guys are awesome .. thank you for taking time out of your day to try and assist me in this 'issue' i am experiencing. So if i may ask , would i be right in saying that i should update my BIO's and then work from there?

Kind regards.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top