Analyzing a WinDbg dump after a BSOD - "An expected clock interrupt was not received"

Question

About six months ago I upgraded my computer hardware - new mobo, CPU, RAM, etc. It's run like a champ until just recently. This morning when I went to my computer it had a BSOD. I used WinDbg to analyze the minidump. Can someone help analyze these results?

Here are the initial results:

Use !analyze -v to get detailed debugging information.
BugCheck 101, {31, 0, fffff88002f65180, 2}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner

When I ran the !analyze -v I got the following output:

CLOCK_WATCHDOG_TIMEOUT (101)
An expected clock interrupt was not received on a secondary processor in an
MP system within the allocated interval. This indicates that the specified
processor is hung and not processing interrupts.
Arguments:
Arg1: 0000000000000031, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: fffff88002f65180, The PRCB address of the hung processor.
Arg4: 0000000000000002, 0.

Debugging Details:
------------------


BUGCHECK_STR:  CLOCK_WATCHDOG_TIMEOUT_4_PROC

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  svchost.exe

CURRENT_IRQL:  d

STACK_TEXT:  
fffff880`08c33328 fffff800`02d268c9 : 00000000`00000101 00000000`00000031 00000000`00000000 fffff880`02f65180 : nt!KeBugCheckEx
fffff880`08c33330 fffff800`02cd9497 : fffff880`00000000 fffff800`00000002 00000000`00002711 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x4e2e
fffff880`08c333c0 fffff800`02c13895 : fffff800`02c39460 fffff880`08c33570 fffff800`02c39460 00000000`00000000 : nt!KeUpdateSystemTime+0x377
fffff880`08c334c0 fffff800`02ccb173 : fffff800`02e44e80 00000000`00000001 00000000`00000001 fffff800`02c52000 : hal!HalpHpetClockInterrupt+0x8d
fffff880`08c334f0 fffff800`02ca4661 : fffff800`02e44e80 fffff800`02e52cc0 00000000`00000046 fffff800`02cca6dc : nt!KiInterruptDispatchNoLock+0x163
fffff880`08c33680 fffff800`02fd8def : 00000000`00000000 fffff880`08c33b60 00000000`00000000 fffff880`00de20b9 : nt!KeFlushProcessWriteBuffers+0x65
fffff880`08c336f0 fffff800`02fd9449 : 00000000`004d5d60 fffff800`02fc54de 00000000`00000000 fffffa80`085c1b60 : nt!ExpQuerySystemInformation+0x13af
fffff880`08c33aa0 fffff800`02ccded3 : 00000000`00000000 fffff880`08c33b60 ffffffff`fffe7960 000007fe`fcd30bd8 : nt!NtQuerySystemInformation+0x4d
fffff880`08c33ae0 00000000`77c4167a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`00fbefd8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77c4167a


STACK_COMMAND:  kb

SYMBOL_NAME:  ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME:  Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  X64_CLOCK_WATCHDOG_TIMEOUT_4_PROC_ANALYSIS_INCONCLUSIVE

BUCKET_ID:  X64_CLOCK_WATCHDOG_TIMEOUT_4_PROC_ANALYSIS_INCONCLUSIVE

Followup: MachineOwner

My presumption is that there was some hiccup with one of the processors on my CPU (an Intel Core i5-2400 Quad-Core). But maybe this particular error is a symptom of some other problem.

I Googled CLOCK_WATCHDOG_TIMEOUT (101) and there were a number of posts in various hardware-related forums. Reading through some of them it appears that the problem isn't so much related to the processor but rather that something else in the stack trace is to blame (typically a driver). If that's the case here, is it safe to assume that KeUpdateSystemTime is the culprit? I'm not sure if I'm reading the stack trace correctly, or how I'd go about analyzing it further.

The good news is that this has (so far) only happened once and has not (yet) happened again! :-)

UPDATE: 2011-09-12

I ran the following command from the minidump:

!thread @@c++((nt!_kprcb *)0xfffff88002f65180)->CurrentThread)

And received the following output.

GetPointerFromAddress: unable to read from fffff80002f01000
THREAD fffffa800952db60  Cid 0074.0110  Teb: 000007fffffd5000 Win32Thread: 0000000000000000 RUNNING on processor 0
Impersonation token:  fffff8a001fc0060 (Level Delegation)
GetUlongFromAddress: unable to read from fffff80002e40ba4
Owning Process            fffffa8009527060       Image:         svchost.exe
Attached Process          N/A            Image:         N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount      14245338     
Context Switch Count      6898658             
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address 0x000007feff54a808
Stack Init fffff88008c33c70 Current fffff88008c33830
Base fffff88008c34000 Limit fffff88008c2e000 Call 0
Priority 27 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5

Followed by the same stack trace as noted above.

Answer 1

Basically, one of your processors has detected that one of your OTHER processors has stopped receiving clock interrupts. The one that detected the condition then bugchecks and tells you which processor was hung:

fffff88002f65180, The PRCB address of the hung processor.

The question then becomes, "what was the hung processor doing?" You can answer that by using the following command:

!thread @@c++((nt!_kprcb *)0xfffff88002f65180)->CurrentThread)

Note, however, that it might not work due to the fact that all you have is a mini-dump. If it doesn't work, configure your system to create kernel summary dumps and wait for the crash to happen again.

http://support.microsoft.com/kb/254649