☰

BSOD 후 WinDbg 덤프 분석 - "예상된 클럭 인터럽트가 수신되지 않았습니다."

tag-icon • tag-icon bsod minidumps windbg
BSOD 후 WinDbg 덤프 분석 - "예상된 클럭 인터럽트가 수신되지 않았습니다."

약 6개월 전에 저는 컴퓨터 하드웨어(새로운 mobo, CPU, RAM 등)를 업그레이드했습니다. 최근까지만 해도 이 하드웨어는 챔피언처럼 운영되었습니다. 오늘 아침에 컴퓨터에 갔는데 BSOD가 있었습니다. 미니덤프를 분석하기 위해 WinDbg를 사용했습니다. 누군가 이 결과를 분석하는 데 도움을 줄 수 있나요?

초기 결과는 다음과 같습니다.

Use !analyze -v to get detailed debugging information.
BugCheck 101, {31, 0, fffff88002f65180, 2}
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

내 추측으로는 내 CPU의 프로세서 중 하나(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

위에서 언급한 것과 동일한 스택 추적이 이어집니다.

답변1

기본적으로 프로세서 중 하나가 다른 프로세서 중 하나가 클럭 인터럽트 수신을 중지했음을 감지했습니다. 그런 다음 조건을 감지한 프로세서가 버그를 확인하고 어떤 프로세서가 중단되었는지 알려줍니다.

fffff88002f65180, The PRCB address of the hung processor.

그러면 "정지된 프로세서가 무엇을 하고 있었나요?"라는 질문이 생깁니다. 다음 명령을 사용하여 이에 답할 수 있습니다.

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

그러나 가지고 있는 것은 미니 덤프뿐이므로 작동하지 않을 수도 있습니다. 작동하지 않으면 커널 요약 덤프를 생성하고 충돌이 다시 발생할 때까지 기다리도록 시스템을 구성하십시오.

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

관련 정보