Short Answer
The CLOCK_WATCHDOG_TIMEOUT BSOD occurs because a processor did not respond in time to a clock synchronisation interrupt, these are used to synchronise the various processor clocks. The failing processor (processor 10) is stuck in an MWaitIdle state, this is a special Intel power management state which probably allows the processor to enter a lower power state because there is no useful work for it to do (it's idle). In the MWait state however, the processor should respond to any interrupt - like the clock synchronisation interrupt - and it didn't. The software environment is all as expected so that failure to respond to the interrupt must be a hardware failure. You need to replace the CPU I'm afraid.
The WHEA (Windows Hardware Error Architecture) BSODs you've been getting are also suggestive of a CPU problem, but this CLOCK_WATCHDOG_TIMEOUT confirms it. You may want to stress your CPU with the tools mentioned above, but I doubt that it will get very far in any of them. It's terminal sadly.
Longer Answer
The CLOCK_WATCHDOG_TIMEOUT writes the faulty processor identifier in argument 4 of the parameters passed when the bugcheck occurs....
Rich (BB code):
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: 000000000000000c, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffb901dc7e4180, The PRCB address of the hung processor.
Arg4: 000000000000000a, The index of the hung processor.
This of course is processor 10 in decimal. If we examine the call stack of processor 10...
Rich (BB code):
10: kd> knL
# Child-SP RetAddr Call Site
00 ffff948c`f2abef78 ffffb7c0`f246be46 intelppm!MWaitIdle+0x1f
01 ffff948c`f2abef80 0000002c`88cac0e0 0xffffb7c0`f246be46
02 ffff948c`f2abef88 ffff9d08`3107a0f0 0x0000002c`88cac0e0
03 ffff948c`f2abef90 ffffb901`dc7e4180 0xffff9d08`3107a0f0
04 ffff948c`f2abef98 00000000`00000000 0xffffb901`dc7e4180
These stacks are read from the bottom up (they're push down stacks), you can see that the last function that was called was intelppm!MWaitIdle. This is an Intel function that essentially handles power management of the processors, the MWaitIdle component places the processor in an idle state and (probably) a lower power state - but this is Intel specific. In the MWaitIdle state the processor is still enabled for interrupts and so should have responded to the clock synchronisation interrupt but it didn't.
Interestingly, if we examine the Interrupt Flag (the IF register) it should be at logical 1 if the processor is enabled for interrupts, and it's not...
That could indicate a problem with the interlppm.sys driver, though that's very unlikely. You could try installing the Intel Driver & Support Assistant and see whether that finds driver updates for the Intel hardware you have. This could also be related to the MWait instruction that Intel processors use to put the processor in a lower power idle state with interrupts enabled, it's possible that the MWait instruction doesn't set the IF register. I don't know nearly enough about the Intel x64 instruction set to know for sure.
If we look instead at processor 0 (the one that detected the problem) we can see what processor 10 should have done...
Rich (BB code):
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff801`24ca7c88 fffff801`20643704 nt!KeBugCheckEx
01 fffff801`24ca7c90 fffff801`20486e3d nt!KeAccumulateTicks+0x1bfae4
02 fffff801`24ca7cf0 fffff801`2047dec1 nt!KiUpdateRunTime+0x5d
03 fffff801`24ca7d40 fffff801`20481253 nt!KiUpdateTime+0x4a1
04 fffff801`24ca7e80 fffff801`20488ae2 nt!KeClockInterruptNotify+0x2e3
05 fffff801`24ca7f30 fffff801`2053e965 nt!HalpTimerClockInterrupt+0xe2
06 fffff801`24ca7f60 fffff801`205fdc3a nt!KiCallInterruptServiceRoutine+0xa5
07 fffff801`24ca7fb0 fffff801`205fe407 nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
08 ffff948c`f98ce810 fffff801`204ea6c1 nt!KiInterruptDispatchNoLockNoEtw+0x37
09 ffff948c`f98ce9a0 fffff801`208120e3 nt!KeFlushProcessWriteBuffers+0xb5
0a ffff948c`f98ce9e0 fffff801`20808d67 nt!ExpGetProcessInformation+0x183
0b ffff948c`f98cf040 fffff801`20807f17 nt!ExpQuerySystemInformation+0xd07
0c ffff948c`f98cf380 fffff801`2060f4f5 nt!NtQuerySystemInformation+0x37
0d ffff948c`f98cf3c0 00007ff9`f518d724 nt!KiSystemServiceCopyEnd+0x25
0e 00000066`67bdd478 00000000`00000000 0x00007ff9`f518d724
You can see the call to nt!HalpTimerClockInterrupt on receipt of the clock synchronisation interrupt. Processor 10 should have responded in a similar way and didn't. That's a hardware fault in the CPU.
