Hey… where did my RAM go? – WSUS, SVCHOST and High RAM Usage

A quick blog about this…    The problem has been driving me crazy for the last couple of weeks.

Random clients have been calling, reporting that they were having high RAM usage on the SVCHOST process.   That normally worries me and points to some nasties.   Looking further into the issue you can see that the Windows Update service is the cause.

Luckily, Les Connor and Susan Bradley – SBS MVP’s – were already on the case chatting about the issue on our private listserv.  I stumbled across the thread where Susan pointed to:

The Automatic Updates service may stop responding:

Oh wonderful.   ANOTHER PATCH I HAVE TO CALL PSS FOR!   Do Microsoft have ANY idea how difficult and how much of a waste of time it is to sit on the phone just to get a patch!  We so badly need another way!

EDIT 4:  Due to pressure from my fellow SBS MVP’s, I have taken down the links to the patches.   Not that I wanted to, because this situation of having to call for patches outside the USA SUCKS!

  9 Replies to “Hey… where did my RAM go? – WSUS, SVCHOST and High RAM Usage”

  1. Dale Unroe
    August 30, 2006 at 2:33 pm

    …or you could just reduce your WSUS Update cycle to greater than every 2 hours in your relevant GPO and wait for the patch at the next patch Tuesday

    Thanks for bringing attention to this though. I have found Update Services in a stopped state and wondered how it had occurred.

  2. August 30, 2006 at 2:39 pm

    Thanks for that tip Dale.

    I am actually set to once every 12 hours. It still happens.

    Is that normal?

  3. September 2, 2006 at 7:33 am

    I’m surprised you find it difficult to get hotfixes from Microsoft – the couple of times I had to use them in the uk, the hardest bit was finding the phone number for pss – then it was just a case of interrupting their spiel on the phone and stating i wanted a hotfix for kb article 123456, providing the same os as the kb article and i had it in my email about 5 minutes later.

  4. September 4, 2006 at 2:36 am

    Hey Andy,

    During working hours it isn’t so bad. But anytime after 5:30 or before 9:00 it is really bad.

    But… that’s not the point. Do you not agree that Microsoft Partners should have full access, via the web, to these patches?

  5. January 11, 2007 at 12:10 pm

    I totally agree that we should have 24 hour access. I’d also say that anyone should get access to the patches. After all, if they are free to anyone then why lock them away. If people are dumb enough to install the wrong patch, then that is their own fault, but someone who is intelligent enough to find the kb article relating to their problem is likely to be clever enough to ensure they have a backup and a recovery plan in place.

  6. Michael Porzio
    February 15, 2007 at 11:40 am

    Is this patch for the error:

    Error: Agent failed detecting with reason: 0x8007000e


  7. Mike
    February 19, 2007 at 12:37 pm

    After installing this patch 6 of my machiens began having an issue with svchost crashing upon login. an absolute nightmare. I was able to fix most of them by useing a file given to me by a second level engineer at MS called sysreg.bat. It basically broke windows update and this file reregisteres all of the dll files and renames the software distribution folder. I nust say that it did fix my WSUS error “Error: Agent failed detecting with reason: 0x8007000e” but in the process broke half of my machiens.

  8. February 19, 2007 at 12:47 pm

    Everyone reading this post, should not make any more comments and should go here, to the updated article:


  9. March 10, 2007 at 5:36 am

    my god.. i work as a technical support analyst for Sophos.. some customers we get:

    “your product is eating all our cpu and memory”

    get them to check the processes…

    “yes its a sophos process.. svchost!”

    erm… riiiiight.


    glad ur a guy who actually fixes these problems nick 🙂

Leave a Reply to NickWhittome Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.