High CPU utilization by svchost and automatic updates processes

It takes several minutes for my older machines to check for updates. In some
instances this causes a "hang" in which mouse and keyboard control is lost
for up to 15 seconds. With process monitor, I see svchost and wuauclt in the
process activity monitor both use over 40 seconds of file time.

The workstation disks have been defragmented and I've run the server cleanup
wizard on the WSUS (3.0) server. I've also re-indexed the database.

Does anyone have suggestions for speeding up the client scans or ideas as to
what would cause this symptom?

Thanks,

-Mike

I also have an old PC (933Mhz) which takes
forever to check for updates.

I have Windows automatic updates turned off
and check for updates manually. It's takes a while
as you said so I just walk away and check the PC
later for the list of updates.

I have not found anything that will make a significant
speed improvement.

--
JS
http://www.pagestart.com


"Ricemt" <> wrote in message
news:1CA858C0-DA4A-4C11-84C4-...
> It takes several minutes for my older machines to check for updates. In
> some
> instances this causes a "hang" in which mouse and keyboard control is lost
> for up to 15 seconds. With process monitor, I see svchost and wuauclt in
> the
> process activity monitor both use over 40 seconds of file time.
>
> The workstation disks have been defragmented and I've run the server
> cleanup
> wizard on the WSUS (3.0) server. I've also re-indexed the database.
>
> Does anyone have suggestions for speeding up the client scans or ideas as
> to
> what would cause this symptom?
>
> Thanks,
>
> -Mike

What OSS are these "older machines"?

Do they update via WSUS?

It's not unusual to see temporary and brief (e.g, 15-30 seconds, possibly a
little longer) spikes in CPU when AU kicks into gear.

What other Processes are running in the background when this occurs? Have
you tried Clean Boot troubleshooting the behavior/problem?
--
~Robear Dyer (PA Bear)
MS MVP-IE, Mail, Security, Windows Client - since 2002
AumHa VSOP & Admin http://aumha.net
DTS-L http://dts-l.net/


Ricemt wrote:
> It takes several minutes for my older machines to check for updates. In
> some
> instances this causes a "hang" in which mouse and keyboard control is lost
> for up to 15 seconds. With process monitor, I see svchost and wuauclt in
> the
> process activity monitor both use over 40 seconds of file time.
>
> The workstation disks have been defragmented and I've run the server
> cleanup
> wizard on the WSUS (3.0) server. I've also re-indexed the database.
>
> Does anyone have suggestions for speeding up the client scans or ideas as
> to
> what would cause this symptom?

Sorry, I guess I left out many of the relevant details.

The systems in question are HP DC5100's with 2.8 Ghz Celeron processors and
512MB or 1 GB of memory and running XP SP2 or SP3. The memory and service
pack don't seem to make a difference.

Yes, they are updated by WSUS (Version: 3.1.6001.65).

Running process on the capture I'm currently looking at include:

Process Name File Time
lsass.exe 0
winlogon.exe 0
sdclientmonitor.exe 0
WinVNC.exe 0
WMPNetwk.exe 0
ctfmon.exe 0
Cpqdfwag.exe 0
iPodService.exe 0
uphclean.exe 0
WINWORD.EXE 0
LocalSch.EXE 0
igfxpers.exe 0
svchost.exe 0
ALsvc.exe 0
tmcsvc.exe 0.0004101
spoolsv.exe 0.0009303
SavService.exe 0.0232674
services.exe 0.0348336
support.exe 0.0397464
notepad.exe 0.0417357
OUTLOOK.EXE 0.0431455
BlitzMail.exe 0.0448974
svchost.exe 0.0529482
csrss.exe 0.0609516
wuauclt.exe 0.0689516
cmd.exe 0.1803052
Explorer.EXE 0.3250209
SideCar.exe 0.5419331
taskmgr.exe 0.8959313
softmon.exe 1.1609927
AcroRd32Info.exe 1.2844374
wmiprvse.exe 1.3755224
cisvc.exe 2.0968545
cidaemon.exe 12.4387084
svchost.exe 41.2095672
wuauclt.exe 42.8354778

The list of process are from a process monitor capture at the time when
windows update did a check for updates. The file times are what was reported
in the process activity summary.

The other interesting tidbit is that the average disk queue length hits
unacceptable levels while the systems are checking for updates. This is how I
correlated the system hangs with the windows update process.

It sounds like my next step should be the Clean Boot Troubleshooting you've
suggested.

Thanks,

-Mike




"PA Bear [MS MVP]" wrote:

> What OSS are these "older machines"?
>
> Do they update via WSUS?
>
> It's not unusual to see temporary and brief (e.g, 15-30 seconds, possibly a
> little longer) spikes in CPU when AU kicks into gear.
>
> What other Processes are running in the background when this occurs? Have
> you tried Clean Boot troubleshooting the behavior/problem?
> --
> ~Robear Dyer (PA Bear)
> MS MVP-IE, Mail, Security, Windows Client - since 2002
> AumHa VSOP & Admin http://aumha.net
> DTS-L http://dts-l.net/
>
>
> Ricemt wrote:
> > It takes several minutes for my older machines to check for updates. In
> > some
> > instances this causes a "hang" in which mouse and keyboard control is lost
> > for up to 15 seconds. With process monitor, I see svchost and wuauclt in
> > the
> > process activity monitor both use over 40 seconds of file time.
> >
> > The workstation disks have been defragmented and I've run the server
> > cleanup
> > wizard on the WSUS (3.0) server. I've also re-indexed the database.
> >
> > Does anyone have suggestions for speeding up the client scans or ideas as
> > to
> > what would cause this symptom?
>
>

[[ Forwarded to WSUS newsgroup
(microsoft.public.windows.server.update_services) via crosspost as a
convenience to OP.

On the web:
http://www.microsoft.com/communities...pdate_services

In your newsreader:
news://msnews.microsoft.com/microsof...pdate_services
]]

Ricemt wrote:
> Sorry, I guess I left out many of the relevant details.
>
> The systems in question are HP DC5100's with 2.8 Ghz Celeron processors
> and
> 512MB or 1 GB of memory and running XP SP2 or SP3. The memory and service
> pack don't seem to make a difference.
>
> Yes, they are updated by WSUS (Version: 3.1.6001.65).
>
> Running process on the capture I'm currently looking at include:
>
> Process Name File Time
> lsass.exe 0
> winlogon.exe 0
> sdclientmonitor.exe 0
> WinVNC.exe 0
> WMPNetwk.exe 0
> ctfmon.exe 0
> Cpqdfwag.exe 0
> iPodService.exe 0
> uphclean.exe 0
> WINWORD.EXE 0
> LocalSch.EXE 0
> igfxpers.exe 0
> svchost.exe 0
> ALsvc.exe 0
> tmcsvc.exe 0.0004101
> spoolsv.exe 0.0009303
> SavService.exe 0.0232674
> services.exe 0.0348336
> support.exe 0.0397464
> notepad.exe 0.0417357
> OUTLOOK.EXE 0.0431455
> BlitzMail.exe 0.0448974
> svchost.exe 0.0529482
> csrss.exe 0.0609516
> wuauclt.exe 0.0689516
> cmd.exe 0.1803052
> Explorer.EXE 0.3250209
> SideCar.exe 0.5419331
> taskmgr.exe 0.8959313
> softmon.exe 1.1609927
> AcroRd32Info.exe 1.2844374
> wmiprvse.exe 1.3755224
> cisvc.exe 2.0968545
> cidaemon.exe 12.4387084
> svchost.exe 41.2095672
> wuauclt.exe 42.8354778
>
> The list of process are from a process monitor capture at the time when
> windows update did a check for updates. The file times are what was
> reported
> in the process activity summary.
>
> The other interesting tidbit is that the average disk queue length hits
> unacceptable levels while the systems are checking for updates. This is
> how
> I correlated the system hangs with the windows update process.
>
> It sounds like my next step should be the Clean Boot Troubleshooting
> you've
> suggested.
>
> Thanks,
>
> -Mike
>
>
>
>
> "PA Bear [MS MVP]" wrote:
>
>> What OSS are these "older machines"?
>>
>> Do they update via WSUS?
>>
>> It's not unusual to see temporary and brief (e.g, 15-30 seconds, possibly
>> a
>> little longer) spikes in CPU when AU kicks into gear.
>>
>> What other Processes are running in the background when this occurs?
>> Have
>> you tried Clean Boot troubleshooting the behavior/problem?
>> --
>> ~Robear Dyer (PA Bear)
>> MS MVP-IE, Mail, Security, Windows Client - since 2002
>> AumHa VSOP & Admin http://aumha.net
>> DTS-L http://dts-l.net/
>>
>>
>> Ricemt wrote:
>>> It takes several minutes for my older machines to check for updates. In
>>> some
>>> instances this causes a "hang" in which mouse and keyboard control is
>>> lost
>>> for up to 15 seconds. With process monitor, I see svchost and wuauclt in
>>> the
>>> process activity monitor both use over 40 seconds of file time.
>>>
>>> The workstation disks have been defragmented and I've run the server
>>> cleanup
>>> wizard on the WSUS (3.0) server. I've also re-indexed the database.
>>>
>>> Does anyone have suggestions for speeding up the client scans or ideas
>>> as
>>> to
>>> what would cause this symptom?

I rebuilt a system from our corporate image and then did a clean-boot.

For a test sequence, I stop automatic updates, delete the contents of
c:\windows\softwaredistribution, and the start automatic updates. I then
start process monitor, and issue a "wuauclt /detectnow" from a command prompt.

With this process, I see wuauclt.exe taking between 36 and 42 seconds of
file time.

If I don't delete the contents of c:\windows\softwaredistribution,
wuauclt.exe takes less than 1 second of file time.

In looking at c:\windows\windowsupdate.log on a slow system, I see large
chunks of time used here:

