Frequent errors requiring sensor refresh

[trowieuk]

Started on the 20th, either after a fancontrol update or hwinfo update but every few hours it throws errors.

Log attached.

[Rem0o]

No log attached

[trowieuk]

log_1.txt
apologies.

[Rem0o]

FanControl.HWInfo throws an error because there is a duplicate sensor from HWInfo.

[trowieuk]

FanControl.HWInfo throws an error because there is a duplicate sensor from HWInfo.

anyway to see which one? I haven't changed anything in HWInfo just did the last update...

[Fr0stX76]

I think its failing to report.

Any RGB software running? https://www.hwinfo.com/forum/threads/ram-detection-lost-occasionally.8657/

[trowieuk]

I think its failing to report.

Any RGB software running? https://www.hwinfo.com/forum/threads/ram-detection-lost-occasionally.8657/

No RGB software other than ones bundled with it but turned off, razer and icue for example.

[marceloavf]

Happens to me too everytime it startup with windows, even increasing the delay at user logon
log_1.txt

[ronny130286]

I have the same "issus", after xx minute i get the messager that der HwInfo senosr are missing.
If i refreshed the data manually (ctrl+r), the sensor data are avalible, but fev minutes later the same issus are back.

My log:

29.12.2023 19:02:10: HWInfo sensor failed momentarily during operation: HWInfo/DDR5 DIMM [#1] (BANK 0/Controller0-DIMM1)/SPD Hub Temperatur/°C - Missing
29.12.2023 19:02:10: Unhandled exception in FanControl v175.0.0.0
29.12.2023 19:02:10: System.Exception: HWInfo sensors failed: HWInfo/DDR5 DIMM [#1] (BANK 0/Controller0-DIMM1)/SPD Hub Temperatur/°C
   at FanControl.HWInfo.HWInfoPlugin.Update()
   at FanControl.Domain.BackendProviders.Plugin.PluginBackendProvider.Update() in C:\Users\Remi\source\repos\FanControl\FanControl.Library\Domain\BackendProviders\Plugin\PluginBackendProvider.cs:line 71
   at FanControl.Domain.ComputerAccessLayer.Update() in C:\Users\Remi\source\repos\FanControl\FanControl.Library\Domain\ComputerAccessLayer.cs:line 221
   at FanControl.Domain.ApplicationClock.DoActions() in C:\Users\Remi\source\repos\FanControl\FanControl.Library\Domain\ApplicationClock.cs:line 66
--- End of stack trace from previous locaation ---
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)

EDIT:
I found a fix: use hwinfo v7.66 and the problem dont exists ;)

[Fr0stX76]

Ok I think I found the issue, since I just had the same happen to me during an OCCT memory test.

To compensate for a sensor flaw of DDR5, Martin of HWinfo64 removed some temparatur values from being reported (see here for details ). This change was added to 4.68, so indeed rolling back to a previous buil will fix the issue. The problem with this is that you will now be stuck on that build until something gets fixed

In a nutshell, once your DIMM hit 47.75c, the sensor will go grey in HWinfo64, which means it is now "dormant". This create a situation where it will not report to the FanControl HWinfoplugin until either the temp of the DIMM go over or under 47.75c again... Which can take more time than the timeout of the plugin. Thus, the error you are getting.

No clue how this can be fixed from a FanControl/ HWinfoplugin standpoint. Someone should report it to Martin of HWinfo64 and see what he can do.

@Rem0o , I thought when a sensor goes missing in HWinfo64plugin, that it would keep the last know value instead of reporting an error. I guess there is still a timeout period before you consider the sensor disabled.

log.txt

[Fr0stX76]

Nevermind, I found this on the plugin history "After 10 consecutive update with a missing sensor, it will throw as it did before"

I think the updates are of 1hz (1000ms), so I would assume if the sensor stopped reporting for over 10 seconds, it is considered disabled for FanControl and the error will pop-up

[trowieuk]

I have disabled hwinfo plugin and still getting hwinfo errors. also lianli plugin errors.
new log attatched.
log.txt

[Fr0stX76]

If your curves are based on hwinfoplugin sensors and you disable the plugin... Its expected you will have errors. Remove any curve based on a hwinfo sensor, close FanControl then delete the plugin dll. This should remove hwinfo errors.

