Hace unos seis meses actualicé el hardware de mi computadora: nuevo mobo, CPU, RAM, etc. Ha funcionado como un campeón hasta hace poco. Esta mañana, cuando fui a mi computadora, tenía un BSOD. Usé WinDbg para analizar el minivolcado. ¿Alguien puede ayudar a analizar estos resultados?
Aquí están los resultados iniciales:
Use !analyze -v to get detailed debugging information.
BugCheck 101, {31, 0, fffff88002f65180, 2}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
Cuando ejecuté !analyze -vobtuve el siguiente resultado:
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
Supongo que hubo algún problema con uno de los procesadores de mi CPU (un Intel Core i5-2400 Quad-Core). Pero tal vez este error en particular sea un síntoma de algún otro problema.
Busqué en GoogleCLOCK_WATCHDOG_TIMEOUT (101)y hubo varias publicaciones en varios foros relacionados con el hardware. Al leer algunos de ellos, parece que el problema no está tanto relacionado con el procesador sino más bien con algo más en el seguimiento de la pila (normalmente un controlador). Si ese es el caso aquí, ¿es seguro asumir que ese KeUpdateSystemTimees el culpable? No estoy seguro de estar leyendo el seguimiento de la pila correctamente o de cómo analizarlo más a fondo.
¡La buena noticia es que esto (hasta ahora) solo ha sucedido una vez y (todavía) no ha vuelto a suceder! :-)
ACTUALIZACIÓN: 2011-09-12
Ejecuté el siguiente comando desde el minivolcado:
!thread @@c++((nt!_kprcb *)0xfffff88002f65180)->CurrentThread)
Y recibió el siguiente 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 del mismo seguimiento de pila como se indicó anteriormente.
Respuesta1
Básicamente, uno de sus procesadores ha detectado que uno de sus OTROS procesadores ha dejado de recibir interrupciones de reloj. El que detectó la condición luego verifica los errores y le indica qué procesador se colgó:
fffff88002f65180, The PRCB address of the hung processor.
La pregunta entonces es: "¿qué estaba haciendo el procesador colgado?" Puedes responder eso usando el siguiente comando:
!thread @@c++((nt!_kprcb *)0xfffff88002f65180)->CurrentThread)
Sin embargo, tenga en cuenta que es posible que no funcione debido a que todo lo que tiene es un minivolcado. Si no funciona, configure su sistema para crear volcados de resumen del kernel y espere a que vuelva a ocurrir el fallo.