Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fan Control breaking some HWiNFO64 sensor readings #64

Open
321MBT opened this issue Dec 17, 2024 · 17 comments
Open

Fan Control breaking some HWiNFO64 sensor readings #64

321MBT opened this issue Dec 17, 2024 · 17 comments

Comments

@321MBT
Copy link

321MBT commented Dec 17, 2024

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
Copy link
Author

321MBT commented Dec 17, 2024

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

HWiNFO64 broken sensors - Copy

@Rem0o Rem0o transferred this issue from Rem0o/FanControl.Releases Dec 17, 2024
@Rem0o
Copy link
Owner

Rem0o commented Dec 17, 2024

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
Copy link
Author

321MBT commented Dec 17, 2024

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:
1 - Copy

Errors after unticking mobo source:
2 - Copy

Controls before breaking my config by disabling the mobo source:
3 - Copy

Controls after breaking my config by disabling the mobo source:
4 - Copy

Controls after reenabling the mobo source:
5 - Copy

@321MBT
Copy link
Author

321MBT commented Dec 17, 2024

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
Copy link

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
Copy link
Author

321MBT commented Dec 18, 2024

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
Copy link
Author

321MBT commented Dec 18, 2024

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
Copy link
Owner

Rem0o commented Dec 18, 2024

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

@Rem0o
Copy link
Owner

Rem0o commented Dec 18, 2024

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
Copy link
Owner

Rem0o commented Dec 18, 2024

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
Copy link
Author

321MBT commented Dec 18, 2024

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:

4 - Copy

2 - Copy

3 - Copy

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
Copy link
Author

321MBT commented Dec 18, 2024

@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
Copy link
Author

321MBT commented Dec 18, 2024

@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
Copy link
Owner

Rem0o commented Dec 18, 2024

@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

@321MBT
Copy link
Author

321MBT commented Dec 18, 2024

@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

Thanks.

I tried what you suggested and used V209 .NET4.8 with LHMLib v0.9.4.0 .NET4.8 that you complied for me. It breaks in the same way as using V209 .NET8 with the shipped LHMLib v0.9.4.0 .NET8

So, for now, I am using FC V208 .NET8 with the standard shipped LHMLib v0.9.3.0 .NET8. It's the most recent combo that works for me without restarting HWiNFO64 and FC after the first start.

Let me know if I can help by testing other builds.

@Rem0o
Copy link
Owner

Rem0o commented Dec 18, 2024

Is it only the readings under the ITE8689 in HWInfo that break? Or both ITE chips.

My only other idea would be arround this change::
LibreHardwareMonitor/LibreHardwareMonitor@d402b4a#diff-2e51595afea07c9604429033c4a41e9892b48de04f88f896eba94b779138860c

@321MBT
Copy link
Author

321MBT commented Dec 18, 2024

Is it only the readings under the ITE8689 in HWInfo that break? Or both ITE chips.

Just the first chip (ITE IT8689E) reading breaks, while ITE IT87952E isn't affected.

Here are both chips reading correctly with FC V208 and the standard shipped LHMLib 0.9.3.0:

v2 08_NET8_standard - Copy

Here's an example of both chips with either:

  1. FC V209 (.NET8) with standard shipped LHMLib 0.9.4.0 (.NET8); or,
  2. FC V209 (.NET4.8) with LHMLib 0.9.4.0 (.NET4.8) you custom complied for me to test

v2 09_NET4 8_w_compiled_LHMLibv0 9 4 0_ NET4 8_w_volt-registers-fix - Copy

My only other idea would be arround this change:: LibreHardwareMonitor/LibreHardwareMonitor@d402b4a#diff-2e51595afea07c9604429033c4a41e9892b48de04f88f896eba94b779138860c

Feel free to let me know if I can help in any way. I love Fan Control, so I'm happy to help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants