8.20-5640 Win 10 frozen/stuck sensors, only hard reboot fixes

[scastle]

In my system, with HWiNFO 8.20-5640 (pro) and Rainmeter, using shared memory, about every two days the sensors freeze - all the lines in Rainmeter go flat, and in the sensor window, the values don't change. If HWiNFO is shut down there is screen after screen saying that a sensor is stuck, and finally, it won't die, not even when killed from task manager. Only a hard power-off or reset will allow the system to restart. I am attaching a DBG and system report. Unfortunately, I get the message "The uploaded file is too large for the server to process." for the DBG file. I will try zipping it.

 

[Martin]

Which sensor does it claim to be stuck, the EC sensor perhaps? You might try to disable monitoring of the EC sensor.

 

[scastle]

All sensors, AFAICT. Starts with CPU, then goes on to fan 1, fan 2... I will disable EC anyhow to see if there is a change.

 

[red-ray]

Only a hard power-off or reset will allow the system to restart.

What state is the HWiNFO service in after you have aborted HWiNFO and can you stop it? From an admin command window use commands such as:

sc query type= driver | find "HW"
sc query HWiNFO_204
sc stop HWiNFO_204

Attached is what should happen, first when HWiNFO exited normally and then when I aborted it. Note the name may change from HWiNFO_204 to HWiNFO_205 or later.
.
I am wondering if the service won't stop in which case the issue is probably the driver stuck trying to read the problem sensor. If the driver is stuck then before aborting HWiNFO select Create Dump File and by looking at the dump it should be easy enough for the HWiNFO developers to tell which sensor was trying to be read.

 

[scastle]

What state is the HWiNFO service in after you have aborted HWiNFO and can you stop it?

Good question. If/when it happens again I will try that. The usual sequence I followed at first was (1) quit HWiNFO, whereupon it would display the stuck sensor messages, (2) then I would try to kill it using task mgr, which would not kill it, (3) try to kill it again, (4) try to do a normal restart or shutdown, which would not finish, and finally (5) hit the hard reset button or the power button. I couldn't see anything in the event logs that pointed at a failing component. Recently I've been going for the hard reset or poweroff directly. I will try your sc commands at each of the stages (well, not the 4th, because I have no console at that point) next time.

 

[scastle]

Here's an interesting wrinkle: when I issue the command "sc query type=driver | find "HW" " I get two hits - both HWiNFO_178 and HWiNFO_204 are found. I'm wondering if there's some kind of conflict/race condition going on. Looks like something belonging to an earlier release got left during an update?

 

[Martin]

A conflict here is not possible. You can do a "sc delete HWiNFO_178".

 

[scastle]

Issued stop followed by delete. Now to create a restore point.

 

[red-ray]

After pondering this I suspect that when HWiNFO is stuck it's holding the lock for whichever sensor is causing the issue, so if we could find out which lock then that would probably tell us which set of sensors has the issue.

The only program I know of that can do this is my SIV utility which has Menu->Help->Lock Handle, but once the system is frozen I suspect SIV won't start as it will wait for the lock on start-up, however it should log the fact it can't get to lock to SIV_DBGOUT.log every 20 to 30 seconds so by looking at the log we can find out the lock and hence which set of sensors. From SIV V5.79 SIV also has Menu->Edit->Options->Lock Setup and if SIV was running when the system froze I expect it would automatically popup this panel which should tell us the lock name and the program holding it, it would also report that programs thread name if that program used SetThreadDescription() to set it. In general it should never popup, I had to set Mutex Wait First to 100ms to make it happen.

 

[scastle]

I've been up without issues for 3 days now. If it makes it to 4 I will re-enable EC support and see how that goes.

Also, replying to red-ray: the system does not lock up and freeze, only the sensor reporting by HWiNFO and Rainmeter. But, if it happens again, I will try to fire up SIV and see what it says.

 

[red-ray]

I was lax with my wording, given you can abort HWiNFO then clearly the system is not totally frozen, just some of the sensors.

