Hi, I just purchased my second Intel motherboard and installed Intel Desktop Utilities. When I change the Temperature threshold in the "Options --> Set Sensor Threshold" button, the next time I boot the computer IDU resets to its default values and keeps popping up unwanted alerts. I don't like to disable any alerts, so is there any way to work this around and set threshold limits for good?
IDU has a "other/unknown temperature" sensor (that usually is around 30 degrees Celsius), but its default upper threshold is zero C (?). I've just upgraded to the 3.1.4.031a version and it didn't solve my proble.
My previous PC (that was purchased back in 2005) also had an Intel board and IDU used to have the same problem (not keeping threshold changes after a few booting), so I think this may be some sort of issue inherited from the early versions of IDU.
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.
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 - 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 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?
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...