Just to add some more information: IDU version 3.1.4.031a also had some sort of conflict, since my PC running Win 7 64 was experiencing some audio dropouts due to high latency. When testing by disabling many services I figured out IDU was the responsible for the dropouts.
Hopefully Intel will correct this in the next versions.
Thank you.
Please let us know what service(s) you saw creating this "high latency". The actual monitoring of the HDD temperature is being performed by the FSCAppServ service, which has title "Intel® Desktop Boards Fan Speed Control Instrumentation Service"...
By the way, if you want to reset IDU's database (which should result in the sensors getting enumerated properly - and with the right upper threshold), do the following:
...Scott
Scott - I was unable to implement your recommended fix. All IDU-related processess stopped except "intelmain.exe" not found. I deleted Desktop Board in registry and rebooted. IDU still shows Other/Unknown Temperature Status as over threshold. I would appreciate any further advice. Thanks. Peter
IntelMain.exe will only be found it you have the GUI opened, so you can ignore this notification otherwise.
I tested this process on 32-bit Windows and presumed it would work on 64-bit Windows (barring path difference). I was able to reproduce the deletion rejection, however (I guess I should have tried it in the first place
). The "Heceta Sensors" and "QST Sensors" sub-keys are locked (I will have to have my developer investigate why this is). Regardless, for what you are attempting to do, this is not a problem; on these systems, it is the "Aux Sensors" and "FSC Sensors" sub-keys that we need deleted. Just delete them individually instead...
Oops, one of my developers just informed me that they were able to reproduce this issue and that it appears to be exclusively occurring in cases where RAID is enabled (does this jive with folks' findings?). It looks like it is a bug in our enumeration of drives within RAID arrays (code I wrote (sigh)). I will have to see whether we can squeeze this fix into our next release...
Hi Scott - I do not have RAID enabled. The common thread among folks who said they had the same problem was recent installation of a SSD. Regards. Peter
Hhmmm, SSDs do not typically include a thermal sensor and thus shouldn't be exposed. Was this an addition or a replacement?
Back to duda_ce's original report - What motherboard are you using? What HDDs were present? Was RAID enabled?
Hi Scott - I replaced my boot drive, a WDC WD1002Faex, with an Intel SSD 320 series . I kept the the WDC HD and am using it for my D drive. The IDU had been trouble free untill the SSD was installed. The first reboot after installation produced the first alarm and the "Other/unknown temperature" line appeared on the monitor just above the Hard Drive Temperature entry. I tried uninstall/reinstall several times but at each shutdown the threshold resets to 0 and on each reboot the alarm is activated. Regards. Peter
Ah, I see the issue. Because the SSD replaced the HDD in the SATA ordering, the entry used oiginally for the HDD got matched up against the SSD. Then, a new entry was created for the HDD. In fact, however, the first (original) entry should have been dropped from the list when the stack recognized that the SSDS did not have a temperature sensor. I will have to look into why this is...
Thanks a lot Scott and Peter.
In fact I have an SSD and a RAID array. A X25 40GB SSD as the boot drive in SATA2 (not RAID) and 2 x Seagate ST31000524AS in SATA 0 and 1 in a RAID 1 array. My motherboard is a DH67CL.
Regarding the high latency, how can I find out which service is causing the high latency, by simply disabling each one or is there any free software that helps us in this task?
Regards!
Hi, the alerts issue has been solved in newer versions of Intel Desktop Utilities, but the audio and video drop-outs due to high latency peaks still remain.
Thank you.
The newer versions of IDU don't present the wrong alerts anymore, but the audio and video drop-outs remain (less times, but still happen).
We're well aware of this issue (there are a number of threads that have complained about it 
) and are looking into it presently. In our investigation so far, it only seems to affect systems that utilize RAID. It has something to do with our support for extracting S.M.A.R.T. data from the HDDs/SSDs that are within these RAID arrays. Our S.M.A.R.T. monitoring is somehow slowing array responsiveness, causing audio decoding to glitch when buffers are exhausted (we've not seen it affect video but this is certainly within the realm of possibilities). You can either ignore the glitches or uninstall Intel(R) Desktop Utilities until we can make a fix available...