2009-03-23 09:15:07:869 1064 148 PT Server URL =
http://dh343/SimpleAuthWebService/SimpleAuth.asmx
2009-03-23 09:16:19:827 1064 148 PT +++++++++++ PT: Synchronizing extended
update info +++++++++++

On our more recent hardware, I see the same log entries taking between 6 and
8 seconds.

Am I on the right path here? What is happening with "PT: Synchronizing
extended update info" and is there a way to make it happen either faster or
in a manner that doesn't impact the users?

Thanks,

-Mike

Are the systems obtaining the latest Version of the Windows Update Agent
[WUA] from WSUS ?

As long as the most recent Versions of the WUA have been installed
[7.2.6001.784 and 7.2.6001.788 ], I'd venture that the issue stems from
the check of the DataStore.edb, located in SoftwareDistribution\DataStore.
There are locked files in the SD subfolder that MS recommends NOT
scanning with the installed AV. Check this KB and see if doing so
resolves the high CPU issue:

Virus scanning recommendations for computers that are running Windows
Server 2008, Windows Server 2003, Windows 2000, Windows XP, or Windows Vista
http://support.microsoft.com/kb/822158

On the systems where I've seen the high CPU issue, just excluding
DataStore.edb resolved it.


MowGreen [MVP 2003-2009]
===============
*-343-* FDNY
Never Forgotten
===============


Ricemt wrote:

> I rebuilt a system from our corporate image and then did a clean-boot.
>
> For a test sequence, I stop automatic updates, delete the contents of
> c:\windows\softwaredistribution, and the start automatic updates. I then
> start process monitor, and issue a "wuauclt /detectnow" from a command prompt.
>
> With this process, I see wuauclt.exe taking between 36 and 42 seconds of
> file time.
>
> If I don't delete the contents of c:\windows\softwaredistribution,
> wuauclt.exe takes less than 1 second of file time.
>
> In looking at c:\windows\windowsupdate.log on a slow system, I see large
> chunks of time used here:
>
> 2009-03-23 09:15:07:869 1064 148 PT Server URL =
> http://dh343/SimpleAuthWebService/SimpleAuth.asmx
> 2009-03-23 09:16:19:827 1064 148 PT +++++++++++ PT: Synchronizing extended
> update info +++++++++++
>
> On our more recent hardware, I see the same log entries taking between 6 and
> 8 seconds.
>
> Am I on the right path here? What is happening with "PT: Synchronizing
> extended update info" and is there a way to make it happen either faster or
> in a manner that doesn't impact the users?
>
> Thanks,
>
> -Mike

[[ Forwarded again to WSUS newsgroup via crosspost. @Ricemt: Please
crosspost all further replies to
microsoft.public.windows.server.update_services newsgroup, too THX ]]

Ricemt wrote:
> I rebuilt a system from our corporate image and then did a clean-boot.
>
> For a test sequence, I stop automatic updates, delete the contents of
> c:\windows\softwaredistribution, and the start automatic updates. I then
> start process monitor, and issue a "wuauclt /detectnow" from a command
> prompt.
>
> With this process, I see wuauclt.exe taking between 36 and 42 seconds of
> file time.
>
> If I don't delete the contents of c:\windows\softwaredistribution,
> wuauclt.exe takes less than 1 second of file time.
>
> In looking at c:\windows\windowsupdate.log on a slow system, I see large
> chunks of time used here:
>
> 2009-03-23 09:15:07:869 1064 148 PT Server URL =
> http://dh343/SimpleAuthWebService/SimpleAuth.asmx
> 2009-03-23 09:16:19:827 1064 148 PT +++++++++++ PT: Synchronizing
> extended
> update info +++++++++++
>
> On our more recent hardware, I see the same log entries taking between 6
> and
> 8 seconds.
>
> Am I on the right path here? What is happening with "PT: Synchronizing
> extended update info" and is there a way to make it happen either faster
> or
> in a manner that doesn't impact the users?
>
> Thanks,
>
> -Mike

> Ricemt wrote:
>> I rebuilt a system from our corporate image and then did a clean-boot.
>>
>> For a test sequence, I stop automatic updates, delete the contents of
>> c:\windows\softwaredistribution, and the start automatic updates. I then
>> start process monitor, and issue a "wuauclt /detectnow" from a command
>> prompt.
>>
>> With this process, I see wuauclt.exe taking between 36 and 42 seconds of
>> file time.
>>
>> If I don't delete the contents of c:\windows\softwaredistribution,
>> wuauclt.exe takes less than 1 second of file time.

Doh... you destroy the file download cache, which it then needs to rebuild,
and you're surprised to sse it takes some time to do that?

>> Am I on the right path here?

No. Why, pray tel, are you mucking with the SoftwareDistribution folder ..
for "testing"???

> What is happening with "PT: Synchronizing
>> extended update info" and is there a way to make it happen either faster
>> or in a manner that doesn't impact the users?

Quit deleting the friggin "SoftwareDistribution" folder would be the first
step.


--
Lawrence Garvin, M.S., MCITP(x2), MCTS(x5), MCP(x7), MCBMSP
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/pro...awrence.Garvin