Fan Control breaking some HWiNFO64 sensor readings

[321MBT]

Hi,

Over the past week or so, I have been experiencing an issue where Fan Control breaks some HWiNFO64 sensor readings. I'm unsure if I should report this issue to HWiNFO64 or Fan Control, so I posted this at HWiNFO64 forum because it's the affected software (link), and I'm CC'ing the report here.

Please let me know if this has been reported previously, if I can provide assistance, and whether a fix is in the works.

Issue:

• When HWiNFO64 is running, and Fan Control starts, some HWiNFO64 voltage and fan speed sensors stop working.
• This occurs if I have HWiNFO64 and Fan Control set to auto-start or if I manually start them after logging in.
• The only way I can fix this issue is by starting a first instance of HWiNFO64 and Fan Control, killing both, and then restarting them.
• I looked at the log files for HWiNFO64 and Fan Control, but they're empty after allowing Fan Control to break HWiNFO64 sensor readings. The system Event View didn't show any relevant errors or warnings.

Fan Control setup:

• I don't use Fan Control's native sensor readings. Instead, I use the HWiNFO64 plugin for Fan Control and HWiNFO64 Gadet reporting to send HWiNFO's sensor readings to Fan Control.

My System Specs:

• HWiNFO64 Pro v8.17-5615
• Fan Control v2.09 (NET 8)
• Windows 11 Pro 23H2 (build 22631.4602)
• Gigabyte Z690 AERO G DDR 4 (mobo)
• Radion RX 580 (dGPU)

Temp Fix:

1. I created two batch files to kill HWiNFO64 and Fan Control, restart them in order, and finally kill and restart Explorer.exe.
2. Refer to the comments in the primary batch file, "ReLaunch HWiNFO64 and Fan Control.bat".

Detailed Explanation:

This script silently calls ReStarting_HWiNFO64_FanControl.bat, which:

• (1) Kills the running Fan Control process
• (2) Waits for 1 second
• (3) Kills the running HWiNFO64 process[*]
• (4) Waits for 1 second
• (5) Starts HWiNFO64
• (6) Waits for 2 seconds
• (7) Starts Fan Control
• (8) Waits for 10 seconds
• (9) Kills Explorer.exe (remove the prior instance of System Tray icons for HWiNFO64 and Fan Control)
• (10) Starts Explorer.exe

[*] This must occur after killing Fan Control if the HWiNFO64 Gadget and HWiNFO64 plugin are used for Fan Control's sensor readings. Otherwise, Fan Control will get stuck in a loop, and you'll have to kill the Fan Control process manually.

Alternate Solution:

If you're experiencing this issue upon login and don't want to use these scripts:

• (1) Enable the HWiNFO64 setting "Auto Start"; do not change the default 5-second delay in Task Scheduler
• (2) Enable the Fan Control setting "Start at user log on"; set the delay to at least 10 seconds
• (3) Manually exit Fan Control after it loads its System Tray icon
• (4) Manually exit HWiNFO64
• (5) Manully start HWiNFO64
• (6) Manually start Fan Control
• (7) Run the mouse cursor over the System Tray icons or restart Explorer.exe to remove the prior instance of System Tray icons.

Running the batch files:

1. I attached these two batch files to this post with an appended text file extension (e.g., ".txt"). To run the files, remove the appended .txt extension.
2. Alternatively, I shared the code below to create your batch files using copy/paste.

CODE:

ReLaunch_HWiNFO64_FanControl.bat

@echo off

