Virus Scanners and ASP.NET apps don't always mix

In a previous post, I talked about Alternate Data Streams and how some virus-scanning engines use them for tracking purposes.  When this happens, the file is changed.  It doesn't matter that the "real" data hasn't changed.  The system still knows that a change has occurred.  When this happens to a file inside an ASP.NET web site, this can cause some interesting side effects.

First, let's review File Change Notification in ASP.NET 2.0. 

ASP.NET receives a notification whenever a file in a virtual folder is changed.  This includes updates, inserts, and deletions.  When a change occurs, the application is restarted.  This causes a loss of application state, including session variables, cached data, and so on.  See these sites for more info:

https://blogs.msdn.com/toddca/archive/2006/07/17/update-deleting-asp-net-2-0-application-sub-directories-shuts-down-the-appdomain.aspx

https://weblogs.asp.net/owscott/archive/2006/02/21/ASP.NET-v2.0-_2D00_-AppDomain-recycles_2C00_-more-common-than-before.aspx

Now, let's add virus scanning to the mix.  Since some scanning engines insert tracking information inside a file's alternate data stream, and since this action can be considered a change to the file, this can cause an application restart.  Yes, that's right.  Using a virus scanner to scan your application files for viruses can cause your web application to restart.  Refer to this KB article: https://support.microsoft.com/kb/312592.

I'm seeing more of this lately, so I though I'd put the word out.  Test your virus scanner against your web applications before you place them in production.  If you have this problem, you can exclude the application folders from scanning or you can try the steps listed in this KB article: https://support.microsoft.com/kb/911272.  I'm not really happy with either solution, so I'm not making any recommendations.  However, I do urge you to perform a test before you go live.