Vor etwa sechs Monaten habe ich die Hardware meines Computers aufgerüstet – neues Motherboard, CPU, RAM usw. Bis vor Kurzem lief er einwandfrei. Als ich heute Morgen an meinen Computer ging, hatte er einen BSOD. Ich habe WinDbg verwendet, um den Minidump zu analysieren. Kann jemand bei der Analyse dieser Ergebnisse helfen?
Hier sind die ersten Ergebnisse:
Use !analyze -v to get detailed debugging information.
BugCheck 101, {31, 0, fffff88002f65180, 2}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
Als ich es ausführte, !analyze -verhielt ich die folgende Ausgabe:
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
Ich gehe davon aus, dass es bei einem der Prozessoren meiner CPU (einem Intel Core i5-2400 Quad-Core) zu Problemen gekommen ist. Aber vielleicht ist dieser spezielle Fehler auch ein Symptom für ein anderes Problem.
Ich habe gegoogeltCLOCK_WATCHDOG_TIMEOUT (101)und es gab eine Reihe von Beiträgen in verschiedenen Hardware-bezogenen Foren. Beim Durchlesen einiger davon scheint es, dass das Problem nicht so sehr mit dem Prozessor zusammenhängt, sondern dass etwas anderes im Stacktrace schuld ist (normalerweise ein Treiber). Wenn das hier der Fall ist, kann man dann davon ausgehen, dass das KeUpdateSystemTimeder Übeltäter ist? Ich bin mir nicht sicher, ob ich den Stacktrace richtig lese oder wie ich ihn weiter analysieren soll.
Die gute Nachricht ist, dass dies (bisher) nur einmal passiert ist und (noch) nicht wieder vorgekommen ist! :-)
AKTUALISIERUNG: 12.09.2011
Ich habe den folgenden Befehl vom Minidump ausgeführt:
!thread @@c++((nt!_kprcb *)0xfffff88002f65180)->CurrentThread)
Und habe die folgende Ausgabe erhalten.
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
Gefolgt vom gleichen Stacktrace wie oben angegeben.
Antwort1
Im Grunde hat einer Ihrer Prozessoren festgestellt, dass einer Ihrer ANDEREN Prozessoren keine Taktunterbrechungen mehr empfängt. Der Prozessor, der den Zustand festgestellt hat, führt dann eine Fehlerüberprüfung durch und teilt Ihnen mit, welcher Prozessor hängen geblieben ist:
fffff88002f65180, The PRCB address of the hung processor.
Die Frage ist dann: „Was hat der hängengebliebene Prozessor gemacht?“ Sie können diese Frage mit dem folgenden Befehl beantworten:
!thread @@c++((nt!_kprcb *)0xfffff88002f65180)->CurrentThread)
Beachten Sie jedoch, dass es möglicherweise nicht funktioniert, da Sie nur einen Mini-Dump haben. Wenn es nicht funktioniert, konfigurieren Sie Ihr System so, dass Kernel-Zusammenfassungsdumps erstellt werden, und warten Sie, bis der Absturz erneut auftritt.