rChaz

Just an update regarding the above; I subsequently noticed that after returning from a Hibernate state, the registry fix 2) doesn't seem to take effect, and so the 2 CPUs burn away again while idle - until a non-hibernate boot occurs. I gave 1) a try, but it didn't seem to work at all, so it looks like it'll be back to the older version of hal.dll. That doesn't really give me the warm & fuzzies, but at least my CPUs will cool....

I'm kind of surprised that the Rollup wouldn't be able to determine a SMP ACPI machine (mine has two processors - it's not a dual-core or hyperthreaded.) But if a SMP status actually can't be determined, I certainly understand why a reg key/boot.ini wouldn't be made to all machines. Sure would be nice to make a note of it for us poor minority that are adversely impacted without the reg or boot.ini mod. It's an easy fix only if the information is readily available; it took a lot of digging to find this solution. I consider it a mistake to not provide any notice in this situation, even with only a small percentage of systems impacted. SMP is a small percentage, but it's certainly not an unexpected configuration.

coldkiss, This issue also drove me nuts tracking down, but I found a good solution in an obscure reference posted on a German site mentioning this problem. They mostly suggested the hall.dll restore, but one poster mentioned the individual patch where MS originally updated the hal.dll - prior to the rollup (MS KB 835730). KB 835730 basically mentioned a symptom that a Win2k system using HyperThreading Technology (no mention specifically of multiprocessors) may experience the computer not correctly entering the C3 power-saving state when idle. It then listed the hotfix (new hal.dll - v5.0.2195.6988 vs the newer rollup v5.0.2195.7006). To take effect, the hotfix has to be manually activated with one of two options: 1) Add the /usepmtimer switch to the Windows 2000 boot line of boot.ini OR 2) add the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\HAL dword key named 14140000FFFFFFFF with a hex value of 00000010. I was skeptical, but figured I'd give it a shot before resorting to restoring the earlier hal.dll version - since who knows what other security or other useful changes may be in the latest hal.dll. I used the registry activation method rather than the boot.ini switch, then I rebooted and watched as the CPU temperature cooled to normal again. Anyway, use one of the hotfix activation methods mentioned in KB 835730 - it works! Microsoft probably just forgot to add the registry patch in the Rollup required for multiprocessor/hyperthreading systems and the newer hal.dll.