svchost.exe 99% cpu
smoore0414
master a about 20 subordinate WSUS server globally serving approximately 3000
clients. We are running SP3 for XP clients and SP2 for all Server 2003 R2
clients. We are seeing about 1-2% of these clients are having the issue where
svchost.exe is taking 99% of the CPU after updates are approved for
installation. There is no common denominator between the machines (except
maybe Office 2003), as I write this, a Server 2003 R2 machine is at 99% while
it is trying to install the updates. Usually we see it once the updates have
been approved and the client is attempting to sync with the WSUS server.
Usually, the only thing we can do is delete the contents of the
SoftwareDistribution folder and manually pull the updates from Windows
Update. We have gone through all the old 'fixes' with no success (927891, WUA
3.0).
Any assistance is in determining the root cause of this is grealy
appreciated.
MULTISY
Server (Windows Server 2008 Standard) of EBS; which uses WSUS 3.0.
wuaueng.dll pegs CPU Core, but it appears it is trying to run. Windows
Update will never response.
To prevent high CPU load, disable Windows Update Service.
"smoore0414" <smoor...@discussions.microsoft.com> wrote in message
news:FB1A6739-49D2-4DE0...@microsoft.com...
![PA Bear [MS MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjXsf05hH-R8XChS3fXPPzfoO8FYYxAKhT86KfPnIELr3QJ9tQ=s40-c)
PA Bear [MS MVP]
(microsoft.public.windows.server.update_services) via crosspost as a
convenience to OP.
In your newsreader:
news://msnews.microsoft.com/microsoft.public.windows.server.update_services
]]
Lawrence Garvin [MVP]
>> We are seeing about 1-2% of these clients are having the issue
>> where svchost.exe is taking 99% of the CPU after updates are approved for
>> installation. There is no common denominator between the machines (except
>> maybe Office 2003),
And this could be the significant common factor. There was an issue with
Office 2003 some time back. (Actually the issue was with the MSI.DLL, but it
manifested most often in relation to Office updates.) Are all of these
client machines fully updated for all Office 2003 applications?
>> as I write this, a Server 2003 R2 machine is at 99%
>> while it is trying to install the updates.
Does this server machine have any Office components installed? If so, are
they fully updated?
Also, is there a possibility that any of these machines are still running
one of the interim builds of the Windows Installer v3.1?
Here's a KB article that starts at the beginning of this issue, and contains
additional links that may also be relevant:
http://support.microsoft.com/default.aspx/kb/916089
--
Lawrence Garvin, M.S., MCITP:EA, MCDBA
Principal/CTO, Onsite Technology Solutions, Houston, Texas
Microsoft MVP - Software Distribution (2005-2009)
MS WSUS Website: http://www.microsoft.com/wsus
My Websites: http://www.onsitechsolutions.com;
http://wsusinfo.onsitechsolutions.com
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
smoore0414
Yes, they are all updated with latest Office 2003 patches, including SP3.
Oddly enough, the server does have Office 2003 installed as well (not sure
why i did that).
All these machines have had 927891 and WUA client 3.0 installed for quote
some time.
I can't see how they would/could be running an interim build of windows
installer 3.1.
-Scott
smoore0414
I was looking at the Server 2003 machine that had the problem, it has 927891
installed installed since 6/2007 and the version of msi.dll is 3.1.4000.4042
-Scott
smoore0414
Yes, they are all updated with latest Office 2003 patches, including SP3.
Oddly enough, the server does have Office 2003 installed as well (not sure
why i did that).
All these machines have had 927891 and WUA client 3.0 installed for quote
some time.
I can't see how they would/could be running an interim build of windows
installer 3.1.
MULTISY
updates my guess). Only resolution disable windows update service.
Thinking about it having Microsoft update automatically??? Most likely
better not getting this fixed.
"PA Bear [MS MVP]" <PABe...@gmail.com> wrote in message
news:e1cPRgtw...@TK2MSFTNGP05.phx.gbl...
James
of EBS.
I've just installed EBS and am having the same problem on the security
server. svchost.exe runs at full cpu usage, permanantly, until I turn the
windows update service off.
I've tried a number of things to fix it, including reboots, cleaning out
SoftwareDistribution folder and running it manually, but the problem keeps
coming backl
Lawrence Garvin [MVP]
news:020E23D6-E393-4968...@microsoft.com...
> MULTISY in the original post stated he was having this on the security
> server
> of EBS.
I missed that bit of information. I didn't see any "original post" from
MULTISY in this thread on the .update_services newsgroup.
> I've just installed EBS and am having the same problem on the security
> server. svchost.exe runs at full cpu usage, permanantly, until I turn the
> windows update service off.
Others have also reported similar issues on the security server of EBS in
the Connect .ebs newsgroup and on a private EBS newsgroup of which I'm
subscribed.
I would suggest engaging in that conversation if you have access. (Frankly,
I'm intrigued that such conversations are now taking place in a restricted
newsgroup on MSConnect rather than in a public newsgroup or forum -- of
course, no such public newsgroup exists.)
In the meantime, no actual cause/solution has been identified, but if one
is -- I'll post what I get back here.
smoore0414
the updates are approved for installation in the WSUS console, and the client
machine communicates with the WSUS server to get that new information, it
gets "stuck" for a lack of a better word. So, this starts before the machine
even begins to download the update file.
Looking in the WindowsUpdate.log when this happens, the last entry in the
log until it becomes "un-stuck" is similar to the following:
+++++++++++ PT: Synchronizing extended update info +++++++++++
+ ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL =
http://wsus-server/ClientWebService/client.asmx
This can be the last entry for an hour to 6 hours or more. Obviously, during
this time svchost.exe is pegged at 99%. Once the updated are located and
downloaded, typically it seems svchost.exe drops to normal usage.
So, it appears it is hanging during the communication process.
-Scott
Lawrence Garvin [MVP]
news:020E23D6-E393-4968...@microsoft.com...
> server
> of EBS.
>
> I've just installed EBS and am having the same problem on the security
> server. svchost.exe runs at full cpu usage, permanantly, until I turn the
> windows update service off.
Apparently there is an issue, just posted, that caused this on Exchange 2007
servers with automatic anti-spam updates enabled. This would include SBS2008
and EBS2008 installations with Forefront for Exchange installed.
It is, apparently a server-side issue at Microsoft.
Here's the link to the SBS blog post, and the relevant text included:
http://blogs.technet.com/sbs/archive/2009/04/25/svchost-may-spike-the-cpu.aspx
===========================================================
You may notice an issue where the Windows Update (WUAUSERV) service
will be spiking one of the logical CPUs on servers running Exchange 2007
with automatic anti-spam updates turned on. This will include any SBS 2008
installation where Forefront for Exchange was installed as part of the
setup.
Please note that the service displayed will by SVCHOST, since WUASERV
runs inside SVCHOST.EXE.
This issue has now been resolved on the Windows Update backend, and
should clear itself automatically after your WSUS server’s next sync. If
you
are still experiencing the issue you can start a manual WSUS sync by:
Open the Windows SBS Console
Click the Security tab
Click the Updates sub-tab
Click the Synchronize now task
Click Ok to start synchronization
Restart the Windows Update service once synchronization finishes (optional)
===========================================================
smoore0414
Our issue is not on Exchange servers. This is on client PC's running Window
Xp SP3 and Office 2003 (some with SP2 some with SP3).
Is it possible it may be related to the Outlook 2003 anti-junk filter (jsut
like the anti-spam updates in Exchange)?
Lawrence Garvin [MVP]
> My post got hijacked :)
That it did. :)
> Our issue is not on Exchange servers.
Neither is the issue I posted about. The issue is universal, amongst ALL
machines that are clients of a WSUS Server.
It potentially occurs in any environment running WSUS, Exchange 2007, and
Forefront Security for Exchange with automatic anti-spam updates enabled.
> Is it possible it may be related to the Outlook 2003 anti-junk filter
> (jsut
> like the anti-spam updates in Exchange)?
There *is* a prior issue that affected Office 2003 installations with
respect to a defect in the Windows Installer. The fix for that is the
installation of KB927891 and upgrading the client to the WUA v6.0 (or later)
client -- which happens automatically when upgrading a WSUS 2.0 server to
WSUS 3.0.
My general assumption is that all current environments already have those
upgrades applied (which were first released in early 2007), therefore that
solution is generally not relevant to occurrences of this behavior in 2009.
smoore0414
3.0, it appeared to remedy it. Until recently (I would say over the last 3-4
months) we have seen this occurance again. It's not happening on all
machines, and it's not happening on all machines running Office 2003. Oddly
enough, it appears to be happening to only those machines with Office 2003
Standard.
-Scott
Lawrence Garvin [MVP]
> Right, we did see is back in 2007, and after applying 927891 and WUA
> client
> 3.0, it appeared to remedy it. Until recently (I would say over the last
> 3-4
> months) we have seen this occurance again. It's not happening on all
> machines, and it's not happening on all machines running Office 2003.
> Oddly
> enough, it appears to be happening to only those machines with Office 2003
> Standard.
Yesterday, I just learned of three more possible issues that have been
documented to cause this behavior.
I was shocked to learn they were relevant; I was disappointed that they
hadn't been shared earlier.
1. Apparently there is a long-known (but underpublicized) issue with
machines using Outlook 2003 on top of an Office XP installation.
2. In general, on Office 2003 machines, if there is a large number of
installed updates (as evidenced by the contents of the
%systemroot%\Installer folder), which would be the case if the installation
dates back to the RTM package.
There's not much you can do for #1 -- typically this would affect
organizations that have PCs now nearing their end-of-lifecycle that shipped
during 2002 with Office XP, and deployed them into an SBS2003 organization
where Outlook 2003 was provided as an Exchange 2003 licensed client.
For #2, the 'workaround' appears to be:
[a] Uninstall Office 2003.
[b] Reinstall Office 2003 with Service Pack 2 (or apply SP2 directly to
the installation image currently available).
[c] Apply the post Service Pack 2 updates.
which will significantly reduce the contents of the %systemroot%\Installer
folder, and reduce the resulting resources needed to scan that folder at
each detection.
3. A excessive number of undeclined/superceded updates in the WSUS catalog,
which causes the WUA to perform unnecessary scanning work during the
detection event.
For #3 the recommended resolution is a combination of defining a service
pack baseline for system installation, declining all updates superceded by
that service pack, as well as declining all other superceded updates that
are no longer needed to bring a new machine to a fully patched status.
smoore0414
1. Yeah, not much we can do about that. You would think whatever 'issue'
woud have been resolved in one of the SP releases for either Windows XP or
Office 2003.
2. This is kind of a question mark, as I am not 100% sure how ALL these
machines had Office 2003 installed. However, I use Administrative
Installations with SP3 already applied to the install package and deply via
GPO. I know I have seen a few of these machines show this same issue.
3. This is a rather intriguing issue, that may make a lot of sense. I have
not yet gone through our WSUS catalog, but I am willing to bet every 2003
update since the beginning of time is approved for install. The reason I can
see this making some sense is, as I previously stated, when the client shows
99% CPU, the last entry in the WindowsUpdate.log is always "PT: Synchronizing
extended update info". This makes me wonder if the client is scanning through
all these old, approved updates to see if they are needed or not.
Lawrence Garvin [MVP]
> 2. This is kind of a question mark, as I am not 100% sure how ALL these
> machines had Office 2003 installed. However, I use Administrative
> Installations with SP3 already applied to the install package and deply
> via
> GPO. I know I have seen a few of these machines show this same issue.
SP3? Is there an SP3 for Office 2003? I could only find SP2 in my WSUS
Server and I didn't really go digging. But, if you're deploying
installations already patched to SP3, then #2 is not likely the issue.
Aside from that... there were also some historical issues with the WUA not
properly detecting updates from WSUS for application to a patched
administrative install point. I've never really become unconfuzed about this
issue, and I don't even know now if it 's unsupported (which was one
announcement at one point), or has been fixed (and actually works).
> 3. This is a rather intriguing issue, that may make a lot of sense. I have
> not yet gone through our WSUS catalog, but I am willing to bet every 2003
> update since the beginning of time is approved for install.
This would be the first place I'd go hunting, then.
Note: The issue is not specific to only Office updates. This would also be
relevant to the several dozen superseded Cumulative Updates for IE and OE,
Windows Mail and Outlook Junk Mail updates, Windows Defender definition
files, Malicious Software Removal Tools, and all of those updates superseded
by a service pack you've likely long-ago applied (XP SP3, Win2003SP1, Vista
SP1).
smoore0414
http://www.microsoft.com/downloads/details.aspx?FamilyID=E25B7049-3E13-433B-B9D2-5E3C1132F206&displaylang=en
I have never patched my administrative installations, jsut applied to the SP
to it, deploy via GPO and then let the client update via WSUS. I have 3
different versions of Office (2000, 2002, 2003), Office Apps (Project, Visio,
etc.) and other apps that I deploy this way.
I defintely think that may be the first place to start. Whether or not that
will help remains to be seen. Still, the odd part about all of this is it is
affecting only a small percentage. The only common denominator so far is
Office 2003 Std edition, but even then, not all the Office 2003 Std machines
are having this problem.
PA Bear [MS MVP]
in Nov-07 IIRC.]
Lawrence Garvin [MVP]
>> SP3? Is there an SP3 for Office 2003? I could only find SP2 in my WSUS
>> Server and I didn't really go digging. But, if you're deploying
>> installations already patched to SP3, then #2 is not likely the issue.
> [Yes, Office 2003 SP3 went RTM in Sept-07 & was released to Windows Update
> in Nov-07 IIRC.]
Well, shucks.. there it is, right here in my WSUS server... I just totally
missed it the first time through.