I have to admit the Exchange 2003 Outlook Web Access has me a bit spoiled. It always seems to be there – day in, day out. So when a report of OWA not loading came in, I was surprised. Where to begin?
I really don’t like rebooting Exchange. The usually ever-reliable attempt to restart the IIS service didn’t bring it back to life and nothing suspicious was in the event logs, so our resident webmaster took a look in the IIS logs and found several “connections refused” errors in the %WINDIR%\logfiles\httperr\httperr1.log.
This gave me something to start with and after some research I found that those type of errors in the HTTPERR log often point to a non-paged pooled memory leak. As per the Troubleshots MSDN blog:
While there are many possible causes for the “Page cannot be displayed” error, there is only root cause which causes the http.sys driver to begin refusing client connections–a depletion of non-paged pooled memory, an NPP leak. The HTTP.sys driver was new with Windows 2003, is a kernel mode driver, and, at the risk of splitting hairs, is technically not part of IIS 6.0. This distinction is important in troubleshooting. When http.sys refuses to hand connections to IIS a “Connection_refused” or “Connections_refused” will be logged in the httperr log (C:\WINDOWS\system32\Logfiles\HTTPERR) rather than the IIS logs.
At this point, I didn’t want to just reboot the server to clear the memory leak. I wanted to know what was leaking. Using Task Manager, I added the columns for the Non-paged Pool and the process for “NPSrvHost” shot to the top of the list with almost 10x the average memory consumed compared to the other processes. NPSrvHost belongs the NetPro Compliance Agent. I stopped and restarted that service and memory usage returned to a normal range.
Finally, I performed and IISRESET and the OWA service came back to life.