Analysieren eines WinDbg-Dumps nach einem BSOD - "Ein erwarteter Taktalarm wurde nicht empfangen"
4494
Scott Mitchell
Vor etwa sechs Monaten habe ich meine Computerhardware aufgerüstet - neues Mobo, CPU, RAM usw. Es läuft bis vor kurzem wie ein Champion. Als ich heute morgen zu meinem Computer ging, hatte es einen BSOD. Ich habe WinDbg verwendet, um den Minidump zu analysieren. Kann jemand helfen, diese Ergebnisse zu analysieren?
Hier sind die ersten Ergebnisse:
Use !analyze -v to get detailed debugging information. BugCheck 101, Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE ) Followup: MachineOwner
Als ich das lief, !analyze -vbekam ich 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
Meine Vermutung ist, dass es bei einem Prozessor auf meiner CPU (einem Intel Core i5-2400 Quad-Core) einige Probleme gab. Aber vielleicht ist dieser Fehler ein Symptom für ein anderes Problem.
Ich habe CLOCK_WATCHDOG_TIMEOUT (101) gegoogelt und es gab eine Reihe von Beiträgen in verschiedenen Hardware-Foren. Beim Lesen einiger von ihnen scheint es, dass das Problem nicht so sehr mit dem Prozessor zusammenhängt, sondern dass etwas anderes in der Stack-Ablaufverfolgung Schuld ist (normalerweise ein Treiber). Wenn dies der Fall ist, kann man davon ausgehen, dass dies KeUpdateSystemTimeder Täter ist? Ich bin nicht sicher, ob ich die Stapelverfolgung richtig lese oder wie ich sie weiter analysieren würde.
Die gute Nachricht ist, dass dies (bisher) nur einmal passiert ist und (noch) nicht wieder passiert ist! :-)
UPDATE: 2011-09-12
Ich habe den folgenden Befehl vom Minidump ausgeführt:
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 von der gleichen Stapelverfolgung wie oben angegeben.
1 Antwort auf die Frage
2
snoone
Grundsätzlich hat einer Ihrer Prozessoren festgestellt, dass einer Ihrer ANDEREN Prozessoren keine Taktunterbrechungen mehr erhalten hat. Derjenige, der den Zustand erkannt hat, meldet und gibt an, welcher Prozessor aufgehängt wurde:
fffff88002f65180, The PRCB address of the hung processor.
Die Frage lautet dann: "Was hat der gehängte Prozessor getan?" Sie können das mit dem folgenden Befehl beantworten:
Beachten Sie jedoch, dass es möglicherweise nicht funktioniert, da Sie nur einen Mini-Dump haben. Wenn dies nicht funktioniert, konfigurieren Sie Ihr System so, dass Kernel-Übersichts-Dumps erstellt werden, und warten Sie, bis der Absturz erneut auftritt.
Ich habe meinen Rechner so konfiguriert, dass er in der Zukunft einen vollständigen Kernel-Dump erstellt. Ich habe auch meine Frage mit den Ergebnissen des Befehls aktualisiert, den Sie notiert haben. Können Sie einen Blick darauf werfen und Feedback geben? Vielen Dank
Scott Mitchell vor 12 Jahren
0
Ich bin etwas zweifelhaft, dass der Befehl tatsächlich funktioniert hat. Beachten Sie alle Fehler. Ich vermute, dass der Mini-Dump nicht den Speicher des fehlerhaften PRCB enthält und das Ergebnis zeigt Ihnen nur den aktuellen Thread (anstelle des fehlerhaften Threads).
snoone vor 12 Jahren
1