Question I'm getting "CLOCK/SYNTHETIC_WATCHDOG_TIMEOUT" sometimes whenever I am gaming ?

[ack-val]

I originally thought it was a valorant issue, but i recently installed apex legends and that also caused the same issues where i sometimes get blue screens usually with error code CLOCK_WATCHDOG_TIMEOUT or SYNTHETIC_WATCHDOG_TIMEOUT, but sometimes the screen just freezes and usually takes a minute or two to blue screen then restart, but when that happens it doesn't leave a dump file.

I started getting this issue in June, but i have tried many fixes such as uninstalling software and installing drivers, and i even clean reset Windows using Tiny10 but the issues still persist. I dont have every dump file but i can provide 3 as well as !analyze -v outputs for most crashes.

The PC is prebuilt Acer.

Specs:
i5-8400,
GTX 1050
16GB DDR4
1TB HDD

dump files:

dump files – Google Drive

drive.google.com

 

[ubuysa]

First off, Tiny10 is not an official Windows release, so if you're still running that version I'm unable to help.

If you're now running an official Windows 10 release however, can you please upload the kernel dump in the file C:\Windows\Memory.dmp. It will be large (1GB to 2GB). These types of clock watchdog timeouts can only be analysed with a kernel dump, because a mindump only contains the data fields for the failing processor and we need to be able to access the data areas for all processors.

The bad news is that these types of clock watchdog are almost always caused by a bad CPU. One or more processors are failing to respond to regular clock synchronisation interrupts. I would therefore suggest that you download Prime95 and run all three tests (small FFTs, large FFTs, and Blend) for a minimum of 4 hours each test. This will make your CPU run very hot, so you need som real-time temperature monitor running, something like HWMonitor or CoreTemp.

If Prime95 generates errors, if the system BSODs or crashes, or if the CPU gets dangerously hot (Tjunction for your CPU is 100C) then stop Prime95 and let us know what happened.

 

[ack-val]

I ran prime95 (blend) and the system froze and wouldnt restart so i had to use force power button, but i ran it again (small fft, large fft, blend) and it passed all tests (running for 4 hours each). Second, i was originally running a windows pro build, then clean resetting to tiny10, but issues are same. avg cpu core temps were ~65-75C. Do i need to run more tests? I am also considering using memtest86 to check my ram. I added the memory.dmp file to the drive

 

[ubuysa]

It will do no harm to run Memtest86 (free), but if no errors are found aafter the four iterations of the 13 tests that the free version does, then restart Memtest86 and do another four.

That said, I think this is most likely a CPU problem. I'll explain in a bit more detail...

A 0x101 BSOD occurs because a processor failed to respond to a clock synchronisation request within a specified time. It indicates a hung processor, and whilst that's most usually a hardware problem, it can be caused by a driver running at a high IRQL blocking the clock synchronisation interrupt.

In your kernel dump we can see that the processor that failed to respond to the clock synchronisation request was processor #1 (see argument 4)...

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: 0000000000000020, Clock interrupt time out interval in nominal clock ticks.
Arg2: 0000000000000000, 0.
Arg3: ffffc000f2100180, The PRCB address of the hung processor.
Arg4: 0000000000000001, The index of the hung processor.

If we look at the processor control block for processor #1 we can see what IRQL it was running at...

3: kd> !prcb 1
PRCB for Processor 1 at ffffc000f2100180:
Current IRQL -- 0
Threads--  Current ffffad02da149080 Next ffffad02d0c8d640 Idle ffffc000f210b1c0
Processor Index 1 Number (0, 1) GroupSetMember 2
Interrupt Count -- 8b2a8cf0
Times -- Dpc    0001dbd0 Interrupt 000189b8
         Kernel 0198dd26 User      00677c38

The CurrentIRQL value of 0 is the lowest IRQL, when running at this IRQL the clock interrupt is not blocked, that means the failure to respond must be hardware (CPU) related.

The processor with the focus in the debugger at the moment is processor #3, the one that detected the clock watchdog timeout. If we display the call stack you can see that normal processing is happening...

3: kd> kv
 # Child-SP          RetAddr               : Args to Child                                                           : Call Site
00 ffffc000`f24f7c88 fffff800`0d443a04     : 00000000`00000101 00000000`00000020 00000000`00000000 ffffc000`f2100180 : nt!KeBugCheckEx
01 ffffc000`f24f7c90 fffff800`0d286e3d     : 00000000`00000000 ffffc000`f24de180 00000000`00000246 00000000`02012e30 : nt!KeAccumulateTicks+0x1bfde4
02 ffffc000`f24f7cf0 fffff800`0d27dec1     : 00000000`02012c00 00000000`0131e11e ffffc000`f24de180 00000000`00000001 : nt!KiUpdateRunTime+0x5d
03 ffffc000`f24f7d40 fffff800`0d281253     : ffffc000`f24de180 00000000`00000000 fffff800`0dc318a0 00000000`00000000 : nt!KiUpdateTime+0x4a1
04 ffffc000`f24f7e80 fffff800`0d288ae2     : fffff68c`16869e50 fffff68c`16869ed0 fffff68c`16869e00 00000000`0000000c : nt!KeClockInterruptNotify+0x2e3
05 ffffc000`f24f7f30 fffff800`0d33ec65     : 000004c7`87ea5077 ffffad02`ad52d9e0 ffffad02`ad52da90 00000000`00000000 : nt!HalpTimerClockInterrupt+0xe2
06 ffffc000`f24f7f60 fffff800`0d3fdf5a     : fffff68c`16869ed0 ffffad02`ad52d9e0 00000000`00000001 00000000`00000000 : nt!KiCallInterruptServiceRoutine+0xa5
07 ffffc000`f24f7fb0 fffff800`0d3fe727     : 00000000`00000000 fffff800`0dd2f268 fffff800`07cb9138 fffff800`0d2eae5a : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa (TrapFrame @ ffffc000`f24f7e70)
08 fffff68c`16869e50 fffff800`0d2ea9c1     : fffff68c`1686a028 fffff68c`1686a020 00000000`00000000 00000000`00000000 : nt!KiInterruptDispatchNoLockNoEtw+0x37 (TrapFrame @ fffff68c`16869e50)
09 fffff68c`16869fe0 fffff800`0d6123b3     : 00000000`00000000 fffff68c`1686aa80 00000000`00000001 00000000`00000001 : nt!KeFlushProcessWriteBuffers+0xb5
0a fffff68c`1686a020 fffff800`0d609037     : 00000000`00000000 00000000`00016000 ffff9a0f`4f8368d0 00000000`00000000 : nt!ExpGetProcessInformation+0x183
0b fffff68c`1686a680 fffff800`0d6081e7     : ffffad02`ad52d680 fffff800`0d2f625a 00000000`00000094 000001d6`7c343040 : nt!ExpQuerySystemInformation+0xd07
0c fffff68c`1686a9c0 fffff800`0d40ff9a     : 00000000`00000000 00007fff`d3345554 fffff68c`1686aa80 ffffad02`caf089f0 : nt!NtQuerySystemInformation+0x37
0d fffff68c`1686aa00 00007fff`d416d774     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceExitPico+0x3ef (TrapFrame @ fffff68c`1686aa00)
0e 0000003c`2ac7ee28 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x00007fff`d416d774

This is the kind of call stack you see on an active processor. Even a processor that's idle has functions on its call stack as it runs the idle loop.

If we now switch the dump focus to processor #1 and then display the call stack for that processor...

3: kd> ~1
1: kd> kv
 # Child-SP          RetAddr               : Args to Child                                                           : Call Site
00 00000000`00000000 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0
1: kd> .frame /r 0
00 00000000`00000000 00000000`00000000     0x0
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000000 rsp=0000000000000000 rbp=0000000000000000
 r8=0000000000000000  r9=0000000000000000 r10=0000000000000000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up di pl nz na pe nc
cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
00000000`00000000 ??              ???

Here you can see nothing at all, it's all zeros, even the processor registers are empty, and that is extremely unusual, I've never seen an empty call stack before. To me this indicates a dead processor.

Processor #4 is the same, it's all zeros and apparently dead. The other four processors in your CPU are behaving normally. I'm wondering whether Prime95 simply didn't run on these two cores? I would suggest downloading the Intel Processor Diagnostic Tool and see what that reports.

I've also referred this to a BSOD analysts group to which I belong to get their input, but I think this is a CPU failure in two cores.

 

[ack-val]

it could be that the processor isnt always dead, and does works and randomly stops since intel processor diagnostic tool doesnt recognise any issues. i even had on loop but still nothing

--- IPDT64 - Revision: 4.1.8.40
--- IPDT64 - Start Time: 2023-09-05 6:58:31 AM

----------------------------------------------
-- Testing
----------------------------------------------
CPU 1 - Genuine Intel - Pass.
CPU 1 - BrandString - Pass.
CPU 1 - Cache - Pass.
CPU 1 - MMXSSE - Pass.
CPU 1 - IMC - Pass.
CPU 1 - Prime Number - Pass.
CPU 1 - Floating Point - Pass.
CPU 1 - Math - Pass.
CPU 1 - GPUStressW - Pass.
CPU 1 - CPULoad - Pass.
CPU 1 - CPUFreq - Pass.

IPDT64 Passed
--- IPDT64 - Revision: 4.1.8.40
--- IPDT64 - End Time: 2023-09-05 7:02:20 AM

----------------------------------------------
PASS

 

[ack-val]

i was running prime 95 for a few seconds (blend mode) and the system has frozen and no blue screen. is there a way to analyze this? like triggering a bsod? (caps lock stuck to off)

 

[ubuysa]

I still think that this is the CPU. You've reinstalled Windows and as long as you installed all necessary drivers each time, that means the issue is hardware.

If you open Task Manager and click the Performance tab, and then the CPU option, how many CPU cores does it report? And if you change the graph to display logical processors how many are active (positive value on the graph)?

You said that this issue started in June, so what changed in June?

 

[ack-val]

Ran prime95 for abt 7 hours and core 1 and 4 seems to have less activity (img1). Task manager and other programs also report there being 6 cores (img2). As for finding the issue, theres not much i did in june which would cause issues, let alone also done on this build of windows. I also looked around at the parameter 4 of past bsod, they were usually 0x0, 0x1, or 0x3. Dont forget that i also get SYNTHETIC_WATCHDOG_TIMEOUT at around the same frequency as CLOCK_WATCHDOG_TIMEOUT

img1:https://cdn.discordapp.com/attachments/805823739325317178/1148698775280422922/image.png
img2:https://media.discordapp.net/attachments/805823739325317178/1148699053882884236/image.png

 

[ubuysa]

The SYNTHETIC_WATCHDOG_TIMEOUT is a global form of the CLOCK_WATCHDOG_TIMEOUT. The latter occurs when one processor fails to respond to the clock synchronisation interrupt, the former occurs when no processors respond to the clock synchronisation interrupt.

That Prime95 runs for 7 hours is encouraging but you have also had freezes when running Prime95. The kernel dump quite clearly shows that the failing processor at the time (processor #1) was completely unresponsive. That all raises a big red flag over the CPU for me.

I have seen CPUs that were unstable when idle and in a low power state but were fine when running. That could be what's happening here. A quick way to tell is to enable the Windows High Performance power option, that profile doesn't allow low power states for any hardware, so see whether it's stable using the High Performance power option.

What PSU do you have? A flaky PSU can cause all sorts of strange issues, especially when under load, such as when gaming.

 

[ack-val]

Since i have a prebuilt, i do believe that the psu could be the issue here as it is just a random chinese psu thats probably also a fire hazard, but i did have my power plan set to high performance beforehand

 

[sitehostplus]

Let me see if I can hazard a guess here.

Is this happening while playing a game called 'valorant' or anything else made by riot games?

If it is, try this.

Other things that cause the error you're seeing:

1. Overclocking. Back off and see what happens.

2. Faulty ram module. Toms has several memory testers you can try to see if this is the problem. Read about it here.

3. Corrupted hardware driver.

Here's more information on your problem.

Let me know if any of this helps.

 

[ubuysa]

Well, we know it's a hardware problem. Is there any possibility of begging or borrowing a better PSU?

If a replacement PSU doesn't stop the BDODs then I'd put my money on the CPU.

If you get any more of these BSODs please upload the kernel dump (in C:\Windows\Memory.dmp) as soon as you can. There is only ever one kernel dump, a new BSOD will overwrite it.

 

[ack-val]

I dont have any extra parts on hand currently, and would like to avoid buying a new psu because it is an old pc, so I think it should be fine if we wait until i can get more information

 

[ubuysa]

Ok. Every time you get a CLOCK_WATCHDOG_TIMEOUT or a SYNTHETIC_WATCHDOG_TIMEOUT BSOD upload the kernel dump (C:\Windows\Memory.dmp) to the cloud and post a link to it here. There more dumps we can see the more reliable any diagnosis will be.

In the meantime, you could try changing the Processor Power Management settings in your current power plan so that the Maximum Processor State and Minimum Processor State are both set to 99%. This should also stop the processors idling into a low power state and might mitigate the possible CPU problem. It's worth a try anyway.

 

[ack-val]

I will update if i keep getting issues, but for now keep yourself safe

 

[ubuysa]

Ok. I think it's worth checking your PSU if you can. I've seen flaky PSUs creating all sorts of issues.

 

[ack-val]

New BSOD. Added memory.dmp file to the google drive, may take a while to upload

 

[ubuysa]

I've been talking again withe the very experience BSOD analysts in the group to which I belong and it seem that these 'all zero' processor displays are not that uncommon, it just means that no context was saved for that processor.

In your first kernel dump the processor that failed to respond to the clock synchronisation interrupt (processor #1) was running vgk.sys, so it appears that vgk.sys cleared the interrupt flag, preventing the processor from responding to the clock interrupt and generating the BSOD.

In this new kernel dump the processor that failed to respond to the clock synchronisation interrupt was processor #0 and the interrupt flag was again zero, preventing this processor from responding. However, vgk.sys was not running on this processor, but it was running on the processor that detected the clock watchdog timeout (processor #2).

It's too much of a coincidence to find vgk.sys on two processors involved in a 0x101 bugcheck in two different dumps, so the consensus is that vgk.sys is the most likely cause. Can you please try disabling and uninstalling Riot Vanguard - that where vgk.sys comes from - and reboot (to ensure that vgk.sys is not loaded). See whether the BSODs continue. If they do, upload the new kernel dump please.

 

[ack-val]

New BSOD (was playing valorant). gonna update drive in a few mins