After posting I checked if SIV had code to report EC sensors on your ASUS ProArt Z790 and it didn't so I added it for SIV 5.80 Beta-04. It would be wise to check what SIV reports when the system is working as expected, there should be System Power Usage + an EC section on the initial screen. I wonder if it will still detect/report them when there is the issue and suspect you will have to abort HWiNFO so SIV can get the Global\Access_EC lock.

 

[scastle]

After posting I checked if SIV had code to report EC sensors on your ASUS ProArt Z790 and it didn't so I added it for SIV 5.80 Beta-04. It would be wise to check what SIV reports when the system is working as expected, there should be System Power Usage + an EC section on the initial screen. I wonder if it will still detect/report them when there is the issue and suspect you will have to abort HWiNFO so SIV can get the Global\Access_EC lock.

I downloaded that beta using your link, thanks. I will get some baseline info as you suggest.

 

[scastle]

Owing to my need for monitoring of the EC, it seems I can no longer use HWiNFO64 to report my sensors. It hangs so badly that only a hard reboot corrects it, and then not for very long - within a day or two it hangs again. So, I no longer run HWiNFO64. If this is not corrected, I will not be renewing my pro subscription, either. I'm sorry about this because it had worked well for me up until the 8.20 release. 8.22 is no better, either. So now I run with only the CoreTemp display on the task bar.

I suppose it's possible this is shared memory issue. I may explore using HWiNFO64 and Rainmeter without shared memory and see how that works out.

 

[Martin]

Are you perhaps running any other monitoring/tweaking/fan/RBG control application along with HWiNFO? This includes ASUS AI Suite too.
If yes, try to close the other apps (AI Suite might require uninstall as it has background services running even if closed).

 

[scastle]

Are you perhaps running any other monitoring/tweaking/fan/RBG control application along with HWiNFO? This includes ASUS AI Suite too.
If yes, try to close the other apps (AI Suite might require uninstall as it has background services running even if closed).

I mentioned CoreTemp, which has never caused an issue before. I have avoided AISuite, as it never has offered anything to me after Fan Xpert was dropped from it. I do have the Lian Li L-Connect-3 running, as it seems to be required by the AIO cooler (GA II Trinity Performance 360), and I have the Asus Armoury Crate installed, too, as it seems to be needed to keep the Asus drivers up to date. I am trying to run without Fan Xpert. I don't run any RGB controls at all other than what's built into L-Connect-3 for the fancy pump LEDs. Shutting down some of those things might require tweaking startup settings, or, as you mentioned, uninstall.

So: No SpeedFan, Fan Control, or Aida64. Just CoreTemp and L-Connect-3. Fan Xpert, while looking nice, just doesn't seem to do its job properly, so I haven't run it recently. I suppose it still might have something lurking in the background, like the crappy asus_framework processes. I'd love to get rid of those.

Right now, I am running HWiNFO64 with only a system tray CPU usage display. I had all those Rainmeter measures going because I was trying to tweak this CPU and motherboard to be reliably overclocked, and it provided monitoring. I have given up on that.

 

[scastle]

Just to say I am not giving up yet. I've just installed Windows 11 and had to fight several driver issues along with that (what a PITA - it should have been called Windows 9.5, as it seems to be a pared-down version of 10). I still have one outstanding that causes Win 11 to turn off core isolation. I'm wondering now if this is tied to the HWiNFO64 issue, and the same driver problem is behind that. I'm thinking about using the driver verifier tool.

 

[Martin]

No, HWiNFO is not preventing that.

 

[scastle]

No, HWiNFO is not preventing that.

Didn't think it was. I'm wondering if the misbehaving driver is also causing the HWiNFO issue, since I see nobody else having this problem. I've been trying to identify old cruft and deleting drivers that are no longer needed, such as LSI 3ware and the like. It's a slog. I know the quick way would be a fresh install but that would remove a lot of things I'd really rather not lose.

 

[scastle]

An update. In the Win 11 update on Mar 11 [2025-03 Cumulative Update for Windows 11 Version 24H2 for x64-based Systems (KB5053598)], many drivers were updated, among them the ones that were involved in my recent BSODs while trying to enable core isolation. I am now running with core isolation enabled, which would not happen at all before. I have hopes for HWiNFO as well.

The MS doc for this update does not mention that 130 (at least) drivers were updated; it only mentions service stack components. Typical.