High CPU load
- Thread starter waleedov
- Start date
Not to be annoying, I allowed the "pro" update function today - to go from 7.62 build 5200 -> 7.63 build 5220 BETA.
I don't think it was right away, but after a few hours I noticed that HWiNFO64.exe was sucking up a whole "core" (5%+) CPU loading on my Alder Lake 12th gen. This continued as long as a I cared to watch, so I reverted to 5200.
Win 11 Pro "Insiders" build 22631.2338.
I don't think it was right away, but after a few hours I noticed that HWiNFO64.exe was sucking up a whole "core" (5%+) CPU loading on my Alder Lake 12th gen. This continued as long as a I cared to watch, so I reverted to 5200.
Win 11 Pro "Insiders" build 22631.2338.
Would be good to know why that happens, could be due to integration of PresentMon or something else. You might try what I proposed above and let me know the results so I can look into that.
Unfortunately, this is still present in the newest build - 5230. 
I have no idea where these settings are that you mentioned above - I looked all over the place for anything that looked like a "Profiling Time" column - I couldn't even find where to add or take away columns in general, and that surprised me.
In any case, since I don't like seeing a core busy all the time, I reverted again to 5200.
I have no idea where these settings are that you mentioned above - I looked all over the place for anything that looked like a "Profiling Time" column - I couldn't even find where to add or take away columns in general, and that surprised me.
In any case, since I don't like seeing a core busy all the time, I reverted again to 5200.
Good and bad news - with PresentMon ENABLED, resuming from sleep will flip HWiNFO into 5% CPU utilization - which is, of course, considered a logical core on my Alder Lake (8P+4E=20 threads).
I tried first just to run a graphically intense game to see if that would cause any trouble, but it didn't.
The "bad news" is just that, once this 5% thing is going, disabling PresentMon will NOT stop it.
I tried first just to run a graphically intense game to see if that would cause any trouble, but it didn't.
The "bad news" is just that, once this 5% thing is going, disabling PresentMon will NOT stop it.
I'm trying to reproduce this problem but so far I wasn't able to see any increase in CPU usage.
So the utilization ramps up immediately after resuming from sleep? Does restarting HWiNFO after that solve the problem?
Can you confirm that it's the HWiNFO64 process that takes excessive usage after resume? This can be checked in the Details tab of Task Manager.
And when you disable PresentMon Support via global settings and then start HWiNFO no such increase in usage happens?
So the utilization ramps up immediately after resuming from sleep? Does restarting HWiNFO after that solve the problem?
Can you confirm that it's the HWiNFO64 process that takes excessive usage after resume? This can be checked in the Details tab of Task Manager.
And when you disable PresentMon Support via global settings and then start HWiNFO no such increase in usage happens?
Last edited:
Yes, immediately on resume, one poor little "logical processor" is pegged - by the HWiNFO process.
If I disable PresentMon, I can make the high CPU go away - yes, it requires not just the option reset, but an actual restart of HWiNFO.exe to make the excess CPU usage go away.
Unfortunately, sleeping and resuming will still jump HWiNFO's CPU usage up - even with PresentMon disabled, the app restarted, and things looking happy before the sleep/resume.
So, back to 5200 - anything after that exhibits this undesirable behavior.
While it doesn't actually seem to care about graphics, I will mention I am using an RTX 4070 with the next-to-latest NVidia driver (537.34).
If I disable PresentMon, I can make the high CPU go away - yes, it requires not just the option reset, but an actual restart of HWiNFO.exe to make the excess CPU usage go away.
Unfortunately, sleeping and resuming will still jump HWiNFO's CPU usage up - even with PresentMon disabled, the app restarted, and things looking happy before the sleep/resume.
So, back to 5200 - anything after that exhibits this undesirable behavior.
While it doesn't actually seem to care about graphics, I will mention I am using an RTX 4070 with the next-to-latest NVidia driver (537.34).
Hi all,
I noticed this as well. After trying the current version and also beta version, this issue still persists.
That's why I tried multiple older version(s) and found one which still doesn't have this issue: 7.26 ( !!! without the AORUS coloured layout in the main settings !!! )
So, there must be a code change from 7.26 --> 7.30 (or later in the 7.3x series ) which generates this issue.
Regards
I noticed this as well. After trying the current version and also beta version, this issue still persists.
That's why I tried multiple older version(s) and found one which still doesn't have this issue: 7.26 ( !!! without the AORUS coloured layout in the main settings !!! )
So, there must be a code change from 7.26 --> 7.30 (or later in the 7.3x series ) which generates this issue.
Regards
This can have several reasons like adding support of new sensors that take more time to read.
For such case I recommend enabling the "Profiling Time" column in HWiNFO, then see which sensor takes most time and disable its monitoring.
If you figure that out, please let us know which one is causing it.
For such case I recommend enabling the "Profiling Time" column in HWiNFO, then see which sensor takes most time and disable its monitoring.
If you figure that out, please let us know which one is causing it.
Yes... I am not concerned with those sensors.. so disabling seems to be the best course of action.
Don't have any other monitoring-specific software installed... AMD GPU drivers have monitoring of course, so unsure if that could be a culprit. I did update those recently.
Thanks!
Yes! This is *exactly* what I see on my Gigabyte Z690 mobo - these two sensor groups are where the time is going - in the same amount(s) as shown above.
But, not to be tiresome, there was no problem with build 5200... it all happened immediately after that.
So, rather than disabling these sensors, maybe checking what changed in the code that has a problem now that didn't previously?
And, for full clarity, this is still present for me with BETA build 5250 on my Intel 12-th gen Alder Lake CPU and mobo, with Windows 11 "Insider" build 22635.2552.
But, not to be tiresome, there was no problem with build 5200... it all happened immediately after that.
So, rather than disabling these sensors, maybe checking what changed in the code that has a problem now that didn't previously?
And, for full clarity, this is still present for me with BETA build 5250 on my Intel 12-th gen Alder Lake CPU and mobo, with Windows 11 "Insider" build 22635.2552.
Last edited:
Is it possible that in earlier versions these sensors were not shown in HWiNFO? Because that's what changed recently - HWiNFO enabled their monitoring.
Note, that after running later HWiNFO builds you might need to reboot the system before trying older versions. That's because newer versions enable access to those sensors.
Not even running GIGABYTE SIV ?
Note, that after running later HWiNFO builds you might need to reboot the system before trying older versions. That's because newer versions enable access to those sensors.
Not even running GIGABYTE SIV ?
I have no idea what is/was shown in HWiNFO, as I never mess with "customizing" or changing away from whatever is the default display... the first time I have done anything to change the default displays is due to your asking in relation to this issue.
With that said, I just looked at my [restored] build 5200 display and you are of course correct - I do not see these particular sensor groups, I just see a pair of GIGABYTE Z690 AORUS MASTER groups, one with "(ITE IT8689E)" added on, and the other with "(ITE IT87952E)" added.
Last edited: