locked
Vista Computers Stuck Checking for Updates RRS feed

  • Question

  • We are currently rolling out Microsoft Forefront and using out existing WSUS servers to deploy the client and updates.  I approved some security updates and after installing those updates all of our Vista computers get stuck "Checking for Updates".  svchost.exe gets stuck at 50% CPU utilization (dual core processors so I'm assuming its maxing a single core).  I am seeing no errors either on the workstation or the servers.  We have 4 WSUS servers running on Server 2008 x64.  Our XP and Windows 7 computers seem to be working fine.  When I look at the WindowsUpdate.log file it always stops at Synchronizing extended update info.  I used the ClientDiag.exe tool and it reports no problems.

    Log info:

    2010-04-29 09:21:05:128  316 c80 Misc ===========  Logging initialized (build: 7.4.7600.226, tz: -0400)  ===========
    2010-04-29 09:21:05:128  316 c80 Misc   = Process: C:\Windows\system32\svchost.exe
    2010-04-29 09:21:05:128  316 c80 Misc   = Module: c:\windows\system32\wuaueng.dll
    2010-04-29 09:21:05:128  316 c80 Service *************
    2010-04-29 09:21:05:128  316 c80 Service ** START **  Service: Service startup
    2010-04-29 09:21:05:128  316 c80 Service *********
    2010-04-29 09:21:05:130  316 c80 Agent   * WU client version 7.4.7600.226
    2010-04-29 09:21:05:130  316 c80 Agent   * Base directory: C:\Windows\SoftwareDistribution
    2010-04-29 09:21:05:131  316 c80 Agent   * Access type: No proxy
    2010-04-29 09:21:05:131  316 c80 Agent   * Network state: Connected
    2010-04-29 09:21:13:806  316 8dc Report CWERReporter::Init succeeded
    2010-04-29 09:21:13:806  316 8dc Agent ***********  Agent: Initializing Windows Update Agent  ***********
    2010-04-29 09:21:13:807  316 8dc Agent ***********  Agent: Initializing global settings cache  ***********
    2010-04-29 09:21:13:807  316 8dc Agent   * WSUS server: http://wsus:8530
    2010-04-29 09:21:13:807  316 8dc Agent   * WSUS status server: http://wsus:8530
    2010-04-29 09:21:13:807  316 8dc Agent   * Target group: Computers
    2010-04-29 09:21:13:807  316 8dc Agent   * Windows Update access disabled: No
    2010-04-29 09:21:13:855  316 8dc DnldMgr Download manager restoring 0 downloads
    2010-04-29 09:21:13:856  316 8dc AU ###########  AU: Initializing Automatic Updates  ###########
    2010-04-29 09:21:13:857  316 8dc AU AU setting next detection timeout to 2010-04-29 13:21:13
    2010-04-29 09:21:13:857  316 8dc AU   # WSUS server: http://wsus:8530
    2010-04-29 09:21:13:857  316 8dc AU   # Detection frequency: 12
    2010-04-29 09:21:13:857  316 8dc AU   # Target group: Computers
    2010-04-29 09:21:13:857  316 8dc AU   # Approval type: Scheduled (Policy)
    2010-04-29 09:21:13:857  316 8dc AU   # Scheduled install day/time: Every day at 5:00
    2010-04-29 09:21:13:857  316 8dc AU   # Auto-install minor updates: Yes (Policy)
    2010-04-29 09:21:13:859  316 8dc AU Initializing featured updates
    2010-04-29 09:21:13:859  316 8dc AU Found 0 cached featured updates
    2010-04-29 09:21:13:861  316 8dc AU AU finished delayed initialization
    2010-04-29 09:21:13:862  316 8dc AU Triggering AU detection through DetectNow API
    2010-04-29 09:21:13:862  316 8dc AU Triggering Online detection (interactive)
    2010-04-29 09:21:13:889  316 c80 Report ***********  Report: Initializing static reporting data  ***********
    2010-04-29 09:21:13:889  316 c80 Report   * OS Version = 6.0.6002.2.0.65792
    2010-04-29 09:21:13:889  316 c80 Report   * OS Product Type = 0x00000006
    2010-04-29 09:21:13:918  316 c80 Report   * Computer Brand = Dell Inc.
    2010-04-29 09:21:13:918  316 c80 Report   * Computer Model = Latitude D830                  
    2010-04-29 09:21:13:921  316 c80 Report   * Bios Revision = A05
    2010-04-29 09:21:13:921  316 c80 Report   * Bios Name = Phoenix ROM BIOS PLUS Version 1.10 A05
    2010-04-29 09:21:13:921  316 c80 Report   * Bios Release Date = 2007-11-05T00:00:00
    2010-04-29 09:21:13:921  316 c80 Report   * Locale ID = 1033
    2010-04-29 09:21:13:922  316 c80 AU #############
    2010-04-29 09:21:13:922  316 c80 AU ## START ##  AU: Search for updates
    2010-04-29 09:21:13:922  316 c80 AU #########
    2010-04-29 09:21:13:925  316 c80 AU <<## SUBMITTED ## AU: Search for updates [CallId = {1B351AB5-9E06-406B-9C97-5C8E47E569E5}]
    2010-04-29 09:21:14:229  316 a74 Agent *************
    2010-04-29 09:21:14:229  316 a74 Agent ** START **  Agent: Finding updates [CallerId = AutomaticUpdates]
    2010-04-29 09:21:14:229  316 a74 Agent *********
    2010-04-29 09:21:14:229  316 a74 Agent   * Online = Yes; Ignore download priority = No
    2010-04-29 09:21:14:229  316 a74 Agent   * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
    2010-04-29 09:21:14:229  316 a74 Agent   * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
    2010-04-29 09:21:14:229  316 a74 Agent   * Search Scope = {Machine}
    2010-04-29 09:21:14:248  316 a74 Setup Checking for agent SelfUpdate
    2010-04-29 09:21:14:248  316 a74 Setup Client version: Core: 7.4.7600.226  Aux: 7.4.7600.226
    2010-04-29 09:21:14:249  316 a74 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2010-04-29 09:21:14:253  316 a74 Misc  Microsoft signed: Yes
    2010-04-29 09:21:14:260  316 a74 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
    2010-04-29 09:21:14:264  316 a74 Misc  Microsoft signed: Yes
    2010-04-29 09:21:14:267  316 a74 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    2010-04-29 09:21:14:271  316 a74 Misc  Microsoft signed: Yes
    2010-04-29 09:21:14:277  316 a74 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wsus3setup.cab:
    2010-04-29 09:21:14:282  316 a74 Misc  Microsoft signed: Yes
    2010-04-29 09:21:14:300  316 a74 Setup Determining whether a new setup handler needs to be downloaded
    2010-04-29 09:21:14:300  316 a74 Setup SelfUpdate handler is not found.  It will be downloaded
    2010-04-29 09:21:14:301  316 a74 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.4.7600.226"
    2010-04-29 09:21:14:303  316 a74 Setup Setup package "WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.4.7600.226" is already installed.
    2010-04-29 09:21:14:303  316 a74 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.4.7600.226"
    2010-04-29 09:21:14:323  316 a74 Setup Setup package "WUClient-SelfUpdate-Aux-TopLevel~31bf3856ad364e35~x86~~7.4.7600.226" is already installed.
    2010-04-29 09:21:14:324  316 a74 Setup Evaluating applicability of setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.4.7600.226"
    2010-04-29 09:21:14:356  316 a74 Setup Setup package "WUClient-SelfUpdate-Core-TopLevel~31bf3856ad364e35~x86~~7.4.7600.226" is already installed.
    2010-04-29 09:21:14:356  316 a74 Setup SelfUpdate check completed.  SelfUpdate is NOT required.
    2010-04-29 09:21:15:973  316 a74 PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    2010-04-29 09:21:15:973  316 a74 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus:8530/ClientWebService/client.asmx
    2010-04-29 09:22:46:290  316 a74 PT +++++++++++  PT: Synchronizing extended update info  +++++++++++
    2010-04-29 09:22:46:290  316 a74 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus:8530/ClientWebService/client.asmx

    We have DNS setup to allow for roaming users to get their updates from any of the four WSUS servers.

    Thanks for your help!

    Thursday, April 29, 2010 1:44 PM

Answers

  • Hi Lawernce,

    I did try changing the service location to reflect the actual server rather than the host that we have setup for round-robin.  This did not seem to make a difference. 

    I'm not sure exactly what happened but I ran the server cleanup on all the servers and performed syncronization between the upstream server and all the downstream servers.  Clients seem to be able to get their updates now.  Computers that have the svchost.exe stuck at 50% have to be rebooted but they seem to be working again.

    Thanks for the response.  I couldn't find anything to help me make sense of the log so I appriciate the information.  It was obviously getting stuck but I couldn't tell why or where.

    Thanks again!

    Scott

    Thursday, April 29, 2010 6:14 PM

All replies

  • 2010-04-29 09:21:15:973  316 a74 PT +++++++++++  PT: Synchronizing server updates  +++++++++++
    2010-04-29 09:21:15:973  316 a74 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus:8530/ClientWebService/client.asmx
    2010-04-29 09:22:46:290  316 a74 PT +++++++++++  PT: Synchronizing extended update info  +++++++++++
    2010-04-29 09:22:46:290  316 a74 PT   + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://wsus:8530/ClientWebService/client.asmx
    This is an incomplete detection event.
    We have DNS setup to allow for roaming users to get their updates from any of the four WSUS servers.
    This is a likely source of the complications. Round-Robin DNS has several complicating factors which are not (unfortunately) adequately described in the WSUS documentation concerning the use of this functionality. If you remove the Round-Robin DNS and allow this Vista client access to only one IP Address for the WSUS hostname, does the problem resolve itself?
    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Principal/CTO, Onsite Technology Solutions, Houston, Texas
    Microsoft MVP - Software Distribution (2005-2010)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    My Blog: http://onsitechsolutions.spaces.live.com
    Thursday, April 29, 2010 6:03 PM
  • Hi Lawernce,

    I did try changing the service location to reflect the actual server rather than the host that we have setup for round-robin.  This did not seem to make a difference. 

    I'm not sure exactly what happened but I ran the server cleanup on all the servers and performed syncronization between the upstream server and all the downstream servers.  Clients seem to be able to get their updates now.  Computers that have the svchost.exe stuck at 50% have to be rebooted but they seem to be working again.

    Thanks for the response.  I couldn't find anything to help me make sense of the log so I appriciate the information.  It was obviously getting stuck but I couldn't tell why or where.

    Thanks again!

    Scott

    Thursday, April 29, 2010 6:14 PM
  • I ran the server cleanup on all the servers and performed syncronization between the upstream server and all the downstream servers.  Clients seem to be able to get their updates now.  Computers that have the svchost.exe stuck at 50% have to be rebooted but they seem to be working again.

    Quite possibly this manifestation of the svchost.exe CPU utilization was impacted by the number of updates (or approved updates) available on the WSUS server. It's likely that running the Server Cleanup Wizard mitigated that impact, and reduced the number of updates that the WUAgent needed to process during a detection.

    The 50% utilization on a dual-core system is consistent with the 100% utilization we've seen on single-core systems.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Monday, May 6, 2013 8:18 PM