As for the LianLi plugin, I don't use it, so can't say.

[marceloavf]

Ok I think I found the issue, since I just had the same happen to me during an OCCT memory test.

To compensate for a sensor flaw of DDR5, Martin of HWinfo64 removed some temparatur values from being reported (see here for details ). This change was added to 4.68, so indeed rolling back to a previous buil will fix the issue. The problem with this is that you will now be stuck on that build until something gets fixed

In a nutshell, once your DIMM hit 47.75c, the sensor will go grey in HWinfo64, which means it is now "dormant". This create a situation where it will not report to the FanControl HWinfoplugin until either the temp of the DIMM go over or under 47.75c again... Which can take more time than the timeout of the plugin. Thus, the error you are getting.

No clue how this can be fixed from a FanControl/ HWinfoplugin standpoint. Someone should report it to Martin of HWinfo64 and see what he can do.

@Rem0o , I thought when a sensor goes missing in HWinfo64plugin, that it would keep the last know value instead of reporting an error. I guess there is still a timeout period before you consider the sensor disabled.

log.txt

Nice found, I was seing that my PCH fan speed and sensor also are unrechable when stating, but even putting like a 2min delay for FanControl, it still happens.

[Fr0stX76]

@marceloavf I don't think adding a delay will solve anything.

The issue is in the lack of data being sent by Hwinfo for longer than allowed by the plugin HWinfo. I know why for the DDR5 memory (I was the one of the ones who pointed the DDR5 fluke to Martin on HWinfo forum), but for your chipset (PCH) it is not directly related to this change. But I would think it is something similar, as in the PCH sensors go down for longer than expected by the plugin.

EDIT see here: This is exacly what I'm talking about Link

[Rem0o]

@Rem0o , I thought when a sensor goes missing in HWinfo64plugin, that it would keep the last know value instead of reporting an error. I guess there is still a timeout period before you consider the sensor disabled.

Well after how long should it be considered a problem? 30 seconds? 60 seconds? 1 hour? The value is written in the Windows registry by HWInfo. The plugin will report a problem if the value in the registry is missing, as if HWInfo was closed or was no longer reporting that value at all, at which point whatever the last value was is not relevant/reliable.

[Fr0stX76]

@Rem0o, I'm not sure what to answer. My first thought is : Do you need a timeout at all once initial value has been received?

Past that, if the sensor goes dark, then reusing the last know value would be fine until the sensor comes back online (if). The system safety argument cannot be used since when this timeout happens, all fans either stop or go to minimum speed, which is arguably worst.

In the meantime, I just wrote to Martin to see if something can be done on the HWinfo side.

[Fr0stX76]

Ok update on this, I just found a workaround but it does involve a bit of work.

I created a custom sensor based on my RAM sensor (See here for how to create one):

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors\Custom\PCXXX\Temp1]
"Name"="DIMM1 "
"Value"=""DIMM1 Temp""

I then changed HWinfo gadget to report the custom sensor instead of the one from the DIMM (So only the custom one gets reported). This popped and error in FanControl but it was expected as I now had a new sensor (while the older one was deleted). I just added the new sensor to all associated graphs and stuff.

This fixed the sensor going offline issue. Of course if the original sensor my custom one is based on is missing when I start HWinfo, I will get an error message... But this is normal behavior.

EDIT: Martin accepted to change how registry entries are handled for gadgets, the next build of HWinfo should fix all those flukes without using custom sensors... See here

Lets wait and see.

[Fr0stX76]

Update on this, HWiNFO v7.69 Beta 5330 now does not delete the registry lines needed by the plugin, even when the sensor stop reporting. Instead the last know value keeps being reported. This should fix a lot of issues people had with the plugin., especiallly with slow to report sensors.

Obviously this will not fix cases where the sensor is not detected by HWinfo upon launching it.

[Rem0o]

Can I close this? @Fr0stX76 @trowieuk

[Fr0stX76]

@Rem0o as far as I'm concerned, yes. HWiNFO v7.69 Beta 5330 resolved all issues associated to loss of data sent by one of it's sensor.