5

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:

fffff88008c33328 fffff80002d268c9 : 0000000000000101 0000000000000031 0000000000000000 fffff88002f65180 : nt!KeBugCheckEx
fffff88008c33330 fffff80002cd9497 : fffff88000000000 fffff80000000002 0000000000002711 0000000000000000 : nt! ?? ::FNODOBFM::string'+0x4e2e fffff88008c333c0 fffff80002c13895 : fffff80002c39460 fffff88008c33570 fffff80002c39460 0000000000000000 : nt!KeUpdateSystemTime+0x377 fffff88008c334c0 fffff80002ccb173 : fffff80002e44e80 0000000000000001 0000000000000001 fffff80002c52000 : hal!HalpHpetClockInterrupt+0x8d fffff88008c334f0 fffff80002ca4661 : fffff80002e44e80 fffff80002e52cc0 0000000000000046 fffff80002cca6dc : nt!KiInterruptDispatchNoLock+0x163 fffff88008c33680 fffff80002fd8def : 0000000000000000 fffff88008c33b60 0000000000000000 fffff88000de20b9 : nt!KeFlushProcessWriteBuffers+0x65 fffff88008c336f0 fffff80002fd9449 : 00000000004d5d60 fffff80002fc54de 0000000000000000 fffffa80085c1b60 : nt!ExpQuerySystemInformation+0x13af fffff88008c33aa0 fffff80002ccded3 : 0000000000000000 fffff88008c33b60 fffffffffffe7960 000007fefcd30bd8 : nt!NtQuerySystemInformation+0x4d fffff88008c33ae0 0000000077c4167a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 0000000000fbefd8 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 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.

Community
  • 1
Scott Mitchell
  • 719

1 Answers1

2

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

slhck
  • 235,242
snoone
  • 121