WSUS 6.3 default install, the IIS Worker Process takes 90(+)% of the CPU's which crashes WSUS MMC Snapin RRS feed

  • Question

  • We have a default install of WSUS 6.3.9600.16384 we have been unable to put into production because IIS Worker Processes are consuming 90(+)% of the (4) CPU's which causes the WSUS management console to crash. The install is on a newly built Windows 2012 R2 Datacenter server with no other server Roles or Features installed. When the WSUS role was added, it added the additional required roles and features as needed, we added nothing extra.

    In IIS, when the role was installed it shows 2 sites, the Default Web Site bindings on port 80 and the WSUS Administration site bindings on ports 8530 & 8531. 2,900 Machines are hitting the new server and showing up in WSUS console. We are also able to sync and pull down updates without issue.

    What is occurring is that IIS Worker Processes will consume all of the CPU resources causing the WSUS management to freeze and crash. Once the management console crashes, we found that we can do an "iisreset" and once the reset has completed WSUS begins functioning without issue until the IIS Worker Processes peg the CPU's again. (Which most times only takes a few minutes after IIS has been reset.) We have done multiple new builds/WSUS installs as described above and each time we have the same issue with the IIS Worker Process pegging the CPU's.

    When this occurs we see the following error in the event logs:

    The WSUS administration console was unable to connect to the WSUS Server via the remote API.
    Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists, try restarting IIS, SQL, and the Update Services Service.
    The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console.

    The IIS worker process that is causing this is the WSUSPool (process id: 7052)

    Does anyone have a solution or work around to fix this issue?

    Additional Note: Previously we were using WSUS 3.0 on Windows Server 2008 for several years and never encountered this issue.

    • Edited by USI.TRiz Tuesday, September 1, 2015 2:20 PM
    Monday, August 31, 2015 8:56 PM


  • I seemed to find a solution that worked for us. In IIS Manager 8.5 navigated to Application Pools then select WsusPool and select Advanced Settings... In the Advanced Setting window scroll down to Recycling. Originally the Private Memory Limit (KB) was set to 1843200, I changed that to 0. Once the change was made, I recycled the WsusPool. The IIS Worker Process quit spiking and the WSUS console began working without issue or crashing.
    • Marked as answer by USI.TRiz Wednesday, September 2, 2015 4:21 PM
    Wednesday, September 2, 2015 4:21 PM

