> i was speaking to a microsoft technician yesterday about it and he gave me
> this link, seems to have worked for me so far.
> hope this helps
> "buRford" wrote:
> > Hi - - Over the past month, I've noticed some strange behavior after my first bootup of
> > the day... about 30 secs - a minute after bootup, wuauclt.exe starts, then shortly after
> > wmiprvse.exe starts.
> > My CPU spikes to 99%, and everything hangs. One entry of svchost spikes to
> > 99% CPU usage. Then after 30 seconds or so, all goes back to normal. This is the only
> > time it happens. If I bootup later in the day, all's cool... only happens first bootup of
> > the day.
> > If I disable WU, all is cool.
> > The only connections that open are to windows update, during this lag.
> > As far as I can tell, I've scanned with my AV (NOD32), Outpost Firewall anti-spyware
> > plug-in, Spybot, Adaware, Spycop, and Unhackme... my system is clean.
> > I don't know if this has any relevance: In my wmiprov.log I'll get an entry "WDM call
> > returned error: 4200."
> > In wbemess.log, I get five entries of "NT Event Log Consumer: could not retrieve sid,
> > 0x80041002."
> > Nothing abnormal shows up in the System or Application entries of EVENT VIEWER.
> > No other abnormal behavior or errors ever... if I wait a minute or two after bootup, and
> > do nothing, then I have no problems.
> > I'm running XP sp2, on an AMD Athlon XP 1800, with 768MB RAM.
> > Right now, I have WU disabled, but I'd prefer to be notified when
> > Anyone have any idea what might be going on, or where I can look on my system to
> > troubleshoot this? Anywhere I can find out what is using SVCHOST?
> > Any help is appreciated... thanks!
I stumbled across this thread and noticed that it was never really answered
or resolved, so I thought I'd bring some closure
The long delay on boot is caused by the mechanism used by Windows/Microsoft
Auto Update (wuauclt.exe; ...\system32\wu*.*) to determine if you're up to
date or not. Essentially the routine takes each update in order and looks
for it's signature in the appropriate program, thusly: Fetch Update A -> get
signature for Update A -> scan [Windows/Office/Other MS software] for matches
to Update A signature -> IF match found, fetch Update B; ELSE add Update A to
InstallList then fetch Update B. Obviously, the more updates available
and/or pieces of MS software you have installed, the longer the whole
procedure will take. A quick aside here: *Windows* Update just handles
updating the OS itself. *Microsoft* Update handles Windows, Office, and most
any other M$ software you've got. You can cut down on the time wastage by
either avoiding MS Update for Windows Update or by configuring MS Update to
only check for OS updates.
The modules mentioned (svchost, iexplore, explorer) are Windows components
involved in the update process. As a working generalization, you can think
of these components' functions this way: svchost [services host] is
essentially the virtual machine that the component runs in; iexplorer
(Internet Explorer) handles communications between Windows and the MS website
[regardless of what browser you actually use]; and explorer (Windows
Explorer) handles communications between Windows components themselves and
between Windows and you. So you can conceptualize the outbound
communications as: wu*.* files -> svchost (for Windows Update) -> explorer
-> svchost (for Internet Explorer) -> iexplore -> Update website [for
incoming, reverse the sequence].
The ActiveX blocker mentioned above at Spyware.info works by preventing all
ActiveX controls from running. ActiveX has gotten a pretty bad reputation
because, like a gun, it can be used for great evil. But also like a gun, it
can be used for great good; in this case, ActiveX controls are what lets the
MS website scan your copy of MS software looking for the Update signature as
discussed above. By preventing ActiveX controls from running, you are
preventing the update process from happening and thus not using any CPU
cycles. However, you're also preventing many other (some good!) things from
running as well - like some anti-virus programs' updates/scans, many
utilities, and interfering with some core Windows functions. Back to our
analogy, it's like taking the bullets away from the gun - you can't use it
for evil, but you can't use it to stop evil, either.
There is no way to "fix" the problem. If you get updates, you're going to
incur the CPU usage. What you can do, however, is control WHEN you get the
updates. Control Panel > Security Center > Automatic Updates lets you set a
schedule that Windows should use to check for updates. This procedure,
however, has been known to be flaky and you need to be aware that if you
automate any steps of the update process, you're going to get what MS wants
you to have - which may not coincide with what YOU want to have.
Alternatively, you can use my preferred method which is to disable updates
entirely; enabling them only when YOU want to check/get them.
This gives you the ability to control when you get updates AND (unless you
choose the "express" option on the website) lets you choose which updates you
get and install. Don't want the Korean language pack update? Uncheck the
box and you won't get it. Already got good anti-virus? Then you can uncheck
the MRT update. Think IE7 is a tool of Satan? Uncheck the box... And so on.
Note, however, that taking control of your updates is NOT as simple as
turning Automatic Updates off in Security Center - oh, no! This IS, after
all, Micro$oft and that would be too easy and obvious. Turning Updates off
really only turns off Windows *telling you* that it's doing the Update thing
- it will still contact the website, get updates, scan your system, etc.; you
just won't know about it and the updates won't actually be applied (in
theory, anyway....). To truly stop Automatic Updates you must kill the
service which can be done using the services.msc MMC snap-in, or the SC
command-line command, or a 3d party utility like my recommendation, Nir
Sofer's marvelous ServiWin applet freeware from http://www.nirsoft.net
Set the Startup option to "disabled" and after a reboot, auto updates will
not load. When you want to check updates, simply access the service again
with whatever method you prefer, set Startup to "Automatic" and "start" it.
When you're done with the updates, just reset the service to "stop" and
"disabled". A small price in hassle to pay, IMO, for the security of
controlling what's on your system.
A bit long-winded, but I tried to cover all the issues/questions raised in
the thread. Hope it's been helpful to *somebody*!