HWINFO64 suddenly no CPU Temperature

Hi, Martin I have a little trouble with HWINFO, I re‑placed my fan E30307‑001 (12V x 0,2A = 2,4W) for Q9650 be‑cause I was not happy with re‑sult 68°C at full‑load, so I changed it with a Intel D99136‑001 (12V * 0,8A = 9,6W).
This fan cool well with 44°C at full load but the pro‑blem is speed is always at maximum 2850RPM, so he make lot of noise. So I had the idea to go in B.I.O.S to activate Asus Q-Fan Con‑trol "Optimal" and now at idle in Windows, he have 1000RPM at 31°C & 52°C at 1200RPM at full‑load 100%... With "Per‑formance" mode in Q-Fan, the fan run at 1000RPM at idle & 1600RPM at full‑load 100°C with 48°C...
  1. my D99136‑001 re‑sult
The pro‑blem is that after a re‑boot, when I'm log‑in in Windows, or wake‑up from sleep‑state, HWINFO alert me that the speed is under 0RPM (I setted Alert if < 500), in tray icon and in "Sensor status" main page. So be‑cause of that I open HWMONITOR, and in that pro‑gram, the speed is shown normally, after I close HWMONITOR, the RPM speed is shown again in HWINFO (tray icon & "Sensor Status" main page), I don't under‑stand, I had this kind of trouble with C.P.U temperature (read first post of this thread), but you said it is be‑cause that "Asus PC Probe 2" don't have syn‑chronization mechanism. Now, in this case I don't have an other monitoring tool running like "Asus PC probe 2" so why HWINFO have difficulties to read the C.P.U fan sensor ??? What should I do ? Can you help please ?
 
I don't know yet why this happens, I will need to know exactly what fan speed is reported by HWiNFO after the reboot/resume.
Does it mean that HWiNFO doesn't report the fan speed at all until you launch HWMonitor ?
Best would be to enable Debug Mode, catch the situation and then attach it here.
 
HWINFO after start from sleep‑state, don't de‑tect CPU Fan sensor, after launching HWMONITOR, I see that the fan sensor appear in HWMonitor, after closing it, the sensor work again in HWINFO...
I put a picture (as you can see the tray icon is 0 & CPU 0RPM) and in HWMonitor we have result...

Ok, I will make a de‑bug file...
 
So I have done this, activating debug file, closed HWINFO, open it again, then go in sleep mode, I wake‑up the P.C, HWINFO show this speed in tray‑icon 1000RPM, then 1600RPM, then 1500, then 0... I re‑ceive an alarm‑window from HWINFO... I wait 10 seconds, then I open HWMonitor (there CPU fan speed is shown), I close HWMonitor, then immediately HWINFO show CPU fan speed back... That is very strange behavior. I close HWINFO to get De‑bug file... Here it is...

P.S : I up‑dated HWINFO with last version 4.64, but after auto‑start, the pro‑cess is still "Below normal" in "Set priority" in task manager... It seem to me, that you said that you resolved this bug.

P.S : I don't think that is a pro‑blem with mother‑board or Asus Q-Fan con‑trol be‑cause I use it with the fan E30307-001, to see the temperature re‑sult, and I didn't have that bug... Now I have set "Asus Fan con‑trol" to "off", the fan work at full‑speed 2800RPM, I'm gonna test the sleep‑state & wake up to see if HWINFO have the 0RPM bug...

I tested with "Asus Q-Fan Control" "off" in B.I.O.S, after Windows go to sleep‑state & wake‑up the RPM does not fall to 0RPM...
 

Attachments

  • HWiNFO64.DBG
    694 KB · Views: 1
  • HWINFO.JPG
    HWINFO.JPG
    345.6 KB · Views: 2
