Analisando um dump do WinDbg após um BSOD - “Uma interrupção esperada do relógio não foi recebida”

5

Cerca de seis meses atrás eu atualizei meu hardware de computador - novo mobo, CPU, RAM, etc. Ele é executado como um campeão até recentemente. Esta manhã, quando fui ao meu computador, tinha um BSOD. Eu usei o WinDbg para analisar o minidump. Alguém pode ajudar a analisar esses resultados?

Aqui estão os resultados iniciais:

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

Quando eu executei o !analyze -v , recebi a seguinte saída:

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

Minha presunção é que houve algum problema com um dos processadores no meu processador (um Intel Core i5-2400 Quad-Core). Mas talvez esse erro em particular seja um sintoma de algum outro problema.

Eu pesquisei CLOCK_WATCHDOG_TIMEOUT (101) no Google e havia várias postagens em vários fóruns relacionados a hardware. Lendo através de alguns deles, parece que o problema não está muito relacionado ao processador, mas sim que algo mais no rastreamento de pilha é a culpa (normalmente um driver). Se esse é o caso aqui, é seguro assumir que KeUpdateSystemTime é o culpado? Não tenho certeza se estou lendo o rastreamento de pilha corretamente, ou como vou analisá-lo ainda mais.

A boa notícia é que isso (até agora) aconteceu apenas uma vez e não (ainda) aconteceu de novo! : -)

ATUALIZAÇÃO: 2011-09-12

Eu corri o seguinte comando do minidump:

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

E recebeu o seguinte resultado.

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

Seguido pelo mesmo rastreio de pilha, conforme mencionado acima.

    
por Scott Mitchell 06.09.2011 / 21:04

1 resposta

2

Basicamente, um de seus processadores detectou que um dos seus outros processadores parou de receber interrupções de clock. O que detectou a condição, em seguida, verifica o bug e informa qual processador foi interrompido:

fffff88002f65180, The PRCB address of the hung processor.

A pergunta então é: "o que o processador estava fazendo?" Você pode responder usando o seguinte comando:

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

Note, no entanto, que pode não funcionar devido ao fato de que tudo que você tem é um mini-dump. Se isso não funcionar, configure seu sistema para criar dumps de resumo do kernel e espere que a falha aconteça novamente.

link

    
por 12.09.2011 / 17:22