Re: BSOD Clock interrupt was not receieved on a secondary processor - Windows 7 x86
Hi, thanks for the kernel dump as it is necessary for this bug check!
CLOCK_WATCHDOG_TIMEOUT (101)
This indicates that an expected clock interrupt on a secondary processor, in a multi-processor system, was not received within the allocated interval.
BugCheck 101, {
60, 0,
807c2120, 1}
^^ 60 clock ticks in regards to the timeout.
807c2120 is the PRCB address of the hung processor, let's keep this address in mind.
This is an x86 processor based on the parameters.
Code:
0: kd> !prcb 1
PRCB for Processor 1 at [COLOR=#4b0082]807c2120[/COLOR]:
Current IRQL -- 0
Threads-- Current 807c7800 Next 00000000 Idle 807c7800
Processor Index 1 Number (0, 1) GroupSetMember 2
Interrupt Count -- 0023733b
Times -- Dpc 00000a87 Interrupt 000007a0
Kernel 0004cae8 User 0000ec3b
As this matches the 3rd parameter of the bug check, processor #1 is the responsible processor. Now with the information we have here thus far, we know that processor #1 reached 60 clock ticks without responding, therefore the system crashed. Before we go further, what is a clock tick? A clock interrupt is a form of interrupt which involves counting the the cycles of the processor core, which is running a clock on the processors to keep them all in sync. A clock interrupt is handed out to all processors and then they must report in, and when one doesn't report in, you then crash.
Let's now look at the stacks of the different processors to see what the threads were involved in:
Code:
0: kd> kv
ChildEBP RetAddr Args to Child
e3babc4c 82c89117 00000101 00000060 00000000 nt!KeBugCheckEx+0x1e
e3babc88 82c88763 0002625a 00000000 0005b901 nt!KeAccumulateTicks+0x242
e3babcc8 82c88610 6ebac8c5 57762f1f 00000000 nt!KeUpdateRunTime+0x145
e3babd20 82c87e13 00000000 00000000 000000d1 nt!KeUpdateSystemTime+0x613
e3babd20 6ebac8c5 00000000 00000000 000000d1 nt!KeUpdateSystemTimeAssist+0x13 (FPO: [0,2] TrapFrame @ e3babd34)
WARNING: Frame IP not in any known module. Following frames may be wrong.
0301fdb8 00000000 00000000 00000000 00000000 0x6ebac8c5
At this time of the bug check, the first and primary CPU core is attempting to update the system time, but is struggling to sync with the other processors, so it calls a bug check.
Code:
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 28 (CLOCK2_LEVEL)
At the time of the crash we were at IRQL 28 which is the Clock timer for x86 hardware.
Code:
0: kd> !idt
Dumping IDT: 80b95400
37: 8303b104 hal!PicSpuriousService37
52: 85554058 ataport!IdePortInterrupt (KINTERRUPT 85554000)
53: 85e6f058 ndis!ndisMiniportIsr (KINTERRUPT 85e6f000)
61: 855542d8 serial!SerialCIsrSw (KINTERRUPT 85554280)
62: 855547d8 ataport!IdePortInterrupt (KINTERRUPT 85554780)
ataport!IdePortInterrupt (KINTERRUPT 85554500)
USBPORT!USBPORT_InterruptService (KINTERRUPT 85e6f500)
63: 87004cd8 dxgkrnl!DpiFdoLineInterruptRoutine (KINTERRUPT 87004c80)
72: 85e6fa58 ataport!IdePortInterrupt (KINTERRUPT 85e6fa00)
ataport!IdePortInterrupt (KINTERRUPT 85554a00)
73: 85e6fcd8 ataport!IdePortInterrupt (KINTERRUPT 85e6fc80)
a4: 85e6f7d8 USBPORT!USBPORT_InterruptService (KINTERRUPT 85e6f780)
b1: 85554cd8 ACPI!ACPIInterruptServiceRoutine (KINTERRUPT 85554c80)
b4: 85e6f2d8 Wdf01000!FxInterrupt::_InterruptThunk (KINTERRUPT 85e6f280)
c1: 8303b3f4 hal!HalpBroadcastCallService
d1: 83023fb4 hal!HalpRtcClockInterrupt
df: 8303b1dc hal!HalpApicRebootService
e1: 8303b958 hal!HalpIpiHandler
e3: 8303b6f8 hal!HalpLocalApicErrorService
fd: 8303bf2c hal!HalpProfileInterrupt
fe: 8303c1a8 hal!HalpPerfInterrupt
Dumping the interrupt descriptor table shows a few interesting things, such as the Direct X Kernel, USBPORT, NDIS (network), etc.
Code:
0: kd> .trap e3babd34
ErrCode = 00000000
eax=00000104 ebx=041bdf18 ecx=041be270 edx=05980040 esi=041be270 edi=041c6680
eip=6ebac8c5 esp=0301fc80 ebp=0301fdb8 iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206
001b:6ebac8c5 ?? ???
0: kd> u @eip
6ebac8c5 ?? ???
^ Memory access error in 'u @eip'
No luck regarding dissassembly of the trapframe.
Code:
1: kd> kv
# ChildEBP RetAddr Args to Child
00 807dec98 82c8d7ee 85b5f030 807c7800 807c2000 [COLOR=#4b0082]amdk8!C1Halt+0x4[/COLOR] (FPO: [0,0,0])
01 807ded20 82c852cd 00000000 0000000e 00000000 [COLOR=#ff0000]nt!PoIdle+0x524[/COLOR]
02 807ded24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0xd (FPO: [0,0,0])
What's happening here in this stack is your C1 state kicks in by halting the processor during its idle state. All x86 processors (32-bit) have an instruction known as HLT which is is 'Halt' in what we see in the stack here -
amdk8!C1Halt. This does exactly what the word 'halt' would describe, which is to idle the CPU and halt it from doing anything until it receives an interrupt. An interrupt is a signal sent by the hardware to the CPU that basically says "Hey, I need this done
right now, so stop what you're doing and take care of it".
Why is this done? Well, in simplest terms, to limit power cunsumption. It's a power management feature.
So, core 0 was waiting on core 1 to respond to handle interrupts, but it was too busy catching some nice needed rest.
Very likely a faulty CPU when this is the case, but there are a few things I want to take out of the picture first software-wise:
1. Please uninstall
all Asus bloatware (PC Probe, etc). They are very known to cause problems given they are OS > BIOS utilities.
2.
Code:
1: kd> lmvm aspi32
Browse full module list
start end module name
939d3000 939d51a0 ASPI32 (deferred)
Image path: \SystemRoot\System32\Drivers\ASPI32.SYS
Image name: ASPI32.SYS
Browse all global symbols functions data
Timestamp: Fri Jul 12 19:31:08 [COLOR=#ff0000]1996[/COLOR]
Adaptec ASPI Driver(most likely associated with an older CD/DVD burning program) dated from
1996! Needs to be removed ASAP! Uneblievably way too old to function with the OS.
3. Uninstall B's Recorder GOLD by B.H.A. Corporation (possibly related to the above, or not) ASAP!
Regards,
Patrick
