张枕书 编写：
I got a dump file from colleague, its stop code is 0x101(CLOCK_WATCHDOG_TIMEOUT). I go through the CPUs context and found CPU0 looks corrupted because its context is fully empty which surprised me very much. Below is !analyze -v information:
Bugcheck Analysis
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: 00000030, Clock interrupt time out interval in nominal clock ticks.
Arg2: 00000000, 0.
Arg3: 82283120, The PRCB address of the hung processor.
Arg4: 00000000, 0.
3: kd> k
# ChildEBP RetAddr
00 8957a4e4 821c35df nt!KeBugCheckEx
01 8957a550 8212dbea nt! ?? ::FNODOBFM::`string’+0x309bd
02 8957a600 820211be nt!KeClockInterruptNotify+0x28a
03 8957a610 82030b93 hal!HalpTimerClockInterruptCommon+0x3e
04 8957a610 82179713 hal!HalpTimerClockInterrupt+0x1cb
05 8957a720 820b2bf8 nt!KiIpiSendPacket+0xdf
06 8957a778 8209e73a nt!MiFlushTbList+0x1ca
07 8957a858 82100912 nt!MmSetAddressRangeModified+0xa8
08 8957a900 8209b8ac nt!CcFlushCachePriv+0x3d0
09 8957a914 858c0f49 nt!CcFlushCache+0x18
0a 8957a968 858c125c Ntfs!NtfsFlushUserStream+0x67
0b 8957aa10 85889bff Ntfs!NtfsCommonFlushBuffers+0x1b6
0c 8957aa44 820e70bb Ntfs!NtfsCommonFlushBuffersCallout+0x1d
0d 8957aad4 820e6d23 nt!KeExpandKernelStackAndCalloutInternal+0x37b
0e 8957aaec 8588b9b3 nt!KeExpandKernelStackAndCalloutEx+0x1f
0f 8957ab28 8588b946 Ntfs!NtfsCommonFlushBuffersOnNewStack+0x3c
10 8957ab88 821ed2b0 Ntfs!NtfsFsdFlushBuffers+0x80
11 8957abac 820d7a52 nt!IopPerfCallDriver+0x119
12 8957abc0 855afe01 nt!IofCallDriver+0x62
13 8957abfc 855afb60 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x22c
14 8957ac28 821ed2b0 fltmgr!FltpDispatch+0xb1
15 8957ac48 820d7a52 nt!IopPerfCallDriver+0x119
16 8957ac5c 822eb66e nt!IofCallDriver+0x62
17 8957acb8 823a3cc7 nt!IopSynchronousServiceTail+0x16e
18 8957ad28 823a3b47 nt!NtFlushBuffersFileEx+0x177
19 8957ad44 8218a377 nt!NtFlushBuffersFile+0x15
1a 8957ad44 771a2da4 nt!KiSystemServicePostCall
1b 00bef7d8 771a1cae ntdll!KiFastSystemCallRet
1c 00bef7dc 74e169a7 ntdll!NtFlushBuffersFile+0xa
1d 00bef7f4 72225331 KERNELBASE!FlushFileBuffers+0x24
1e 00bef884 721f1c81 wevtsvc!File::WriteCurrentChunk+0x18d
1f 00bef8b4 771708f5 wevtsvc!File::FlushTimerCallback+0x45
20 00bef8d4 7716a038 ntdll!TppTimerpExecuteCallback+0x5c
21 00befad0 750c17ad ntdll!TppWorkerThread+0x368
22 00befadc 77183af4 KERNEL32!BaseThreadInitThunk+0xe
23 00befb20 77183acd ntdll!__RtlUserThreadStart+0x20
24 00befb30 00000000 ntdll!_RtlUserThreadStart+0x1b
0: kd> vertarget
Windows 8 Kernel Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17085.x86fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0x82072000 PsLoadedModuleList = 0x82271438
Debug session time: Tue Jul 15 21:42:06.937 2014 (UTC + 8:00)
System Uptime: 0 days 0:03:17.359
-------------
Below is the CPU0’s context information.
0: kd> !prcb 0
PRCB for Processor 0 at 82283120:
Current IRQL – 0
Threads-- Current 82292100 Next 9272e040 Idle 82292100
Processor Index 0 Number (0, 0) GroupSetMember 1
Interrupt Count – 00019f68
Times – Dpc 00000037 Interrupt 0000001f
Kernel 00002ee8 User 000000b6
0: kd> !thread 82292100
THREAD 82292100 Cid 0000.0000 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0
Not impersonating
DeviceMap 82e0a7a8
Owning Process 82292540 Image: Idle
Attached Process 8459e040 Image: System
Wait Start TickCount 12190 Ticks: 440 (0:00:00:06.875)
Context Switch Count 32498 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:02:57.578
Win32 Start Address nt!KiIdleLoop (0x8218eaa8)
Stack Init 833a0de0 Current 833a0d40 Base 833a1000 Limit 8339e000 Call 0
Priority 0 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 5
ChildEBP RetAddr Args to Child
00000000 00000000 00000000 00000000 00000000 0x0
3: kd> ~0s
0: kd> r
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000
eip=00000000 esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na po nc
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000 efl=00000000
00000000 ?? ???
0: kd> k
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 00000000 00000000 0x0
0: kd> !pcr 0
KPCR for Processor 0 at 82283000:
Major 1 Minor 1
NtTib.ExceptionList: 82276fa0
NtTib.StackBase: 00000000
NtTib.StackLimit: 00001f80
NtTib.SubSystemTib: 81241000
NtTib.Version: 00019e54
NtTib.UserPointer: 00000001
NtTib.SelfTib: 00000000
SelfPcr: 82283000
Prcb: 82283120
Irql: 0000001f
IRR: 00000000
IDR: 00000000
InterruptMode: 00000000
IDT: 8124e400
GDT: 8124e000
TSS: 81241000
CurrentThread: 82292100
NextThread: 9272e040
IdleThread: 82292100
DpcQueue: Unable to read nt!_KDPC_DATA.DpcListHead.Flink @ 82285300
0: kd> dt nt!_ktss 81241000
+0x000 Backlink : 0
+0x002 Reserved0 : 0
+0x004 Esp0 : 0x833a0dd0
+0x008 Ss0 : 0x10
+0x00a Reserved1 : 0
+0x00c NotUsed1 : [4] 0
+0x01c CR3 : 0
+0x020 Eip : 0
+0x024 EFlags : 0
+0x028 Eax : 0
+0x02c Ecx : 0
+0x030 Edx : 0
+0x034 Ebx : 0
+0x038 Esp : 0
+0x03c Ebp : 0
+0x040 Esi : 0
+0x044 Edi : 0
+0x048 Es : 0
+0x04a Reserved2 : 0
+0x04c Cs : 0
+0x04e Reserved3 : 0
+0x050 Ss : 0
+0x052 Reserved4 : 0
+0x054 Ds : 0
+0x056 Reserved5 : 0
+0x058 Fs : 0
+0x05a Reserved6 : 0
+0x05c Gs : 0
+0x05e Reserved7 : 0
+0x060 LDT : 0
+0x062 Reserved8 : 0
+0x064 Flags : 0
+0x066 IoMapBase : 0x20ac
+0x068 IoMaps : [1] _KiIoAccessMap
+0x208c IntDirectionMap : [32] “…”
The other thing I noticed is the IRQL level in TSS which is 0x1f. It’s a x86 Win81 OS so 0x1f the highest IRQL level. I search for HIGH_LEVEL and got below explanation:
HIGH_LEVEL: Machine checks and catastrophic errors; profiling timer for Windows XP and later releases
I doubt CPU0 is corrupted and failed to process its clock interrupt and CPU3 checked the timeout and triggered 0x101 BSOD. there should be MCE happens which runs in HIGH_LEVEL IRQL. But it confused me because I can’t find the MCE call stack.
Anyone have some suggestion? What else information can I got from the dump file?
Very strange. Out of curiosity, what does !thread 9272e040 show? That’s the
thread that would have run next on the CPU0, likely unrelated but it’s worth
looking at.
Also, is the entire kernel stack of CPU0 zeroed (dps 8339e000 833a1000)?
In terms of IRQL HIGH_LEVEL, don’t forget that it’s also possible to raise
IRQL in software with KeRaiseIrql. Therefore it’s possible that you’re at
this IRQL due to normal software processing as opposed to due to one of
those hardware events.
-scott
OSR
@OSRDrivers
“zhang pei” wrote in message news:xxxxx@windbg…
å¼ æž•ä¹¦ 编写：
I got a dump file from colleague, its stop code is
0x101(CLOCK_WATCHDOG_TIMEOUT). I go through the CPUs context and found CPU0
looks corrupted because its context is fully empty which surprised me very
much. Below is !analyze -v information:
Bugcheck Analysis
******
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: 00000030, Clock interrupt time out interval in nominal clock ticks.
Arg2: 00000000, 0.
Arg3: 82283120, The PRCB address of the hung processor.
Arg4: 00000000, 0.
3: kd> k
# ChildEBP RetAddr
00 8957a4e4 821c35df nt!KeBugCheckEx
01 8957a550 8212dbea nt! ?? ::FNODOBFM::`string’+0x309bd
02 8957a600 820211be nt!KeClockInterruptNotify+0x28a
03 8957a610 82030b93 hal!HalpTimerClockInterruptCommon+0x3e
04 8957a610 82179713 hal!HalpTimerClockInterrupt+0x1cb
05 8957a720 820b2bf8 nt!KiIpiSendPacket+0xdf
06 8957a778 8209e73a nt!MiFlushTbList+0x1ca
07 8957a858 82100912 nt!MmSetAddressRangeModified+0xa8
08 8957a900 8209b8ac nt!CcFlushCachePriv+0x3d0
09 8957a914 858c0f49 nt!CcFlushCache+0x18
0a 8957a968 858c125c Ntfs!NtfsFlushUserStream+0x67
0b 8957aa10 85889bff Ntfs!NtfsCommonFlushBuffers+0x1b6
0c 8957aa44 820e70bb Ntfs!NtfsCommonFlushBuffersCallout+0x1d
0d 8957aad4 820e6d23 nt!KeExpandKernelStackAndCalloutInternal+0x37b
0e 8957aaec 8588b9b3 nt!KeExpandKernelStackAndCalloutEx+0x1f
0f 8957ab28 8588b946 Ntfs!NtfsCommonFlushBuffersOnNewStack+0x3c
10 8957ab88 821ed2b0 Ntfs!NtfsFsdFlushBuffers+0x80
11 8957abac 820d7a52 nt!IopPerfCallDriver+0x119
12 8957abc0 855afe01 nt!IofCallDriver+0x62
13 8957abfc 855afb60
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x22c
14 8957ac28 821ed2b0 fltmgr!FltpDispatch+0xb1
15 8957ac48 820d7a52 nt!IopPerfCallDriver+0x119
16 8957ac5c 822eb66e nt!IofCallDriver+0x62
17 8957acb8 823a3cc7 nt!IopSynchronousServiceTail+0x16e
18 8957ad28 823a3b47 nt!NtFlushBuffersFileEx+0x177
19 8957ad44 8218a377 nt!NtFlushBuffersFile+0x15
1a 8957ad44 771a2da4 nt!KiSystemServicePostCall
1b 00bef7d8 771a1cae ntdll!KiFastSystemCallRet
1c 00bef7dc 74e169a7 ntdll!NtFlushBuffersFile+0xa
1d 00bef7f4 72225331 KERNELBASE!FlushFileBuffers+0x24
1e 00bef884 721f1c81 wevtsvc!File::WriteCurrentChunk+0x18d
1f 00bef8b4 771708f5 wevtsvc!File::FlushTimerCallback+0x45
20 00bef8d4 7716a038 ntdll!TppTimerpExecuteCallback+0x5c
21 00befad0 750c17ad ntdll!TppWorkerThread+0x368
22 00befadc 77183af4 KERNEL32!BaseThreadInitThunk+0xe
23 00befb20 77183acd ntdll!__RtlUserThreadStart+0x20
24 00befb30 00000000 ntdll!_RtlUserThreadStart+0x1b
0: kd> vertarget
Windows 8 Kernel Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal
Built by: 9600.17085.x86fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0x82072000 PsLoadedModuleList = 0x82271438
Debug session time: Tue Jul 15 21:42:06.937 2014 (UTC + 8:00)
System Uptime: 0 days 0:03:17.359
-------------
Below is the CPU0’s context information.
0: kd> !prcb 0
PRCB for Processor 0 at 82283120:
Current IRQL – 0
Threads-- Current 82292100 Next 9272e040 Idle 82292100
Processor Index 0 Number (0, 0) GroupSetMember 1
Interrupt Count – 00019f68
Times – Dpc 00000037 Interrupt 0000001f
Kernel 00002ee8 User 000000b6
0: kd> !thread 82292100
THREAD 82292100 Cid 0000.0000 Teb: 00000000 Win32Thread: 00000000 RUNNING
on processor 0
Not impersonating
DeviceMap 82e0a7a8
Owning Process 82292540 Image: Idle
Attached Process 8459e040 Image: System
Wait Start TickCount 12190 Ticks: 440 (0:00:00:06.875)
Context Switch Count 32498 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:02:57.578
Win32 Start Address nt!KiIdleLoop (0x8218eaa8)
Stack Init 833a0de0 Current 833a0d40 Base 833a1000 Limit 8339e000 Call 0
Priority 0 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0
PagePriority 5
ChildEBP RetAddr Args to Child
00000000 00000000 00000000 00000000 00000000 0x0
3: kd> ~0s
0: kd> r
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000000
eip=00000000 esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na po
nc
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000
efl=00000000
00000000 ?? ???
0: kd> k
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 00000000 00000000 0x0
0: kd> !pcr 0
KPCR for Processor 0 at 82283000:
Major 1 Minor 1
NtTib.ExceptionList: 82276fa0
NtTib.StackBase: 00000000
NtTib.StackLimit: 00001f80
NtTib.SubSystemTib: 81241000
NtTib.Version: 00019e54
NtTib.UserPointer: 00000001
NtTib.SelfTib: 00000000
SelfPcr: 82283000
Prcb: 82283120
Irql: 0000001f
IRR: 00000000
IDR: 00000000
InterruptMode: 00000000
IDT: 8124e400
GDT: 8124e000
TSS: 81241000
CurrentThread: 82292100
NextThread: 9272e040
IdleThread: 82292100
DpcQueue: Unable to read nt!_KDPC_DATA.DpcListHead.Flink @ 82285300
0: kd> dt nt!_ktss 81241000
+0x000 Backlink : 0
+0x002 Reserved0 : 0
+0x004 Esp0 : 0x833a0dd0
+0x008 Ss0 : 0x10
+0x00a Reserved1 : 0
+0x00c NotUsed1 : [4] 0
+0x01c CR3 : 0
+0x020 Eip : 0
+0x024 EFlags : 0
+0x028 Eax : 0
+0x02c Ecx : 0
+0x030 Edx : 0
+0x034 Ebx : 0
+0x038 Esp : 0
+0x03c Ebp : 0
+0x040 Esi : 0
+0x044 Edi : 0
+0x048 Es : 0
+0x04a Reserved2 : 0
+0x04c Cs : 0
+0x04e Reserved3 : 0
+0x050 Ss : 0
+0x052 Reserved4 : 0
+0x054 Ds : 0
+0x056 Reserved5 : 0
+0x058 Fs : 0
+0x05a Reserved6 : 0
+0x05c Gs : 0
+0x05e Reserved7 : 0
+0x060 LDT : 0
+0x062 Reserved8 : 0
+0x064 Flags : 0
+0x066 IoMapBase : 0x20ac
+0x068 IoMaps : [1] _KiIoAccessMap
+0x208c IntDirectionMap : [32] “…”
The other thing I noticed is the IRQL level in TSS which is 0x1f. It’s a x86
Win81 OS so 0x1f the highest IRQL level. I search for HIGH_LEVEL and got
below explanation:
HIGH_LEVEL: Machine checks and catastrophic errors; profiling timer for
Windows XP and later releases
I doubt CPU0 is corrupted and failed to process its clock interrupt and CPU3
checked the timeout and triggered 0x101 BSOD. there should be MCE happens
which runs in HIGH_LEVEL IRQL. But it confused me because I can’t find the
MCE call stack.
Anyone have some suggestion? What else information can I got from the dump
file?
This is exactly what you would typically expect to see for a clock watchdog timeout bugcheck.
The bugcheck means that one of the processors is wedged and, if it is wedged, the bugcheck code may not be able to get ahold of that CPU to tell it to save its register context where the debugger can find it. As a result, it is common for that processor to have a stale register context (typically zeroed) when examined in the debugger.
!thread on the active thread on the PRCB might or might not be instructive, the same as manually groveling the DPC/ISR stacks. Usually one of these will have some indication of activity, but you’ll have to manually piece together which one makes sense. Since the processor in question couldn’t be corralled into cleanly bugchecking, you will have to try and manually extract whatever clues might be available as to what the processor was doing when it was stuck.
- S (Msft)
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Tuesday, July 22, 2014 9:00 AM
To: Kernel Debugging Interest List
Subject: Re:[windbg] CPU corruption causes clock_watchdog_timeout
Very strange. Out of curiosity, what does !thread 9272e040 show? That’s the thread that would have run next on the CPU0, likely unrelated but it’s worth looking at.
Also, is the entire kernel stack of CPU0 zeroed (dps 8339e000 833a1000)?
In terms of IRQL HIGH_LEVEL, don’t forget that it’s also possible to raise IRQL in software with KeRaiseIrql. Therefore it’s possible that you’re at this IRQL due to normal software processing as opposed to due to one of those hardware events.
-scott
OSR
@OSRDrivers
“zhang pei” wrote in message news:xxxxx@windbg…
??? ???
I got a dump file from colleague, its stop code is 0x101(CLOCK_WATCHDOG_TIMEOUT). I go through the CPUs context and found CPU0 looks corrupted because its context is fully empty which surprised me very much. Below is !analyze -v information:
Bugcheck Analysis
******
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: 00000030, Clock interrupt time out interval in nominal clock ticks.
Arg2: 00000000, 0.
Arg3: 82283120, The PRCB address of the hung processor.
Arg4: 00000000, 0.
3: kd> k
# ChildEBP RetAddr
00 8957a4e4 821c35df nt!KeBugCheckEx
01 8957a550 8212dbea nt! ?? ::FNODOBFM::`string’+0x309bd
02 8957a600 820211be nt!KeClockInterruptNotify+0x28a
03 8957a610 82030b93 hal!HalpTimerClockInterruptCommon+0x3e
04 8957a610 82179713 hal!HalpTimerClockInterrupt+0x1cb
05 8957a720 820b2bf8 nt!KiIpiSendPacket+0xdf
06 8957a778 8209e73a nt!MiFlushTbList+0x1ca
07 8957a858 82100912 nt!MmSetAddressRangeModified+0xa8
08 8957a900 8209b8ac nt!CcFlushCachePriv+0x3d0
09 8957a914 858c0f49 nt!CcFlushCache+0x18 0a 8957a968 858c125c Ntfs!NtfsFlushUserStream+0x67 0b 8957aa10 85889bff Ntfs!NtfsCommonFlushBuffers+0x1b6 0c 8957aa44 820e70bb Ntfs!NtfsCommonFlushBuffersCallout+0x1d
0d 8957aad4 820e6d23 nt!KeExpandKernelStackAndCalloutInternal+0x37b
0e 8957aaec 8588b9b3 nt!KeExpandKernelStackAndCalloutEx+0x1f
0f 8957ab28 8588b946 Ntfs!NtfsCommonFlushBuffersOnNewStack+0x3c
10 8957ab88 821ed2b0 Ntfs!NtfsFsdFlushBuffers+0x80
11 8957abac 820d7a52 nt!IopPerfCallDriver+0x119
12 8957abc0 855afe01 nt!IofCallDriver+0x62
13 8957abfc 855afb60
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x22c
14 8957ac28 821ed2b0 fltmgr!FltpDispatch+0xb1
15 8957ac48 820d7a52 nt!IopPerfCallDriver+0x119
16 8957ac5c 822eb66e nt!IofCallDriver+0x62
17 8957acb8 823a3cc7 nt!IopSynchronousServiceTail+0x16e
18 8957ad28 823a3b47 nt!NtFlushBuffersFileEx+0x177
19 8957ad44 8218a377 nt!NtFlushBuffersFile+0x15 1a 8957ad44 771a2da4 nt!KiSystemServicePostCall 1b 00bef7d8 771a1cae ntdll!KiFastSystemCallRet 1c 00bef7dc 74e169a7 ntdll!NtFlushBuffersFile+0xa 1d 00bef7f4 72225331 KERNELBASE!FlushFileBuffers+0x24 1e 00bef884 721f1c81 wevtsvc!File::WriteCurrentChunk+0x18d
1f 00bef8b4 771708f5 wevtsvc!File::FlushTimerCallback+0x45
20 00bef8d4 7716a038 ntdll!TppTimerpExecuteCallback+0x5c
21 00befad0 750c17ad ntdll!TppWorkerThread+0x368
22 00befadc 77183af4 KERNEL32!BaseThreadInitThunk+0xe
23 00befb20 77183acd ntdll!__RtlUserThreadStart+0x20
24 00befb30 00000000 ntdll!_RtlUserThreadStart+0x1b
0: kd> vertarget
Windows 8 Kernel Version 9600 MP (4 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS Personal Built by: 9600.17085.x86fre.winblue_gdr.140330-1035
Machine Name:
Kernel base = 0x82072000 PsLoadedModuleList = 0x82271438 Debug session time: Tue Jul 15 21:42:06.937 2014 (UTC + 8:00) System Uptime: 0 days 0:03:17.359
-------------
Below is the CPU0’s context information.
0: kd> !prcb 0
PRCB for Processor 0 at 82283120:
Current IRQL – 0
Threads-- Current 82292100 Next 9272e040 Idle 82292100 Processor Index 0 Number (0, 0) GroupSetMember 1 Interrupt Count – 00019f68
Times – Dpc 00000037 Interrupt 0000001f
Kernel 00002ee8 User 000000b6
0: kd> !thread 82292100
THREAD 82292100 Cid 0000.0000 Teb: 00000000 Win32Thread: 00000000 RUNNING on processor 0 Not impersonating
DeviceMap 82e0a7a8
Owning Process 82292540 Image: Idle
Attached Process 8459e040 Image: System
Wait Start TickCount 12190 Ticks: 440 (0:00:00:06.875)
Context Switch Count 32498 IdealProcessor: 0
UserTime 00:00:00.000
KernelTime 00:02:57.578
Win32 Start Address nt!KiIdleLoop (0x8218eaa8) Stack Init 833a0de0 Current 833a0d40 Base 833a1000 Limit 8339e000 Call 0 Priority 0 BasePriority 0 UnusualBoost 0 ForegroundBoost 0 IoPriority 0 PagePriority 5 ChildEBP RetAddr Args to Child
00000000 00000000 00000000 00000000 00000000 0x0
3: kd> ~0s
0: kd> r
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000
edi=00000000
eip=00000000 esp=00000000 ebp=00000000 iopl=0 nv up di pl nz na po
nc
cs=0000 ss=0000 ds=0000 es=0000 fs=0000 gs=0000
efl=00000000
00000000 ?? ???
0: kd> k
# ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 00000000 00000000 0x0
0: kd> !pcr 0
KPCR for Processor 0 at 82283000:
Major 1 Minor 1
NtTib.ExceptionList: 82276fa0
NtTib.StackBase: 00000000
NtTib.StackLimit: 00001f80
NtTib.SubSystemTib: 81241000
NtTib.Version: 00019e54
NtTib.UserPointer: 00000001
NtTib.SelfTib: 00000000
SelfPcr: 82283000
Prcb: 82283120
Irql: 0000001f
IRR: 00000000
IDR: 00000000
InterruptMode: 00000000
IDT: 8124e400
GDT: 8124e000
TSS: 81241000
CurrentThread: 82292100
NextThread: 9272e040
IdleThread: 82292100
DpcQueue: Unable to read nt!_KDPC_DATA.DpcListHead.Flink @ 82285300
0: kd> dt nt!_ktss 81241000
+0x000 Backlink : 0
+0x002 Reserved0 : 0
+0x004 Esp0 : 0x833a0dd0
+0x008 Ss0 : 0x10
+0x00a Reserved1 : 0
+0x00c NotUsed1 : [4] 0
+0x01c CR3 : 0
+0x020 Eip : 0
+0x024 EFlags : 0
+0x028 Eax : 0
+0x02c Ecx : 0
+0x030 Edx : 0
+0x034 Ebx : 0
+0x038 Esp : 0
+0x03c Ebp : 0
+0x040 Esi : 0
+0x044 Edi : 0
+0x048 Es : 0
+0x04a Reserved2 : 0
+0x04c Cs : 0
+0x04e Reserved3 : 0
+0x050 Ss : 0
+0x052 Reserved4 : 0
+0x054 Ds : 0
+0x056 Reserved5 : 0
+0x058 Fs : 0
+0x05a Reserved6 : 0
+0x05c Gs : 0
+0x05e Reserved7 : 0
+0x060 LDT : 0
+0x062 Reserved8 : 0
+0x064 Flags : 0
+0x066 IoMapBase : 0x20ac
+0x068 IoMaps : [1] _KiIoAccessMap
+0x208c IntDirectionMap : [32] “…”
The other thing I noticed is the IRQL level in TSS which is 0x1f. It’s a x86
Win81 OS so 0x1f the highest IRQL level. I search for HIGH_LEVEL and got below explanation:
HIGH_LEVEL: Machine checks and catastrophic errors; profiling timer for Windows XP and later releases
I doubt CPU0 is corrupted and failed to process its clock interrupt and CPU3 checked the timeout and triggered 0x101 BSOD. there should be MCE happens which runs in HIGH_LEVEL IRQL. But it confused me because I can’t find the MCE call stack.
Anyone have some suggestion? What else information can I got from the dump file?
—
WINDBG is sponsored by OSR
OSR is hiring!! Info at http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer