![]() I assume this is the debug file you're talking about: I haven't actually cold booted the machine in a couple of months, so I can't honestly answer your cold boot question, but if you think it would help I can perform a cold boot? The behavior is slightly different though in that it added the low ball sensor, rather than swapping it, as HWiNFO64 does, so rather than losing the correct sensor reading, it's got a disconnected fan header showing up. A new sensor has appeared labeled FANIN1, and it's readings are strangely similar to the CPU OPT sensor in HWiNFO64. So, put the machine to sleep for several hours, and now after waking the system, it appears HWMonitor has likely run into whatever is tripping up HWiNFO64. I've gone ahead and set an alert for the fan to see if I can observe any sort of correlating activity in the system when the 0 readings occur and will post further if I observe any behavior that might be going on when this happens. I have put the computer to sleep for a few minutes, and after waking, both programs are still reporting consistent and reasonable fan speeds, however HWiNFO64 is no longer labeling "CPU OPT" as such, but rather as "System 2" So, I can also verify the fan is properly spinning with a simple visual inspection.Įxiting and reopening HWiNFO64 restores the fan RPM numbers to agreement between HWMonitor and HWiNFO64. It just so happens " CPU OPT" is a 3-pin persistent LED fan atop the chassis, and the LED display never scrambles on it, which is to say, the RPMs of the fan can be considered reasonably consistent, or else the persistent display would not be coherent. ![]() I went ahead and ran HWMonitor 1.40 and it's reporting reasonable RPM values for the fans it's showing. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |