remember the old xp win update cpu hog bug?

[Chrysalis]

It seems vista has the same bug that plagued XP for years which got fixed in early 2007. I have noticed when checking for windows updates or even windows defender updates trustedinstaller sits at 100% cpu for quite a while hogging cpu.

Anyone else noticed this?

On XP it was svchost that used to hog cpu.

[fizban2]

I have noticed when Vista is installing serveral patches it will peak to 100% every so often. The CPU utilization has always dropped though once the patched have been installed. The problem with XP is that it would not release the utilization that it had taken (ala the SVCHost) that is fixed in vista.

[Chrysalis]

The problem was this.

When checking for updates the cpu stayed at 100% for ages depending on how many patches are installed so on a machine that has office and lots of patches already installed it stayed at 100% for many minutes even on powerful machines, the cpu usage dropped after updates were installed so you are talking about a different bug.

After the bug was fixed cpu still went to 100% but only for a much shorter period of time maybe a a minute or 2 at the most and it no longer stays flatlined at 100%. The bug was even more serious for people who automatically check for updates since on every bootup they had 100% cpu for anything up to an hour depending on the power of the cpu.

The problem with vista is the exact same behaviour if checking for updates or installing updates the cpu goes to 100% and flatlines there for ages except instead of svchost.exe it is trustedinstaller.exe. It doesnt peak at 100% every so often (this is what it should do) it flatlines at 100%. I expect like the XP bug the problem only affects some machines and you are not affected.

[newsposter]

think of svchost.exe as a 'shell' that quite literally hosts the essential services running on the OS. It's why you don't explicitly see processes for things like automatic updates, DCOM, BITS, print spooler, dns/dhcp and about 30 others.

So yes, if you have a long-running process it will seem as though svchost.exe is to blame, but it's really the 'hosted' services it manages that are the problem. You need OS level debugging/management tools (www.sysinternls.com and prio.exe from prnwatch.com) to look at which of the 'hosted' services are really using the most system resources.

If in fact the update/download/patch process seem to be the problem, you still have to look further ID the root cause. Things like a trashed registry (software inventory and PnP inventory) can cause slow update process as the data needs to be collected, sent to MSFT, and recommended update info sent back to you. And you can see that there are loads of system calls to be made as well as network traffic to and from the nearest MSFT Update servers.

Remember that Task Manager is hardly a decent diagnostic tool. It presents just enough info for users to key in on the wrong things.

[Chrysalis]

Without wanting to be rude I know its windows update 100% I am not sure why this is even been debated. In Windows XP I know it shows up as svchost.exe (used by various services) but in windows vista windows update uses trusted installer.exe

What is a fact is its windows update causing the issue. Another fact is it was a recognised bug in windows XP that didnt affect everyone but the people it affected it was a big inconveniance but the bug was squashed early 2007 on windows XP.

What I am on about now is I am seeing the exact same symptons when checking for updates and installing updates the logical conclusion is that it is the same bug, I hope you understand what I am getting at now.

I am not debating what trustedinstaller is and isnt.

It is also not a case of cpu is high but rather it flatlines maxed for a long time and makes the pc appear its half frozen this is NOT normal.

As for trashed registry etc. this behaviour is 100% repeatable on clean installs.

If you have no idea what the bug was in XP these are the patches that fixed it.

WindowsUpdateAgent30-x86.exe

WindowsXP-KB927891-v3-x86-ENU.exe

My belief is the bug was present in vista and XP but only got fixed in XP.

Edited December 27, 2007 by Chrysalis