I have a theory, but you can test it.
Svchosts are a kind of deception. They contain multiple
executables inside. Some genius did this, to make them harder
to debug. And usually, all the guilty parties (the ones that
go rogue), are kept in the same svchost. I'm convinced they
do this, just to piss us off.
In WinXP Pro, you can open a command prompt, and do
tasklist /svc
That shows running processes, as well as the contents
of a svchost container. My PID 1468 for example,
has about fifteen things in that svchost.
On WinXP Home, that command isn't available. Or so they
tell me. Instead, you can use Process Explorer, click on
a svchost (or hold your mouse over it), you can do Properties
then click the Services tab, and it'll show you a list of
items inside that svchost.
http://technet.microsoft.com/en-us/sysinternals/bb896653
The one I have my eye on, is this one. It checks, amongst
other things, the dependencies of all the potential
Windows Updates. Currently, it gets a little confused when
figuring out what to do about your copy of Internet Explorer.
And in the process, chews up a CPU core. It will release the
core in around 30 minutes. Until Windows Update is checked
again, and then it'll go nuts again. The time constant
(the delay factor), has been getting worse month by month.
At one time, the delay was 5 minutes of 100% CPU, now it's
up to 30 minutes of 100% CPU.
wuauserv Automatic Updates wuauserv.dll
*******
I got this from some Microsoft blog post.
You can split it out into its own service by running:
"sc config <service> type= own"
And revert it via
"sc config <service> type= share"
In the case of the wayward Windows Update thing, that
means I'd do one of these. Once I do this, wuauserv
is kept in its own svchost. The idea being, if
it is using CPU cycles, it's the only one inside
a separate svchost, and it's guilty as charged.
sc config wuauserv type= own
So if I do that, reboot, check which svchost is
using 100%, and I find that one with wuauserv
inside it, then wuauserv is the one doing it.
*******
If your symptoms seem to match, the current workaround
is to install a pending Internet Explorer update.
There could be a KB2888505 update waiting for you.
You could go to Windows Update, check your update
history, and see if it is already installed.
Without going to Windows update, you can also get
the update as a standalone download. These are two
I could find.
------
Use this, if you're running IE6.
"Cumulative Security Update for Internet Explorer for Windows XP
(KB2888505)
This update applies to Internet Explorer 6 with the following operating
systems:
* Windows XP SP3"
http://www.microsoft.com/en-us/download/details.aspx?id=41064
------
Use this, if you're running IE8.
Cumulative Security Update for Internet Explorer 8 for Windows XP
(KB2888505)
This update applies to Internet Explorer 8 with the following operating
systems:
* Windows XP SP3
http://www.microsoft.com/en-us/download/details.aspx?id=41074
------
Now, how this works, it isn't like some code in that
package, "fixes" your Windows Update. Instead, the
introduction of that patch, juggles the dependencies
enough, that the wuauserv doesn't get stuck in a loop.
I haven't read anything to convince me, we've seen the
last of this bug.
If that theory doesn't pan out, and you can't finger
that particular one, you can still use some of those
ideas to help track it down. If necessary, you could
take all fifteen services out of the "common" svchost
and make them run separately. It probably requires a
reboot, to see the new orientation (type= own).
Paul