Thanks for the additional information. I have a theory why it happens (BIOS doesn't properly set fan divisors after wake up), but I need one more test. Please try the following:
1. Close HWiNFO and all other fan monitoring tools
2. Do a suspend-resume sequence
3. Wait at least 10 seconds
3. Open HWiNFO with Debug Mode enabled and attach the new Debug File

Regarding the auto-start priority: I have also said that in order to have this working, you will need to first disable Auto Start, click OK and the open the Settings screen again and enable it.
 
I don't under‑stand what do you mean by "Do a suspend-resume sequence", what is that shud‑down and re‑start ?

I have done another test, after sleep‑state & wake up, HWINFO CPU FAN have 1600RPM, then 1300RPM, then 0RPM. If I close HWINFO and re‑start it, the CPU FAN RPM is back & cor‑rect... I tell you this just for your in‑formation...
As you said, I don't think it's coming from the B.I.O.S, I used Q-Fan con‑trol pre‑viously and didn't have that bug, may be the CPU fan wire is bad, or the FAN use to much Watt, I don't know... Without Q‑Fan no 0RPM bug... So for me the B.I.O.S is good...

I'm gonna close HWINFO and test HWMonitor, open it, then sleep mode, then wake up and see if HWMONITOR show 0RPM like HWINFO... I made it and yes HWMonitor have the 0RPM to... After closing it and re‑start the RPM is back...

Both have the problem is not HWINFO or HWMonitor... I don't what it is... How can I cor‑rect this pro‑blem ?
 
With "suspend-resume" I meant to put it into Sleep and then wake up. Please do the procedure above and attach a new Debug File.
 
OK, for these step
1. Close HWiNFO and all other fan monitoring tools
2. Do a suspend-resume sequence
3. Wait at least 10 seconds
4. Open HWiNFO with Debug Mode enabled and attach the new Debug File
But how long shoud I leave HWINFO started in point 4 ? To have the debug file, I need to close it, no ?

Why do you need a de‑bug file of HWINFO launch after 10 seconds ? I don't under‑stand. As I said before, if I re‑launch HWINFO after sleep‑mode the RPM is good, the bug ap‑pear in HWINFO & HWMONITOR only if they were started be‑fore sleep‑state, and after wake‑up...
 
It's enough to wait a few seconds in 4. and then close it. I need it in order to see at what exact raw value the fan speed has settled (this is only visible in the DBG file). It seems that after resume the fan speed gradually goes into an invalid range because the BIOS doesn't properly restore fan divisors. This is fixed during start of HWiNFO and HWMonitor, but after resume it seems it needs a certain delay to recognize the invalid state.
 
The De‑bug file is done (the temperature of CPU is 41°C at 25% usage be‑cause Steam down‑load a game up‑date & Avast Anti‑virus run in back‑ground to scan the files...).

I don't com‑pre‑hend why I have this 0RPM issue with "Asus Q-Fan con‑trol" with "Optimal" or "Per‑formance" setting with the Intel D99136 fan (12V x 0,8A = 9,6W), I used be‑fore Q-Fan with Intel Fan E30307-001 (12V x 0,2A = 2,4W) and I didn't had that trouble in HWINFO after sleep‑state, it's be‑cause of wattage ? It's the B.I.O.S or the fan is faulty ???

I also writed to Asus to ask sup‑port for this case... We shall see what they say...

I checked the 4-pin fan con‑nector on mother‑board and he is well in place...

You say that "This is fixed during start of HWiNFO and HWMonitor, but after re‑sume it seems it needs a certain delay to re‑co‑gnize the in‑valid state." but I let HWINFO works long time and the 0RPM value don't change to real one...
I made the test for 4m30s and no change at all, it re‑main at 0RPM, need to launch HWMONITOR or re‑launch HWINFO to get CPU fan RPM back... How can I cor‑rect this ??? Any idea ? I can't dis‑able the Q-Fan con‑trol, the D99136-001 make to much noise at con‑stant 2800RPM, it seem that I doesn't have in‑tegrated auto‑matic speed con‑trol like the E30307-001, so I really need Q-Fan for quietness...
 

Attachments

  • NEMZAG FAN PROBLEM 2 - HWiNFO64.DBG
    504.7 KB · Views: 1
  • HWINFO CPU FAN 0RPM FOUR MINUTE NO CHANGE.JPG
    HWINFO CPU FAN 0RPM FOUR MINUTE NO CHANGE.JPG
    363.4 KB · Views: 2
To explain it more precisely, the problem is as I already said - after resume the BIOS doesn't properly restore the fan divisor values, which leads into invalid readouts.
HWiNFO does check for such a condition during start and during resume too (because I have seen such problems in the past) and tries to correct it.
Now in your case the problem is that after resume the fan speed measurement works for a few seconds and then drops to the invalid values (counter overflow), which is not recognized by HWiNFO because it happens with a delay.
I think I can fix this, but one last question - can you estimate approximately how long does it take from the point when Windows starts to wake up to the point when the fan speed drops to 0 in HWiNFO ? Is that about 6 seconds ?
 
Martin said:
To explain it more precisely, the problem is as I already said - after resume the BIOS doesn't properly restore the fan divisor values, which leads into invalid readouts.
HWiNFO does check for such a condition during start and during resume too (because I have seen such problems in the past) and tries to correct it.
Now in your case the problem is that after resume the fan speed measurement works for a few seconds and then drops to the invalid values (counter overflow), which is not recognized by HWiNFO because it happens with a delay.

I com‑pre‑hend what you are saying about the BIOS but why I have this with Intel D99136‑001 fan & not with the Intel E30307‑001 fan ? This only occur with Q-Fan "On", with‑out Q-Fan no pro‑blem, the speed re‑main 2800RPM be‑fore & after sleep‑state...


Martin said:
I think I can fix this, but one last question - can you estimate approximately how long does it take from the point when Windows starts to wake up to the point when the fan speed drops to 0 in HWiNFO ? Is that about 6 seconds ?

After waking‑up, I ar‑rive in window 7 log‑in screen, after puting my pass‑word and en‑tering in desk‑top it take 7/8 seconds to RPM to drop from 1600 to 0...
 
Maybe the difference is that the previous fan dropped sooner to the invalid range, which was properly catched and fixed by HWiNFO. The new one need a larger tuning. I'll try to fix this in the next build.
 
Martin said:
Maybe the difference is that the previous fan dropped sooner to the invalid range, which was properly catched and fixed by HWiNFO. The new one need a larger tuning. I'll try to fix this in the next build.

Ok thank, but even HWMonitor had this same pro‑blem, it's really strange, so for me there is some‑thing wrong in the fan or in B.I.O.S with Q-Fan "On"... I can't be‑lieve that two dif‑ferent tools have the same error, how can dif‑ferent de‑velopers make the same omission in their code ?

F.Y.I, I closed HWINFO & I tested "Asus PC Probe 2, version 1.04.88" and this tool doesn't have the bug that HWMonitor & HWiNFO have, the CPU fan RPM is cor‑rect even after sleep‑state and doesn't drop to 0RPM after 7/8 seconds... So the BIOS work cor‑rectly and the fan to, if I be‑lieve what I read there... What have "Asus PC probe 2" more, that has not HWiNFO & HWMonitor ? Better Asus P5K-E (Winbond/Nuvoton W83627DHG) reading ???

I also down‑loaded for test "Asus PC Probe 2" last version "1.04.92" and with that one, after sleeping‑state CHA_FAN2 is at 0RPM for 7 seconds then get back... Really freaky... With 1.04.88 no pro‑blem...

Martin said:
Regarding the auto-start priority: I have also said that in order to have this working, you will need to first disable Auto Start, click OK and the open the Settings screen again and enable it.

You are right I changed the setting and now with HWiNFO auto‑start "Set priority" is at "Normal" in "Windows Task Manager", thank for that bug cor‑recting...

P.S : Still, the second tray icon bug that I re‑ported to you be‑fore in this thread, is still present & not patched...
 
What you saw with "Asus PC Probe 2" version "1.04.92" just confirms what I have already said.

I don't have a solution for the tray icon issue - it's not in my hands.
 
Martin said:
What you saw with "Asus PC Probe 2" version "1.04.92" just confirms what I have already said.

Yeah, but it is the Chassis_Fan_2 that have 0RPM, not CPU_Fan, that is really strange... But fortunately the Chassis_Fan_2 recover real RPM after six seconds... I re‑moved the 1.04.92 and re‑in‑stalled the 1.04.88...
 
Hi, Martin, I noticed a strange bug with HWiNFO64, with "Autostart" I have set "Show Wel‑come Screen & Pro‑gress"... At Windows 7 start, if I click "run" in Wel‑come window im‑mediately, the MSIafterburner pro‑cess & RivaTuner Statistics Server pro‑cess are in "Task Manager" but they don't ap‑pear in tray icon after some time, and if I run a D3D software, the O.S.D not work... If I wait to click HWiNFO64 "Run", then MSIAfterburner.exe & RTSS.exe launch normally... Can you cor‑rect that ???
 
This is a very strange bug and I'm not sure why it happens.
So you mean that MSI AB and the OSD first appear in the task bar, but later disappear ? Or they don't appear at all no matter how long you wait?
On the OSD you don't even get the values MSI AB/OSD own values, so nothing shows up there ?
 
Back
Top