Uh.. This looks like a bug in the Intel RST driver - it just doesn't properly respond to SMART commands.
I know that you will certainly ask - how is it then possible that other tools work. The answer is that those tools most probably favor other methods to retrieve SMART information, while HWiNFO prioritizes a different order, which favors a certain method that I think is buggy in your Intel RST driver (v184.108.40.2064).
Can you please try to upgrade the Intel RST driver and let me know if that helped ?
I can only add a workaround that will ignore all (invalid) thresholds in case this situation is detected. But I'm still convinced that the true bug is in the RST driver - those drivers have a long history of tons of bugs.
I can reproduce this problem on one of my machines using Intel RST v220.127.116.117 and 2 drives in RAID.
This configuration requires that the same method (CSMI SAS) is used by both HWiNFO and CrystalDiskInfo for example. The result is that CrystalDiskInfo reads the same wrong thresholds too.
More precisely the problem is because:
- one asks the Intel RST driver to return SMART ATTRIBUTES (i.e. actual and worst values) and it returns SMART ATTRIBUTES
- one asks the Intel RST driver to return SMART THRESHOLDS and instead of SMART THRESHOLDS it returns SMART ATTRIBUTES !
This is definitively a bug in the old Intel RST versions.
So the only solution is that HWiNFO will ignore those thresholds:
It seems to concern only older versions, I'm not sure which one is the fixed. You can try other versions from the Intel site - on the left side is a list of other versions (11.x, 12.x).
Or you might get along with the proposed HWiNFO fix, which won't report the error anymore, but it won't report any errors because of the missing thresholds.
I already suggested you to try without RST. I believe the main requirement for RST is when you have RAID, but that's not your case.
So using the standard AHCI driver works well with HWiNFO and all SMART data is reported properly ?