All replies

  • Hi,

    we have the same problem (Windows Server 2012 R2 -> WSUS 6.3.9600.16384 )!
    I try to install the server (including the WSUS) new.
    Again and again the same problem.

    Does somebody has any idea?

    • Edited by Schneuer Tuesday, September 1, 2015 2:43 PM
    Tuesday, September 1, 2015 2:42 PM
  • I seemed to find a solution that worked for us. In IIS Manager 8.5 navigated to Application Pools then select WsusPool and select Advanced Settings... In the Advanced Setting window scroll down to Recycling. Originally the Private Memory Limit (KB) was set to 1843200, I changed that to 0. Once the change was made, I recycled the WsusPool. The IIS Worker Process quit spiking and the WSUS console began working without issue or crashing.
    • Marked as answer by USI.TRiz Wednesday, September 2, 2015 4:21 PM
    Wednesday, September 2, 2015 4:21 PM

  • Yes, I have already made it.
    The WsusPool seems now to keep alive.
    But the "IIS Worker Process" needs a lot of memory! about 7GB RAM! And the total CPU utilization is also very high (above 90%). "IIS Worker Process" about 50%.
    Is this normal for WSUS 6.3? Maybe is it the first initialization (eg database)? If so, how long time consume this init process?
    The SQL Server (Standard WID) requires almost no RAM?
    Thursday, September 3, 2015 7:06 AM
  • Yes, our IIS Worker Process also takes a lot of memory as well (about 4GB) but the CPU utilization calmed down and began running under 10% once all of the systems reported in and the WSUS system received status reports from them. Once I applied what appears to be the fix, for the first 24 hours our WsusPool IIS Worker Process ran at a CPU utilization around 50% while at the same time the SQL process was running about 30% CPU utilization. (Our SQL instance in this case is only using about 1GB of memory, much lower than the WsusPool IIS Worker Process.) From what I've experienced this all seems normal when WSUS is first initialized and put into production. Once all systems reported in and the synchronizations were completed the IIS Worker & SQL process seem to average well below 10% CPU unless systems are hitting WSUS, then both the IIS Worker & SQL process will raise to around 20-30% for a short time but then return back to less than 10%.
    Thursday, September 3, 2015 3:30 PM

  • Works unfortunately still not!

    I have now given the virtual server 8 CPUs and 12GB RAM.
    The IIS worker process soaks up all the RAM (more than 11GB), and then the Windows Internal Database (WID) process is stopped with the error message:

    Event ID: 701
    There is insufficient system memory in resource pool 'internal' to run this query.

    The WSUS 6.3 on a Windows Server 2012 R2 is horrible !!!!

    Does somebody has any idea?
    Saturday, September 5, 2015 1:27 PM
  • Being we did many many many new installs of WSUS 6.3 on Windows Server 2012 R2 before we could figure out all the issues to get it to work I have to agree with you Birnbauer, it's horrible. With all of the MS products I've dealt with over the decades, WSUS 6.3 on 2012 R2 is about the worse I've encountered. I think MS really dropped the ball before the end zone on this one! In addition to resetting the Private Memory Limit in IIS for site recycling (as noted above) We also discovered that permissions were not set correctly on many of the folders for the WSUS admin site. The account NT Authority\Network Service has to have Read rights on many directories but these permissions were not created or set during the install of the WSUS roll on the server. It took us several installs and many days of research to figure this out as there seems to be very limited resources for WSUS 6.3 out there. I used the following links to decipher and figure out the permissions issues. I hope these can help you :

    Permissions on WSUS Directories and Registry Keys:

    Verifying WSUS Server Settings:

    Tuesday, September 8, 2015 2:18 PM
  • This seemed to help us by modifying the setting on the WSUSPool application pool in IIS.  We were unable to connect to this node until this change was made, as the pool would stop and CPU utilization was consistently spiking at 99%. Thank you for this, CPU utilization is still fluctuating between 70%+ - 99%.
    Wednesday, September 23, 2015 4:19 PM
  • This was the exact issue for me as well. While I understand what this does, I'm wondering why it isn't sufficient for WSUS to function, and why it isn't mentioned in the setup documentation

    And rather than 0 (unlimited), I wonder what the correct limit might be (even if it needs to be calculated), since 0 might be considered a problem. I'd rather have it set with an upper bound limit, rather than infinite. 

    Monday, October 26, 2015 4:48 PM
  • I am fighting this issue as well. I tried setting the Directory permissions and also the recycling private memory limit to 0. It worked for a bit but now I can't open the console anymore. I originally had this come up on our 2008 R2 system so i built a new server with 2012 R2 and WSUS 6.3. Same thing. WSUS had been working for years without issue and now it suddenly breaks. Grrr...


    Monday, October 26, 2015 7:03 PM
  • Server 2012 with all MS updates, WSUS 6.2.9200.16384 console with ~500 machines was completely unusable for us until changing Private Memory Limit from 1843200 to 0 as described here.  Total memory usage on this vm is currently hovering at 7GB out of 8GB and rising after making the change, was typically below 4GB usage prior to the change, will be tweaking further as needed.  main objective was to actually be able to perform tasks in the wsus console which was not possible until after making the change, it was either unresponsive or would crash with the usual error + reset server node screen.
    • Edited by tektotket Tuesday, May 24, 2016 9:36 PM
    Tuesday, May 24, 2016 9:35 PM
  • Changing Private Memory Limit from 1843200 to 0 worked for me too. Thanks!
    Thursday, June 23, 2016 7:56 PM
  • Thanks, This solution worked like a charm
    Tuesday, October 25, 2016 11:50 AM
  • We have this problem sinds a couple  of weeks. nothing worked. I installed an new server 2016 server with WSUS. Same problem. We have UAC disabled. After enable UAC everything is working Normaly.
    Friday, July 21, 2017 4:12 PM
  • Hi all,

    Here are the new updates that fix the problem :

    1. Windows Server 2016 (KB4039396)
    2. Windows Server 2012 R2 (KB4039871)
    3. Windows Server 2012 (KB4039873)
    4. WSUS 3.0 SP2 (KB4039929)

    New update of August 28 (today). I installed it, and it works.

    Enjoy ;)


    • Edited by Rentz Kevin Tuesday, August 29, 2017 1:50 PM
    • Proposed as answer by SPV4645 Wednesday, March 21, 2018 7:06 AM
    Tuesday, August 29, 2017 1:49 PM
  • My script will fix the problem without increasing the private memory limit (but you can also run my script to set the private memory limit using -SetApplicationPoolMemory - See examples)

    My script automates WSUS Maintenance and INCREASES WSUS performance.

    Have a peek at my Adamj Clean-WSUS script. It is the last WSUS Script you will ever need!

    What it does:

    1. Add WSUS Index Optimization to the database to increase the speed of many database operations in WSUS by approximately 1000-1500 times faster.
    2. Remove all Drivers from the WSUS Database (Default; Optional).
    3. Shrink your WSUSContent folder's size by declining multiple types of updates including by default any superseded updates, preview updates, expired updates, Itanium updates, and beta updates. Optional extras: Language Packs, IE7, IE8, IE9, IE10, Embedded, NonEnglishUpdates, ComputerUpdates32bit, WinXP.
    4. Remove declined updates from the WSUS Database.
    5. Clean out all the synchronization logs that have built up over time (configurable, with the default keeping the last 14 days of logs).
    6. Compress Update Revisions.
    7. Remove Obsolete Updates.
    8. Computer Object Cleanup (configurable, with the default of deleting computer objects that have not synced within 30 days).
    9. Application Pool Memory Configuration to display the current private memory limit and easily set it to any configurable amount including 0 for unlimited. This is a manual execution only.
    10. Checks to see if you have a dirty database, and if you do, fixes it. This is primarily for Server 2012 WSUS, and is a manual execution only.
    11. Run the Recommended SQL database Maintenance script on the actual SQL database.
    12. Run the Server Cleanup Wizard.

    It will email the report out to you or save it to a file, or both.

    Although the script is lengthy, it has been made to be super easy to setup and use so don't over think it. There are some prerequisites and instructions at the top of the script. After installing the prerequisites and configuring the variables for your environment (email settings only if you are accepting all the defaults), simply run:

    .\Clean-WSUS.ps1 -FirstRun

    If you wish to view or increase the Application Pool Memory Configuration, or run the Dirty Database Check, you must run it with the required switch. See Get-Help .\Clean-WSUS.ps1 -Examples

    If you're having trouble, there's also a -HelpMe option that will create a log so you can send it to me for support.

    Adam Marshall, MCSE: Security

    Saturday, September 2, 2017 2:26 AM
  • Microsoft have recentrly reealsed an update KbKB4039396 for widnows 10, server 2012 and Windows server 2016.

    Details can be found at follwing link.

    I hope it will fix the high CPU and client time out issue.


    Saturday, September 2, 2017 11:36 PM