HWInfo hammering hard drive

[Mexxxi]

Recently, I upgraded HWInfo from 4.14-1880 to 4.41-2260 and had to realize that the latter version (sensors only) accesses my external HDD every 500ms which is the graph update frequency I had set in the settings.

Apart from the fact that the constant head movement causes quite some extra heat and wear on the mechanics, it also significantly slowed down the drive. I do realize that 4.14 didn't support external drives and thus didn't have that issue. Still, shouldn't a temperature reading only require accessing the chips on the drive and not have any impact on the mechanics?

While I could easily go back to 4.14 it still begs the question, whether this version also heckles my internal hard drive like crazy. My HDD LED suggests that this is the case. To put some concrete numbers down, I tracked HWINfo's HDD access with Procmon and had to realize that it makes a whooping 100.000 registry requests per minute. That can't be good for system performance or the hard drive's life span. Is that really necessary and if so why? Until now, I was under the impression that the sensor values were directly read into memory.

Seeing this behavior, I also tested other tools, just to see if this behavior is normal. HWMonitor accesses the registry 20.000 times per minute and OpenHardwareMonitor 10.000 times. Granted, both programs show a whole lot less values, it still doesn't explain the constant read and write access of the registry if those values are read directly from the sensors.

Anyway, regarding the constant head movement of the external (and probably also internal) drive: Other tools such as Crystal Disk Info don't pester the hard drive like that. The latter just shows the temperature without setting the head in motion at all.

I would love to hear a clarification on HWInfo's behavior. In any case, thanks for that awesome program

 

[Martin]

HWiNFO only sends S.M.A.R.T. commands to a drive to query it's health status and temperature. These should be completed quickly and without excessive drive activity. If these commands cause such a hammering, the problem might be in the drivers realizing these commands. You should be able to avoid this by disabling monitoring of particular hard drives (right-click -> Disable Monitoring). You might also try to upgrade drive/controller drivers. Some Intel RST drivers are known to cause issues (lags or BSODs) when they are queried for drive status.

I'm wondering about those intensive registry accesses. This should not by directly caused by HWiNFO, it might be triggered by underlying drivers as well. Are you able to determine which registry keys are being accessed intensively? You might also try to disable particular sensors to see which one is causing it. If you determine this, please let me know.

 

[Mexxxi]

If these commands cause such a hammering, the problem might be in the drivers realizing these commands.

I'm using an Asus M5A97 R2.0 motherboard with an AMD SB950 SATA chipset. The drivers are a year old by now and I hadn't had any problems so far, but I updated them now. Since my machine is working right now, I have to wait a day for a reboot and see if the newer drivers do change that behavior.

I checked back with Crystal Disk Info and it seems that the hdd head moves whenever I switch to another hdd tab in the program and back to the external hdd like it initializes reading the sensors sends the head into a single motion. So it also causes these head movements with every sensor refresh, but it doesn't use auto-refresh by default and if you activate it, then the lowest value is 1 minute. May be HWInfo could offer different polling intervalls for different sensors? It makes sense polling S.M.A.R.T.-Data for hard drives much less often than say CPU temperatures or fan speeds.

You should be able to avoid this by disabling monitoring of particular hard drives (right-click -> Disable Monitoring).

That works nicely, but I actually want to track those sensors
Since also flash memory drives show up in HWInfo I'm wondering whether the constant head movements of my external HDD also indicates that read/write-cycles are being performed on the flash drive. Its LED at least is blinking at the intervall I set in HWINfo even though I don't even actively use the drive.

So I went ahead and tested it. I kept HWInfo running for 5 minutes and checked the written amount of data on the drive before and after running it with fsutil. According to the tool, no data was written in that time even though the flash drive's LED was going crazy. Same goes for the drive with the constantly moving head. No data was written or even read. I don't know how reliable fsutil is in this regard though, as it only tracks filesystem activity and might not be able to monitor other access types.

I'm wondering about those intensive registry accesses. This should not by directly caused by HWiNFO, it might be triggered by underlying drivers as well. Are you able to determine which registry keys are being accessed intensively? You might also try to disable particular sensors to see which one is causing it. If you determine this, please let me know.

I looked more into it. Out of the box, HWInfo triggers a constant amount of 2,700 registry events per sensor poll. This became very apparent once I set the delay to 5000ms. For comparison: all processes I usually use on my system on a normal day of work (including Firefox and Opera while downloading stuff) don't cause more than 10,000 system events per minute combined.

It seems that always the same registry values are being read (those for the graphics card). I'll append the procmon log (apologies for the size) to this post so you can actually see everything in full detail.

I went through all sensors disabling them one by one while monitoring registry access in procmon. Turns out that the adt7473 PWM-controller on my GTX260 caused 2000 of those events alone. After deactivating the sensor poll for it, system events went down to 550 per sensor poll.

Just for the fun of it, I also disabled monitoring for the entire GTX260 and the registry queries went down to only 120 per poll. Now, this is a number I can live with

Question is just what causes HWInfo to add 2600 of those system events just when monitoring this graphics card? The graphics driver perhaps, or implementation in HWInfo? I'm using driver version 337.88 which is the latest.

Just to make sure, I counter checked this behavior with HWMonitor. It caused about 400 system events per second, but I can't set the polling interval. It seems to be hard coded to poll sensors every 250ms which would equal 100 system events per poll including graphics card temperatures, voltage and fan speed. Unfortunately, it doesn't support deactivating sensors, so I can't determine how much of that traffic is actually spend on polling sensor data from the graphics card, but looking at the procmon log it seems that the system events are solely used for tracking the graphics card sensors.

OpenHardwareMonitor causes 170 system events per sensor poll for all sensors in my system including the graphics card with its voltages, temperatures, memory/shader/bus clock speeds, fan speed and load levels of different components. Luckily, it supports deactivating components, so I limited it to logging the graphics card only. Interestingly enough, it turns out that those 170 system events are solely used for monitoring the graphics card. Deactivating only monitoring for the latter causes OpenHardwareMonitor to use no registry queries at all, as someone would expect from such a tool.

So, I tracked registry usage of HWInfo with graphics card monitoring deactivated and realized that the only registry entries it then queried were those related to S.M.A.R.T. Once I also deactivated hard drive monitoring HWInfo stayed just as silent as the other tools. While the SMART-polls don't cause an exorbitant amount of registry stress, I'm still wondering why the registry would be accessed for this at all since those values can also be read from the BIOS or other non-registry-based environments. This is especially interesting since the keys that are being queried don't seem to have to do anything with SMART. For example, keys of Procmon are also being read during such a sensor poll and I wonder why.

Do you see a chance to bring down those thousands of registry queries per sensor update for graphics card sensors down to a more civil level?

 

[Martin]

HWiNFO (and I believe all other tools) use dedicated NVIDIA library/driver functions (NVAPI) to query the status of their GPUs.
I'm sure those excessive registry accesses are caused by those NVAPI queries, so I'm afraid there's not much I can do about that. It's a problem of their library.
But I wouldn't worry much about this, since I believe almost all such accesses are cached, thus should not cause a higher system load.

 

[Mexxxi]

Thank you for the clarification

The queries seem to be indeed cached as there seems to be no impact on the hard drive's performance.

Thanks again for HWInfo and your awesome dedication

 

[Martin]

You're welcome