HWInfo64 taking over fancontrol sensor settings

[PP2012]

HWInfo is causing problems with fancontrol.

being overridden by external ??? i have no other control software · Issue #988 · Rem0o/FanControl.Releases

why is this software not trying to force primary control i have no other software to control my fans so why is it now with the latest update v121 that the software is allowing this

github.com

Rem0o implemented apply force in his/her app so it stops other apps taking over but fans wind up and down because headers are being messed with between fancontrol and hwinfo64.

I shutdown hwinfo64 and have not had fans/pump completely go to 0% or 100% in fancontrol.

being overridden by external ??? i have no other control software · Issue #988 · Rem0o/FanControl.Releases

why is this software not trying to force primary control i have no other software to control my fans so why is it now with the latest update v121 that the software is allowing this

github.com

Anything can be done about this so I can use both apps fancontrol and hwinfo64?

 

[Martin]

HWiNFO doesn't change fan speeds except very few systems when it's told to do so via its own Fan control
So this must be some sort of collision or non-synchronized access by the fan control software.
Which exact fans are affected by this issue? Fans connected to mainboard headers? If yes, which mainboard?

 

[PP2012]

HWiNFO doesn't change fan speeds except very few systems when it's told to do so via its own Fan control
So this must be some sort of collision or non-synchronized access by the fan control software.
Which exact fans are affected by this issue? Fans connected to mainboard headers? If yes, which mainboard?

yes, on the headers.
msi z590 A pro

 

[PP2012]

HWiNFO doesn't change fan speeds except very few systems when it's told to do so via its own Fan control
So this must be some sort of collision or non-synchronized access by the fan control software.
Which exact fans are affected by this issue? Fans connected to mainboard headers? If yes, which mainboard?

the other night all fans and pump were at 0 when i woke.

but here is an example of of all fans set at 1200rpm but 3 got taken over to 100%

 

[Martin]

This is most probably because the fan control software doesn't support synchronization with other clients accessing the eSIO controller.
Many other tools (including HWiNFO, AIDA64, CPU-Z/HWMonitor, SIV, ArgusMonitor, etc.) support global mutexes that ensure synchronized access. This allows them to access the eSIO concurrently and work together.

 

[PP2012]

This is most probably because the fan control software doesn't support synchronization with other clients accessing the eSIO controller.
Many other tools (including HWiNFO, AIDA64, CPU-Z/HWMonitor, SIV, ArgusMonitor, etc.) support global mutexes that ensure synchronized access. This allows them to access the eSIO concurrently and work together.

rem0o replied with this

Interesting, but FanControl uses the SuperIO implementation of https://github.com/LibreHardwareMonitor/LibreHardwareMonitor which, from what I can see, does use a global mutex everytime it reads or write to the chip.

Seen a lot of people using the FanControl + HWInfo combo because of the plugin, and there is no "systematic" problem when using both, so there is most likely an other variable, or a specific config at play in your case.

I do not know, but what I do know I can't use hwinfo64 any more, it does something with my fans with fancontrol if hwinfo64 is running.

Example that happens "tested just now": Just fancontrol running, I shut it down, my fans jump to 100% as expected. If i have fancontrol running and hwinfo64 running too, if I shutdown fancontrol, all my fans stop. hwinfo is interfering some how and I don't know how or why.

 

[Martin]

Yes, I can see that LibreHardwareMonitorLib is using the mutex. So unless FanControl is using direct methods to access the eSIO (e.g. ReadByte, WriteByte) which are not protected by the mutex, synchronization should not be the issue.
HWiNFO doesn't perform any changes to eSIO settings nor have any fan control methods implemented, so this problem must be something indirect.
You say that when you have HWiNFO running and close FanControl, the fans stop. So I'd rather look at what FanControl does upon closing, perhaps check if/how the RestoreDefaultFanControl method is called.
I'd also test the following scenarios - start HWiNFO first, then FanControl, then close FanControl. Then try to start FanControl first, then HWiNFO and close FanControl. See if you see the same behavior.

 

[PP2012]

Yes, I can see that LibreHardwareMonitorLib is using the mutex. So unless FanControl is using direct methods to access the eSIO (e.g. ReadByte, WriteByte) which are not protected by the mutex, synchronization should not be the issue.
HWiNFO doesn't perform any changes to eSIO settings nor have any fan control methods implemented, so this problem must be something indirect.
You say that when you have HWiNFO running and close FanControl, the fans stop. So I'd rather look at what FanControl does upon closing, perhaps check if/how the RestoreDefaultFanControl method is called.
I'd also test the following scenarios - start HWiNFO first, then FanControl, then close FanControl. Then try to start FanControl first, then HWiNFO and close FanControl. See if you see the same behavior.

Same behavior: "I'd also test the following scenarios - start HWiNFO first, then FanControl, then close FanControl. Then try to start FanControl first, then HWiNFO and close FanControl. See if you see the same behavior."

 

[PP2012]

Yup all screwy, the ? mark means another source took over and its hwinfo.

 

[Spiritreader]

