none
Automatic Update causes SVCHOST.exe high CPU

    Question

  • Hi,

    I have a problem with high CPU usage on Windows 7 clients and Windows 2008 R2 servers. 

    When I turning off windows update service the high CPU issue dissapears, but if service startup type is automatic service starting in two minutes and this problem went back.

    When I trying to check updates from WSUS or from online the Windows Update is stuck in Checking for updates state.

    WSUS version is 3.2.7600.226.

    How can I solve this problem? 

     

    Monday, August 27, 2012 12:26 PM

Answers

  • Update: Solved sync issue by performing cleanup wizard on WSUS servers.
    Tuesday, August 28, 2012 12:03 PM
  • Yes, but seems that the main problem was solved by turning off updating from WSUS and installing updates from internet. After updating all PC's the issue with high CPU is gone. I've successfully enabled GP's for WSUS and everything started working well.

    I don't know which one update from list that I posted fixed my problem.

    Wednesday, August 29, 2012 4:59 AM

All replies

  • Update: when WSUS server is turned off all computers running fine. Updates are checking and installing from internet. No CPU issue.
    Monday, August 27, 2012 1:02 PM
  • Update: when WSUS server is turned off all computers running fine. Updates are checking and installing from internet. No CPU issue.

    This would suggest that the issue is in your WSUS server.

    • How many updates do you have synchronized?
    • How many updates are approved?
    • How many client systems are there?
    • What is their detection interval?

    Most likely it's time to do some 'housekeeping' on the WSUS server.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Monday, August 27, 2012 8:38 PM
    Moderator
  • Thanks for reply.

    I turned off WSUS server and disabled WSUS GP's. After that I updated some servers including WSUS server and clients from Internet. The issue with CPU is gone for that PC's.

    List of istalled updates:

    KB2600217
    KB2679255
    KB2633952
    KB2647753
    KB2660075
    KB2709630
    KB2929094
    KB2607047
    KB2699779
    KB2608658
    KB2640148
    KB2603229

    Now I can go to WSUS control panel. There are some synchronization errors:

    SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
       at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ReadOneRow()
       at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

    But I see that synchronization brings count for new and expired updates.

    This WSUS server is a replica of another server. On the main server site everithing is fine.

    Tuesday, August 28, 2012 7:07 AM
  • Update: Solved sync issue by performing cleanup wizard on WSUS servers.
    Tuesday, August 28, 2012 12:03 PM
  • Update: Solved sync issue by performing cleanup wizard on WSUS servers.
    Which is pretty much where we were headed with the questions I asked.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Tuesday, August 28, 2012 9:48 PM
    Moderator
  • Yes, but seems that the main problem was solved by turning off updating from WSUS and installing updates from internet. After updating all PC's the issue with high CPU is gone. I've successfully enabled GP's for WSUS and everything started working well.

    I don't know which one update from list that I posted fixed my problem.

    Wednesday, August 29, 2012 4:59 AM
  • Yes, but seems that the main problem was solved by turning off updating from WSUS and installing updates from internet.

    That's not a problem solution, that's merely problem avoidance. I submit that the problem was (or will be) solved by doing the proper update maintenance on your WSUS server. If you don't do the appropriate maintenance, I promise you the problem will occur again.
    After updating all PC's the issue with high CPU is gone.
    Of course, because now the WUAgent knows those updates are installed, it has copies of the update cached locally, and it no longer has to evaluate rulesets and cache update metadata from the WSUS server -- it's all being read locally.

    I don't know which one update from list that I posted fixed my problem.

    It's not any one update from any list .. it's the cumulative effects of having one or more of the following:
    • too many updates synchronized
    • too many updates approved
    • too many clients
    • too many groups

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    Product Manager, SolarWinds
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin

    Thursday, August 30, 2012 12:31 AM
    Moderator
  • Thanks, I've allready done maintenance on WSUS. I was not able to do it before turning off local updates because WSUS was in not responding state.
    Monday, September 03, 2012 1:06 PM
  • What do you do when the cleanup wizard won't run?  I have even gone so far as to write a PowerShell that does each step one at a time.  I have run the MS DB Optimization Script, but no luck.

    Some of the cleanups just timeout...

    Monday, December 03, 2012 11:14 PM
  • What do you do when the cleanup wizard won't run?

    Can you be more specific with "won't run"?

    I have even gone so far as to write a PowerShell that does each step one at a time.

    You know, there's already a tested PowerShell script in codeplex for this?

    I have run the MS DB Optimization Script, but no luck.

    Some of the cleanups just timeout...

    Ahh yes... definitely a problem when a WSUS server has gone too long with out maintenance.

    So, first, when you ran the WSUS DB Maintenance script, did you do that in conjunction with defragmenting the filesystem? If not, defragmenting the filesystem (so that the SUSDB.mdf is on contiguous space) can help significantly. If the database is on the SYSVOL, then just defrag the SYSVOL (which will require a restart). If the database is on a different volume, stop the database service before launching the defrag (otherwise the SUSDB.mdf is locked and it cannot be defragmented).

    Run the WSUS DB Maintenance script.

    After the filesystem defrag and database reindex, then run the Server Cleanup Wizard.. in this order:

    1. Delete unneeded computers.

    2. Decline expired and superseded updates.

    3. DELETE updates (this is the step that is causing the timeouts because it's a very expensive database operation to scan the entire update table, compare it to approvals, client reporting data, etc. in order to determine if an update should be deleted. And then the deletion itself is expensive, and that triggers an index reorg, which can be especially painful if it's being done on a heavily fragmented filesystem, or a heavily fragmented SUSDB.mdf file and/or with inefficient indexes). Note: I also strongly suggest running this command from the LOCAL console on the WSUS server. It may take several hours to run. Best plan is to launch it at the end of the day on Friday, go home, and forget about it until Monday morning.

    4. Delete files (once updates are deleted/declined, then this task can remove all of the unneeded files from the WSUSContent folder).

    If you delete a significant number of updates and/or files, then you should defrag the filesystem again, and then run the WSUS DB Maintenance script again.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    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.

    Thursday, December 06, 2012 2:59 PM
    Moderator
  • -- "Can you be more specific with "won't run"?"

    As in it appears to be working for a while, then goes "white" and unresponsive after a few hours.

    -- "You know, there's already a tested PowerShell script in codeplex for this?"

    Yep, I found that, and they would run for a few DAYS then give a timeout error.  Sorry, I didn't keep them (I resolved it).

    So, I wrote a script that would cycle though every "solution" out there in a loop (DB Script form MS, Index Rebuild Scripts, PowerShell Scripts blah blah blah).  It never seems to be able to get around this timeout.  And again, we are talking after days.  The server isn't that old and doesn't have that many clients (maybe 300).

    I was able to resolve the issue.  It took a few steps.

     #1 Migrate the DB to MS SQL 2008 (our main DB).

    After the migration I was able to run the PowerShell cleanup scripts.  They took 19 hours to run on a DB that is only 6GBs (I think MS needs to work on their DB design :/ )...  However I could not sync with the upstream server.  It would get all of the patches but then error out.  Again reporting a "timeout".

    I made the conclusion that this was happening during the statistical upload. So I removed the server from the upstream server and tried again. Same result.

      #2 I switched it from a replicated server to a direct connection to Microsoft and synced it. I then cleared it from the master server again and re-pointed it out master.

    After that I am now fully functional again.

    ...

    This whole thing has left me feeling less than confidant in WSUS. It seems just wrong that a topped out DB on WSUS should tank every computer in our environment. I also find it irritating that there are no "stock" methods for automatic a cleanup that is required to keep this think from going nuts.

    Sorry, just had to vent there for a moment.

    FYI, this WSUS server has 4 CPUs and 16GBs of RAM and sits on a SAN drive with an SSD cache.  So it's not a system performance issue...




    • Edited by B P Woods Tuesday, December 11, 2012 6:45 PM
    Tuesday, December 11, 2012 6:44 PM
  • Oh, and after the wizard would go "white" it would eventually timeout as well.  But when it came back, the MMC would not populate and fields.
    Tuesday, December 11, 2012 6:52 PM
  • -- "Can you be more specific with "won't run"?"

    As in it appears to be working for a while, then goes "white" and unresponsive after a few hours.

    Well, it depends.

    I was able to resolve the issue. It took a few steps.

    #1 Migrate the DB to MS SQL 2008 (our main DB).

    What database engine was WSUS running on prior to the migration?
    They took 19 hours to run on a DB that is only 6GBs
    That's about normal for a 6GB database that's never had any cleanup run on it before. I discuss elsewere in this forum (recently, in fact) exactly why this is the case. It has nothing at all to do with database design, it has everything to do with the amount of effort that is necessary to perform analysis on tens of thousands of updates to determine whether they are eligible for deletion or not.
    However I could not sync with the upstream server.
    Uhhh.. are you saying you ran this maintenance activity on the downstream server?
    It would get all of the patches but then error out.
    Yep. If you didn't do the maintenance on the upstream server, this is expected behavior.
    This whole thing has left me feeling less than confidant in WSUS.
    Yeah, I know the feeling. I hated GM for a very long time after I blew the engine in my Oldsmobile Achieva because I forgot to fill the crankcase.

    It seems just wrong that a topped out DB on WSUS should tank every computer in our environment. I also find it irritating that there are no "stock" methods for automatic a cleanup that is required to keep this think from going nuts.

    And, nowhere in all of this, has it ever occurred to you that Human Error might have been a significant contributing factor?

    Actually, there are "stock methods" for doing a cleanup. The tool is documented in the WSUS Operations Guide; and Codeplex has a PowerShell script suitable for scheduling in Task Scheduler.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    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.

    Wednesday, December 12, 2012 3:33 AM
    Moderator
  • <style type="text/css"><!-- @page { margin: 0.79in } P { margin-bottom: 0.08in } --> </style>

    - | -- "Can you be more specific with "won't run"?"

    - |

    - | As in it appears to be working for a while, then goes "white" and unresponsive after a few hours.

    - |

    - | Well, it depends.

    What does? Sorry, I don't understand.

    - | I was able to resolve the issue. It took a few steps.

    - |

    - | #1 Migrate the DB to MS SQL 2008 (our main DB).

    - |

    - | What database engine was WSUS running on prior to the migration?

    The stock Windows DB that installs with the wizard.

    - | They took 19 hours to run on a DB that is only 6GBs

    - |

    - | That's about normal for a 6GB database that's never had any cleanup run

    - | on it before. I discuss elsewere in this forum (recently, in fact) exactly why

    - | this is the case. It has nothing at all to do with database design, it has

    - | everything to do with the amount of effort that is necessary to perform

    - | analysis on tens of thousands of updates to determine whether they are

    - | eligible for deletion or not.

    Yes and no. I have some experience in DB design and that only shows a lack of planning/design on Microsofts part. Sorry, but I have worked with far more complex datasets, and that just isn't a very good answer. But that is only my opinion, so feel free to ignore it.

    - | However I could not sync with the upstream server.

    - |

    - | Uhhh.. are you saying you ran this maintenance activity on the

    - | downstream server?

    Correct, the upstream server had the maintenance wizard run on a regular basis. It was only this single downstream server that seems to have lost it's marbles.

    - | It would get all of the patches but then error out.

    - |

    - | Yep. If you didn't do the maintenance on the upstream server, this is

    - | expected behavior.

    Again, upstream was fine, maintenance was run.

    - | This whole thing has left me feeling less than confidant in WSUS.

    - |

    - | Yeah, I know the feeling. I hated GM for a very long time after I blew

    - | the engine in my Oldsmobile Achieva because I forgot to fill the crankcase.

    - | It seems just wrong that a topped out DB on WSUS should tank every

    - | computer in our environment. I also find it irritating that there are no

    - | "stock" methods for automatic a cleanup that is required to keep this

    - | think from going nuts.

    - |

    - | And, nowhere in all of this, has it ever occurred to you that Human Error

    - | might have been a significant contributing factor?

    - | Actually, there are "stock methods" for doing a cleanup. The tool is

    - | documented in the WSUS Operations Guide; and Codeplex has a PowerShell

    - | script suitable for scheduling in Task Scheduler.

    Ok, now I kinda take issue with that. If I didn't do what I was supposed to, sure I can see WSUS going out. But not the clients. That is just a bad design, period.

    Just to be clear, there is no stock method for automating the cleanup in WSUS. As for a PowerShell script being stock, no, I don't think so. It didn't ship with it, so it's not “stock”. I can even say the same thing about the WSUS Operations Guide. It is not something that ships with the product. You have to go looking for it. And nowhere in the guide does it state this possible ramification. In-fact, the only place that Microsoft talks about it is in KB938947.

    I feel like I am in the Hitchhiker's Guide to the Galaxy when the Vogons are talking about how the plans for Earths demolition have been posted for years. :)


    • Edited by B P Woods Wednesday, December 12, 2012 9:56 PM
    Wednesday, December 12, 2012 9:55 PM