We had an odd thing happen the other day at work. The WSUS console kept crashing for not apparent reason. It worked fine up until just now. Digging into the error message, it seemed that the WSUS console was unable to reason the WSUS service and said to check and make sure IIS & SQL we’re running. They both were.
As it turns out, in the IIS logs, there was an error about about IIS exceeding its Private Memory limit and crashing. Eventually I found this blog post:
That indicated that there was a problem with WSUS application pool. As it turned out, that app pool was in fact stopped on our server! Starting it enabled WSUS to function for a while until it crashed again, at which point the app pool was stopped again.
Per the above article, I changed the following entry to “0”:
IIS Manager->Server->Application Pools->WSUS Pool->Advanced Actions->Recycling
And changed Private Memory Limit to 0. A reboot later, and the application pool was able to access much more than the 1.8 GB it is allowed by default. However…..It was still crashing. A second option in that same blog mentioned changing the application pools to default to being 64 bit instead of the default of 32 bit.
All that was required was going IIS->Manager->WSUS Website->ISAPI Filters-> right click – edit->and change the loading order of the 32 bit vs 64 bit entries so the 64 bit option loads first.
Another reboot, and ever since then WSUS has been 100% stable. I don’t know for certain what caused this, other than we recently added some new servers to the domain for WSUS to manage as well as a new OS for it to manage patches for. Those two things combined to be enough to push it over the line and crash out of memory crashes.