Yes, I can see that LibreHardwareMonitorLib is using the mutex. So unless FanControl is using direct methods to access the eSIO (e.g. ReadByte, WriteByte) which are not protected by the mutex, synchronization should not be the issue.
HWiNFO doesn't perform any changes to eSIO settings nor have any fan control methods implemented, so this problem must be something indirect.
You say that when you have HWiNFO running and close FanControl, the fans stop. So I'd rather look at what FanControl does upon closing, perhaps check if/how the RestoreDefaultFanControl method is called.
I'd also test the following scenarios - start HWiNFO first, then FanControl, then close FanControl. Then try to start FanControl first, then HWiNFO and close FanControl. See if you see the same behavior.

First of all: Thanks Martin for responding and even showing interest in this issue at all, because it is quite obscure and only shows up for a small portion of users.
To clarify: I'm not affiliated with FanControl but am following the issue thread on github.

I have observed LHM clashing with other hardware monitoring tools in the past intermittently, but I never observed HWInfo clashing with others.

The problem PP2012 describes is something that I was able to observe on my system as well (but was fixed for me by updating both HWInfo64 and FanControl, or by magic I don't understand).
So from my perspective the issue is not clear-cut.

When I had the issue, yes, the start order of FanControl and HWInfo64 did matter in my case.
When HWInfo64 was started after FanControl, it would cause issues with FanControl's ability to, well, control fans.
HWInfo64 would then also start displaying a lot of new sensors on my NCT6687D which were garbled/incorrect (have readings of 0).

Also to address PP2012/resudroid: I have noticed that you seem to be a bit pushy in terms of communication with developers of both FanControl and HWI. Please note that all of them provide voluntary support for software you can use for free, and the issue you're having is most likely very difficult to debug / determine its origin unless it was clearly reproducible by everyone (which it sadly is not). As such, please be patient and as descriptive as possible if you want any chance of this getting resolved. Thank you!

 

[Martin]

Thanks for your input. Your comment about appearing of new garbled sensors in HWiNFO when starting it after FanControl might point to some issue in LHM.
I checked the LHM code and (besides finding some areas not not protected by the mutex) I also see that it performs some sort of initialization of the eSIO hardware monitor by enabling additional voltage monitors. This is something HWiNFO doesn't do and it keeps the original configuration as set by the system BIOS. This could be one problem.
Another interesting piece is the RestoreDefaultFanControl method which might be the culprit to what you observe after closing FanControl.
So, I believe the problem is not in HWiNFO, but just some coincidence revealing a problem in LHM or FanControl.
Sorry for not providing a deeper insight, but I don't feel responsible for this issue, hence cannot afford spending more time on a deeper analysis of FanControl or LHM.
Moreover, HWiNFO is used by a lot more users than FanControl and none of them reported a similar issue running it alone. If the problem would be here, it would show up also without using other tools and much sooner.

 

[Spiritreader]

Oh yes absolutely, from what I observed I didn't think of it as a HWI problem either and assumed LHM caused the collision. Just wanted to chime in and give some context as this thread was linked in the github issue.

Thank you for your input and insight nonetheless, cheers!

 

[PP2012]

Sorry guys, its just eating me up. I am going to make a OS backup and reinstall when I can. That way if it still does it i can revert my OS. I'll report back in a few days.

 

[UsernameCencoredKappa]

Came here to say that I`m having very similar issue with HWiNFO64 Pro, latest non-beta release. I have reinstalled Windows (for other reasons), tried running PC without apps like ARMOURY and MSI CENTER etc., updated BIOS multiple times..

The issue arise on motherboard MSI X570S Carbon Max WiFi.

Not only FanControl clashes with this software but this software bugs out after sleep mode (which I use a lot since electricity prices). After sleep the software updates only like once every minute or so, sensor values are stuck to the same ones and doesnt change. Also opening software and hitting reset sensor min/max values makes the program hang for a minute or even more - not responding, goes white.

Im pretty sure its something to do with this particular motherboard I use and it aint cool. Literally. I completely understand you cant possibly look into every hardware and get it tested, but would be nice to fix it for us MSI users. When I was on Gigabyte X470 board it worked without any issues.

 

[Martin]

It's interesting that so far all users that reported these issues have the Nuvoton NCT6687D. This chip users a different protocol than most usual SIO chips, this one is eSIO.
So I believe there's either some problem of concurrent access to the eSIO or something that does LHM do to configure the chip (which I described above).
It's also worth noting that no users reported issues with the eSIO when running HWiNFO with other monitoring tools like AIDA64, HWMonitor, SIV, ArgusMonitor, etc.

 

[UsernameCencoredKappa]

Yes but the issue with NCT6687D happen even when no other monitoring or control apps are running (all disabled on startup or not installed at all).

I have checked stuff using portable version of LHM and when running it after sleep, the Motherboard section in device tree is just empty, NCT6687D does not show up at all, including all its sensors. I need to restart the LHM instance 10 times and maybe, just maybe 1 time of 10 it will show my mobo and sensors. And a lot of people reporting similar issues with NCT6687D chip on different forums and software solutions support pages.

HWINFO just straigh up freezes to death after sleep. Didnt notice it before because I only used shared memory support for stream deck. But now when I open the app itself, it freezes and even the timer at the bottom of sensor window is stuck. xD

 

[Martin]

That looks like some issue with initialization of the eSIO during resume, which should be done by the BIOS. The BIOS is needs to restore a lot of settings during resume and it's quite common that they omit something. So this issue with accessing the sensors after resume should be reported to MSI.