Title ReLaunch HWiNFO64 and Fan Control

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::
:: HWiNFO64 and Fan Control Launcher
:: 
:: Description: 
::	Silently auto start HWiNFO64 and Fan Control with elevated privileges (Admin) at login using Task Scheduler 
::
:: Motivation: 
::	Prevent Fan Control from breaking some of HWiNFO64's sensors when Fan Control starts. 
::
:: Warning: 
::	Use at your own risk. I still need to add error checking, IF statements, and other improvements.
::
:: Operation:
:: 		(1) Edit directory locations to match your system.
::		(2) Place  this batch file ("ReLaunch_HWiNFO64_FanControl.bat" and "ReStarting_HWiNFO64_FanControl.bat" into
::			the same directory; e.g., %USERPROFILE%/Documents/your_custom_folder/
::		(3) Use Task Scheduler to run this file at user login with a 15-second delay
::		(4) Configure the task to run with the highest privileges to avoid UAC interaction
::		(5) Enable the HWiNFO64 setting "Auto Start"; do not change the default 5-second delay in Task Scheduler 
::		(6) Enable the Fan Control setting "Start at user log on"; set the delay to 10 seconds
::
:: Explanation: 
::		This script silently calls ReStarting_HWiNFO64_FanControl.bat, which:
::			(1) Kills the running Fan Control process
::			(2) Waits fo 1 second
::			(3) Kills the running HWiNFO64 process (this must occur **after** killing Fan Control!)
::			(4) Waits for 1 second
::			(5) Starts HWiNFO64
::			(6) Waits for 2 seconds
::			(7) Starts Fan Control
::			(8) Waits for 10 seconds
::			(9) Kills Explorer.exe (to remove prior the instance task icons for HWiNFO64 and Fan Control)
::			(10) Starts Explorer.exe
:: 
:: Alternate Solution:
::		If you're experiencing this issue upon login and don't want to use these scripts:
::			(1) Enable the HWiNFO64 setting "Auto Start"; do not change the default 5-second delay in Task Scheduler 
::			(2) Enable the Fan Control setting "Start at user log on"; set the delay to at least 10 seconds
::			(3) Manually exit Fan Control after it loads its System Tray icon
::			(4) Manually exit HWiNFO64 after it loads its System Tray icon
::			(5) Manually start HWiNFO64
::			(6) Manually start Fan Control
::			(7) Run the mouse cursor over the System Tray icons or restart Explorer.exe to remove the prior instance of System Tray icons.       
::
:: NOTES:
::		(1) This is a rough solution to a recent issue where Fan Control kills some HWiNFO64 voltage and fan speed sensors. 
::			E.g., Vcore, DRAM voltage, CPU VCCIN_AUX voltage, CPU fan speed, System 1-3 fan speeds, and CPU_OPT speed.
::		(2) Reproducible: 
::				(A) Default HWiNFO64 installation with Task Scheduler auto starting HWiNFO64_launcher at login.
::				(B) Default Fan Control portable auto start with at least a 10-second delay (so it starts after HWiNFO64 is running).
::				(C) Some HWiNFO64 sensors stop reporting once FanControl starts.
::		(3) I have been experiencing this issue since updating to the following software versions:
::				HWiNFO64 Pro v8.17-5617
::				Fan Control v2.09 (NET 8)
::		(4) OS & Hardware: 
::				Windows 11 Pro 23H2 22631.4602
::				Gigabyte Z690 AERO G DDR4
::				Radion RX 580
::		(5) My HWiNFO64 configuration:
::				- Enable reporting to Gadget 
::		(6) My Fan Control configuration:
::				- Install HWiNFO64 plugin
::				- Exclusive use of HWiNFO64 sensors via Gadget and HWiNFO64 plugin; native Fan Control sensor sources are not used.
::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
CLS
ECHO.
ECHO.
ECHO *********************************************************
ECHO.
ECHO Restarting HWiNFO64, Fan Control, and Windows Explorer. 
ECHO.
ECHO.
ECHO Please wait . . .
ECHO.
ECHO *********************************************************

START /B CMD /C CALL "%USERPROFILE%\Documents\PC\!Startup_HWiNFO64_FanControl\ReStarting_HWiNFO64_FanControl.bat" >NUL 2>&1
exit

ReStarting_HWiNFO64_FanControl.bat

@ECHO OFF 

Title ReStarting HWiNFO64 and Fan Control

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::
::    --> DO NOT DIRECTLY RUN THIS SCRIPT <--
::
::    ---> LAUNCH THIS SCRIPT BY RUNNING ReLaunch_HWiNFO64_FanControl.bat <---
::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

taskkill /f /im FanControl.exe > nul
ping -n 2 127.0.0.1 > nul
taskkill /f /im HWiNFO64.exe > nul
ping -n 2 127.0.0.1 > nul

start "" /d "%PROGRAMFILES%\HWiNFO64\" "%PROGRAMFILES%\HWiNFO64\HWiNFO64Launcher.exe"
ping -n 3 127.0.0.1 > nul
start %USERPROFILE%\Documents\PC\Portable_software\FanControl\FanControl_app\FanControl.exe
ping -n 11 127.0.0.1 > nul
taskkill /f /im explorer.exe > nul && start explorer.exe >nul
exit

[321MBT]

Here is a screenshot of the broken sensor readings after Fan Control starts:

[Rem0o]

Hi,

Send a screenshot of the sources you got enabled in FanControl. There may be a lock issue for the ITE chip access.

If you untick the motherboard source in FanControl, same issue?

I don't think this has something to do with the plugin. The plugin reads the Windows Registry to get the HWInfo data. There is no direct contact between the two. HWInfo writes its data to the registry, FanControl reads the registry. I don't see how the plugin/fancontrol could "break" HWInfo this way.

[321MBT]

Hi,

Thanks for your prompt reply.

This issue started within the past two weeks after I updated Fan Control to v2.09 and HWiNFO64 to v8.17-5615, but because correlation does not imply causation, and I'm not sure exactly when it started, I can't say for sure if either software update is the culprit.

It is very odd because both apps must start and then be restarted to make HWiNFO64 work as expected. If I don't run Fan Control, HWiNFO64 works. It's only when I run Fan Control that some HWiNFO64 sensors break.

Results:

1. With the mobo source unticked, the issue doesn't happen.
2. Disabling the motherboard source throws up many errors, and I lose all but one of my controls, but it does resolve the issue.
3. However, there must be a better solution than disabling the mobo source because it breaks my Fan Control configuration.
4. Please take a look at the screenshots at the end of this message.

Martin from HWiNFO64 thinks it may be related to LWM in Fan Control:

This should be definitely reported to Fan Control.
AFAIK it's based on LibreHardwareMonitor which was affected by problems working with any other software. Some of those issues should be resolved in LHM but not sure if Fan Control is using the latest LHM version.

Current sources:

Errors after unticking mobo source:

Controls before breaking my config by disabling the mobo source:

Controls after breaking my config by disabling the mobo source:

Controls after reenabling the mobo source:

[321MBT]

PSA to anyone reading:

DO NOT untick the mobo source if you don't want to break your Fan Control config! Otherwise, make sure you have a current backup of your Fan Control folder before editing the sources so you can drop the backup in once you break the current config.

[Fr0stX76]

Disabling the MB sensor was a troubleshooting step, not a proposed solution.

You should run LibraHardwareMonitor without FC. The issue might be, as Rémi posted, an ITE chip access clash between LHM and HWinfo64. If it happens with LHM, then it should be reported there. It could be due to a change they introduced in a recent build. FC does not interact directly with the hardware. This is done thru LHM dll (or some of the plugins), which gets updated in FC thru the updates.

https://github.com/LibreHardwareMonitor/LibreHardwareMonitor

It has nothing to do with HWinfo plugin.

[321MBT]

Thanks for your insights.

However, this does seem like a FC issue because FC is the software packaging LHM. So while I agree it's wise to test LHM directly to see if it's the problem, which I will do tomorrow, the primary issue, if LHM is the problem, is that FC is shipping something breaking HWiNFO64 sensors only when FC starts (calls LHM I guess).

If it's LHM, then it seems LHM was probably updated in FC v2.09, which then started this issue on my system. Otherwise, I wouldn't have seen this issue because it only recently started and I recently updated to v2.09.

I am aware Rem0o didn't intend disabling the mobo as a fix. But Rem0o, and to be frank, you, seem to be incorrectly dismissing this issue without much consideration.

I didn't create this report in the HWinfo plugin git, I created it in the FC one, and Rem0o moved it here last night.

[321MBT]

If LHM is the problem:

1. It's on LHM to fix it, and FC to update to the new LHM so it stops breaking some of HWiNFO64's sensors.
2. FC might want to push a new update rolling back LHM to the version used in FC v2.08.
3. I'd bet FC v2.09 (via. LHM) has broken other people's HWiNFO64 sensors.
4. I'd also bet FC v2.09 has affected their FC operation if they use HWiNFO64 for sensor readings in FC like I do, forgoing FC's native sensor readings.

[Rem0o]

Did you use a prior version of FanControl with your build before with this same motherboard/setup without an issue?
Which version?

[Rem0o]

The only recent change I can spot which involve IT87952E is the change from reading 6 to 10 voltage registers.
Here: LibreHardwareMonitor/LibreHardwareMonitor@fce2059

However the motherboards added to require this change only read "9" registers, so I don't know why 10 was set

Looking at https://github.com/torvalds/linux/blob/aef25be35d23ec768eed08bfcf7ca3cf9685bc28/drivers/hwmon/it87.c#L255, it seems like the 10th register isn't 0x20 + 10, but there is an offset from 0x28 to 0x2F, which LHM blindly +1 his way through the registers from 0x20.

[Rem0o]

I compiled a quick version of LHM that uses the proper voltage registers. Use either the .NET 8 or normal (4.8) version depending on your version of FanControl. Make sure to rename the dll to only "LibrehardwareMonitorLib.dll" depending on which one you take from the zip. Copy it over your fancontrol installation folder.

LibreHardwareMonitorLib.zip

[321MBT]

Did you use a prior version of FanControl with your build before with this same motherboard/setup without an issue? Which version?

Yes:

1. I have been using the exact same hardware since I built my system in early 2023, the same time I started using Fan Control.
2. v2.09 is the only version that has caused this issue.
3. I just tested v2.08, and it's working perfectly with HWiNFO64. No problems at all.

I compiled a quick version of LHM that uses the proper voltage registers. Use either the .NET 8 or normal (4.8) version depending on your version of FanControl. Make sure to rename the dll to only "LibrehardwareMonitorLib.dll" depending on which one you take from the zip. Copy it over your fancontrol installation folder.

LibreHardwareMonitorLib.zip

Thanks! But this breaks Fan Control and conflicts with HWiNFO64. Please take a look at the screenshots and FC log file below.

I tested many different configurations:

• Each one using FC v2.09 or LHM >v0.9.3.0 either broke FC or has the same issue I'm reporting
• I also tested FC v2.09 NET 4.8 with LHM v0.9.5.0 NET 4.72, and it has the same issue as I'm reporting for standard FC v2.09. Please take a look at this message for more info.

FC v2.09

1. FC v2.09 + LHM 0.9.4.0 as shipped with FC v2.09 = This issue I'm reporting. LHM breaks HWiNFO64 upon the first start of FC but works after killing & restarting both.
2. FC v2.09 + LHM 0.9.3.0 as shipped with FC v2.08 = Broken; FC can't load due to different errors.
3. FC v2.09 + LHM 0.9.4.0 with fixed voltage registers = Broken; FC can't start because of a conflict with HWiNFO64, and it breaks FC's controls, like when I disabled the mobo in FC settings. Refer to the screenshots and log.txt, below.

FC v2.08

1. FC v2.08 + LHM 0.9.3.0 as shipped with FC v2.08 = Working as expected and no issues to report.
2. FC v2.08 + LHM 0.9.4.0 as shipped with FC v2.09 = This issue I'm reporting. LHM breaks HWiNFO64 upon the first start of FC but works after killing & restarting both.
3. FC v2.08 + LHM 0.9.4.0 with fixed voltage registers = Broken; FC can't start because of a conflict with HWiNFO64, and it breaks FC's controls, like when I disabled the mobo in FC settings.

For now, until a fix is pushed by LHM/FC:

• The easiest solution is to use v2.08, which has LHM v0.9.3.0.

If users experiencing this problem must run FC v2.09:

1. The best solution is running my scripts above.
2. The second best solution is manually restarting HWiNFO64, FC, and explorer.exe, as I described, but that is a PITA if using the strict UAC setting.

Error message and log.txt when running FC v2.09 with LHM v0.9.4.0 voltage registers fix build you shared:

LOG.TXT

18/12/2024 1:42:37 pm: Open - System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Win32.SystemEvents, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. The system cannot find the file specified.
File name: 'Microsoft.Win32.SystemEvents, Version=9.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
   at LibreHardwareMonitor.Hardware.Motherboard.Lpc.IT87XX..ctor(Chip chip, UInt16 address, UInt16 gpioAddress, Byte version, Motherboard motherboard, IGigabyteController gigabyteController)
   at LibreHardwareMonitor.Hardware.Motherboard.Lpc.LpcIO.DetectIT87(LpcPort port, Motherboard motherboard)
   at LibreHardwareMonitor.Hardware.Motherboard.Lpc.LpcIO.Detect(Motherboard motherboard)
   at LibreHardwareMonitor.Hardware.Motherboard.Lpc.LpcIO..ctor(Motherboard motherboard)
   at LibreHardwareMonitor.Hardware.Motherboard.Motherboard..ctor(SMBios smBios, ISettings settings)
   at LibreHardwareMonitor.Hardware.Motherboard.MotherboardGroup..ctor(SMBios smbios, ISettings settings)
   at LibreHardwareMonitor.Hardware.Computer.AddGroups()
   at LibreHardwareMonitor.Hardware.Computer.Open()
   at FanControl.Domain.BackendProviders.LHM.LHMBackendProvider.Open()

[321MBT]

@Rem0o

I will create a bug report at LHM in the coming days unless you can better describe the issue and would prefer to create it yourself. In either case, I will note your comments about IT87952E and the voltage registers.

[321MBT]

@Rem0o

The current nightly LHM v0.9.5.0 has the same problem as v0.9.4.0 (the shipped version, not what you shared above).

1. I just tested FC v2.09 NET 4.8 with standard LHM v0.9.4.0; as expected, it failed the same way as FC v2.09 NET 8.
2. I also tested FC v2.09 NET 4.8 with the current nightly LHM v0.9.5.0 NET 4.72, and it has the same issues as FC v2.09 NET 8 with the standard LHM v0.9.4.0 NET 8.

[Rem0o]

@321MBT
I forgot to include the Microsoft.Win32.SystemEvents.dll for the .NET8 build, sorry about that, hence the errors.

Try the .net 4.8 ( non-net8) LHMLib I compiled with FanControl V209 .NET4.8