Ramblings & Controls from a .NET Addicted Freak!

Kevin Gearing's Blog

ASP, w3wp.exe, Disappearing Memory and McAfee VirusScan Enterprise (Again!)

Following on from my post back in 2005 (ASP.NET, w3wp.exe, 100% CPU Usage and McAfee VirusScan Enterprise) I recently noticed a particular Web server "drinking" what appeared to be an excessive amount of memory.

In fact I was seeing < 100MB physical memory available and the page file usage at approximately 9-10GB on a server that currently has 4GB of RAM and that isn't normally stressed at all.

As this server hosts a number of Web sites in seperate application pools firing up Task Manager revealed some interesting results. I could see most application pools consuming 8-10MB of RAM each, some consuming 30-40MB, but quite a few consuming > 100MB with a couple consuming over 150MB.

I started to tie the application pools back to the individual Web sites and look at the type of content that they were serving, whether it was static or dynamic, ASP, ASP.NET or PHP, whether they were using Access, MySQL or SQL Server databases and whether they were typically busy Web sites.

One thing became immediately apparent, the memory boozers were all ASP driven...

My initial reaction was to stop all McAfee services (always blame the anti-virus software first!) and to see what happened, so after doing this and a quick iisreset I fired up Task Manager again and waited... Sure enough 10 minutes later I was seeing application pools running at > 100MB.

So, thinking that the AV software wasn't to blame I spent the next hour or so checking everything else I could think of.

In the end I turned to the IIS Diagnostics Toolkit (if you haven't seen this check it out!) and dumped a couple of the w3wp.exe processes, within a couple of minutes I was staring at a report which quite obviously was pointing the finger at one of the McAfee modules that was utilising 120MB of the process. After repeating this on a few other processes, all with similar results, I then had to set about working out which part of McAfee was to "blame".

Eventually this led me to the ScriptScan setting within McAfee VirusScan, which is described as...

"ScriptScan scans JavaScript and VBScript scripts that are executed by the Windows Scripting Host.  WSH is used by Internet Explorer and Outlook.  If an unwanted script is detected it is not allowed to execute."


So a quick disable (well, actually not that quick as the AV policies are centrally managed and have to be propogated down to server level from a management console), an iisreset later and I'm closely watching Task Manager as the application pools start firing up... 10 minutes later I'm still watching... 15 minutes... time for a coffee... 30 minutes later and I'm seeing no application pools above 100MB, the vast majority at 8-20MB and the rest at 30-40MB with a couple busier sites running at 50-60MB.

Available memory has suddenly increased from < 100MB to > 2.5GB and the page file usage is down to 2GB.

Re-enabling ScriptScan proves that this "feature" is the problem...

So why is a feature related to Windows Scripting Host, interfering with a process that is excluded from scanning, when the AV services are stopped?

Well, if I knew the answer to that I could probably predict lottery numbers...

Published Feb 10 2009, 11:35 AM by dotNetFreak
Filed under: , ,


No Comments
Copyright ©2004-2007 Kevin Gearing. All Rights Reserved.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems