CPU C0 below 100%, but no higher C state registered?

[Timur Born]

Can anyone explain this behavior? This happens after setting a power plan's "Processor Idle disable" to "Disable Idle". This should disable all C-states other than C0 and run all cores at maximum all-core boost ratios, including Effective Clocks. It happens on a new installation of Windows 11, but did not happen on an older upgrade-from-W10 installation.

As soon as Throttlestop is started the behavior changes to the expected 100% C0 Residency, I don't even have to confirm TS' popup to fully load its GUI.

 

[Martin]

There is a know issue with Windows Defender that messes up with some counters like the Effective Clock.
ThrottleStop should be reporting this case.

 

[Timur Born]

Thottlestop fixes this as soon as it is loaded, even just at the first warning popup stage. It then stays fixed without TS being loaded until the next restart (or maybe for some prolonged time, have to test) even over a relogin and power plan switching.

 

[Martin]

Please attach 2 Debug Files: one when the problem is happening before starting TS and another one after starting TS.

 

[Timur Born]

Will do in a few minutes. I am currently checking how Defender affects this. At this moment I am in a state where switching Realtime Protection on only drops Effective Clocks + C0 readings for one HWinfo poll (2 seconds) and then everything gets back to normal. I did *not* change any Defender settings for that (and Memory Integrity is disabled anyway), so give me some minutes to reproduce this.

 

[Martin]

When Windows Defender messes up those counters, HWiNFO tries to override it which can result in a fight between them both.
You might also try to reduce the polling period in HWiNFO, then HWiNFO might be sampling the values faster than Windows Defender overriding them.

 

[Timur Born]

Disabling and then re-enabling Realtime Protection also seems to fix the counters over prolonged times, including a sign out + relogin. Even switching power plans for a short time seems to work then, but at some point it reverts back to the bugged behavior. Unfortunately I could not reproduce what makes it revert to being bugged. I assume that some "event" makes it switch back to misbehaving, I saw that happen after using a different (idle) power plan for some time and it also happens some minutes after a reboot (but not right away).

I attach three files, the "mixed" one is the longest where switching Realtime Protection off (and back on) fixed it and then I restarted HWinfo right after a reboot when it first doesn't happen and then after some minutes reverts back to being bugged.

PS: Using a faster polling rate is not a good fix, because there are still too many fluctuations and the polling may affect the very reading one is trying to get.

 

[Timur Born]

Here is another one with Throttlestop "fixing" the issue instead of switching Realtime Protection.

 

[Martin]

Yes, this is the typical behavior of Windows Defender constantly reconfiguring the counters while both HWiNFO and TS try to set it back.
Does running TS once fix this problem for the entire run time or do you perhaps still see some lower values?
I think that both HWiNFO and TS are attempting the same, maybe TS does it faster so it manages to override Defender more effectively.

 

[Timur Born]

TS fixes the problem just by starting and stopping TS, so it is not a thing of constantly reapplying the counters in quick succession. Both TS and turning Realtime Protection off->on fix the issue for prolonged time without constantly having to reconfigure values like HWinfo does, but I think there are (unreproducible) conditions where the problems happens again after some time.

 

[Timur Born]

And for Throttlestop it is enough to load the initial warning popup (when no configuration file exists yet), even when TS uses no single CPU cycle afterwards anymore and also when TS is stopped altogether (process killed). So whatever TS (and disabling Realtime Protection) does, it does not have to be re-applied every few milliseconds or even minutes. HWinfo might be able to use this to more reliably keep Defender in check without having to use fast polling rates (that still cause fluctuations from HWinfo battling Defender).

 

[Martin]

Hmm, I have to admit that I have no idea what Throttlestop does here.
Can you try to disable the "Windows Defender Boost" feature in TS to see if that's doing it?

 

[Martin]

I have read some explanations from Throttlestop author and what he describes it's doing it should be the same what HWiNFO does as well:

Windows Defender can Significantly Impact Intel CPU Performance, We have the Fix

Kevin Glynn, aka "Uncle Webb," our associate software author behind popular utilities such as ThrottleStop and RealTemp, developed a new utility named Counter Control, which lets you monitor and log the performance counters of Intel Core processors since 2008 (Core "Nehalem"). During development...

www.techpowerup.com

I don't know why it doesn't work for HWiNFO permanently and it gets overriden shortly after..

 

[Timur Born]

I will watch this a bit using the Counter Control application. Disabling "Windows Defender Boost" would indeed lead to TS only keeping Defender in check for a few seconds to minutes, but still not quickly fluctuating within milliseconds as with HWinfo's battle vs. Defender.

In the Readme of Counter Control it mentions "Windows Defender Real-time Protection notification feature is randomly setting the three fixed function counters to mode 2". So I disabled notifications for a test, but that made no difference.

 

[Timur Born]

What strikes me odd is that I did not see this happen on my former Windows 11 installation. I remembered wrong about it being an "upgrade" from W10, it was a clean installation, but it was originally installed on an AMD 5900X and then just moved over to the Intel 13900K. So whatever Windows set up during the original 5900X installation (and using the system for some time), seems to have translated over when I moved the M.2 over to the Intel system and thus kept Defender from messing with the counters.

 

[Timur Born]

Using the "Reset Counters" button in Counter Control also stops Defender from changing the counter for prolonged time even in a situation where Defender and HWinfo were battling for the counter ongoingly just seconds ago.

 

[Timur Born]

Here you can see HWinfo and Defender battling it out every second until I hit the "Reset Counters" button just *once*. 8 minutes later the counters still didn't switch anymore.

 

[Martin]

I can see one difference between TS and HWiNFO. There are multiple counters and HWiNFO uses only two of them - FIXED_CTR_1 and FIXED_CTR_2, hence it enables only those and doesn't touch the others.
Now when the problem is happening FIXED_CTR_0 is also enabled in user-only mode (probably by Defender).
TS seems to configure all counters 0-2 so that FIXED_CTR_0 is disabled, FIXED_CTR_1 and FIXED_CTR_2 are enabled for both user/kernel mode: 0x330 (the right-most 0 denotes FIXED_CTR_0 is disabled).
However HWiNFO doesn't touch FIXED_CTR_0, so the result of its enabling will be: 0x332
My theory is that maybe this situation is not properly evaluated by Windows Defender and it won't prevent it from reconfiguring the counters to its own mode: 0x222

 

[Timur Born]

50 minutes later the counters still are left untouched by Defender. So maybe HWinfo should set all three counters just once at program start to tell Defender to leave it alone? Is there a performance tax for resetting these counters every polling period instead of just once?

 

[Martin]

HWiNFO sets them only once and won't change unless it determines something else reverted them.
Problem seems to be that Windows Defender doesn't seem to recognize that HWiNFO is using them. Maybe because it doesn't disable counter 0 which does TS.