Анализ дампа WinDbg после BSOD - «Ожидаемое прерывание синхронизации не получено»

4372
Scott Mitchell

Около полугода назад я обновил свое компьютерное оборудование - новое mobo, CPU, RAM и т. Д. До недавнего времени он работал как первоклассный. Этим утром, когда я пошел к своему компьютеру, у него был BSOD. Я использовал WinDbg для анализа минидампа. Может ли кто-нибудь помочь проанализировать эти результаты?

Вот первые результаты:

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

Когда я запустил, !analyze -vя получил следующий вывод:

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

Я предполагаю, что произошел сбой в работе одного из процессоров на моем процессоре (четырехъядерный процессор Intel Core i5-2400). Но, возможно, именно эта ошибка является признаком какой-то другой проблемы.

Я гуглил CLOCK_WATCHDOG_TIMEOUT (101), и на различных форумах, связанных с оборудованием, было много постов. Читая некоторые из них, кажется, что проблема связана не столько с процессором, сколько с чем-то другим в трассировке стека (обычно с драйвером). Если это так, то можно ли предположить, что KeUpdateSystemTimeэто виновник? Я не уверен, правильно ли я читаю трассировку стека, или как я буду анализировать ее дальше.

Хорошая новость заключается в том, что это (пока) произошло только один раз и еще не произошло! :-)

ОБНОВЛЕНИЕ: 2011-09-12

Я запустил следующую команду из минидампа:

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

И получил следующий вывод.

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

Затем следует та же трассировка стека, что и выше.

5

1 ответ на вопрос

2
snoone

По сути, один из ваших процессоров обнаружил, что один из ваших ДРУГИХ процессоров перестал получать прерывания тактового генератора. Тот, который обнаружил условие, затем проверяет ошибки и сообщает вам, какой процессор завис:

fffff88002f65180, The PRCB address of the hung processor.

Тогда возникает вопрос: «Что делал зависший процессор?» Вы можете ответить на это с помощью следующей команды:

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

Однако обратите внимание, что он может не работать из-за того, что у вас есть только мини-дамп. Если это не сработает, настройте вашу систему на создание сводных дампов ядра и дождитесь повторения сбоя.

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

Я настроил свою машину для выполнения полного дампа ядра в будущем. Я также обновил свой вопрос результатами команды, которую вы отметили. Можете ли вы взглянуть и оставить отзыв? Спасибо Scott Mitchell 12 лет назад 0
Я немного сомневаюсь, что команда действительно сработала, обратите внимание на все ошибки. Я подозреваю, что мини-дамп не содержит памяти неисправного PRCB и в результате просто показывает текущий поток (а не ошибочный поток). snoone 12 лет назад 1

Похожие вопросы