ASP.NET v2.0 - AppDomain recycles, more common than before

I stumbled across a very interesting find yesterday morning and Todd Carter confirmed it by sending a link to his blog entry.  (it's a good read)

First let me cover briefly what an AppDomain is. ASP.NET (.NET Winforms too but I won't cover that here) starts and runs within a sandbox called an AppDomain. Each Application on a server will run its own AppDomain which allows separation between different parts of the site for better security isolation and availability. If a folder is marked as an application, it will live within a different AppDomain than the root of the site. This information is not easily seen in IIS6 and earlier versions of IIS, but AppDomains are there just the same.

What this means though is that if the AppDomain is restarted, then there is a performance hit while the AppDomain is started up and pages are recompiled on their first hit. Furthermore, session state that is running In-Process is lost. In-Process, or "InProc" session state is the default setting.

In ASP.NET v1.x, there is an AppDomain restart when global.asax, web.config or anything related to the /bin folder is 'touched'. By 'touched', I mean renaming, creating, or updating the file in any way. And of course an IIS6 application pool recycle or a restart of IIS would cause the old AppDomain to shut down and a new one to start. This all made sense because those were application files and any change to them would make significant changes to the running AppDomain.

While troubleshooting an unrelated issue on a v2.0 site yesterday, I noticed that there was an AppDomain restart simply by creating a non-application folder. Through further testing I found that adding folders, deleting folders and renaming folders caused the AppDomain recycle. Furthermore, if many dozen files were added in short succession to each other, that would also case the same restart. Of course the app_{folders} will cause a restart, and that makes sense, but completely non-application related folders also cause this same behavior.

It turns out that this was a purposeful change with v2.0 and was done so that stale content doesn't remain in place after a significant change. I guess there were enough situations where that happened that they changed the situations that caused an AppDomain recycle to be far more aggressive than v1.x of the framework.

What does this mean? Unfortunately quite a bit. People that used to make quick updates to their websites thinking that it wouldn't affect performance of unrelated parts of the site now need to consider that any changes to folders will cause the entire AppDomain to be restarted. Also a large number of changes to files within the site will do the same. (I'm not sure at this time the threshold that triggers a restart based on file changes). This will immediately kill all InProc session state and cause a performance hit on the site.

I'm normally not one to complain about .NET, there are so many great things to say about it. But in this situation, I think this is a step backward. At this time, there is no way to disable this aggressive response to file and folder changes. The linkd.exe solution that Todd gave in the blog entry is a solution, but it's not an easy one and isn't reasonable in many situations.

I don't have a good solution for this, but at least I am now aware of the affects of various file and folders changes and can watch out for that when making site updates or troubleshooting sites.

Added later: It's now possible to disable file change notifications completely by making a registry change and restarting IIS.   The downside to disabling it completely is that whenever you make a change to web.config or other system folder, you will need to restart the app pool manually, otherwise the settings won't take effect.  See the registry information section of this page: 

This forums thread is another good one and covers how to make a global.asax post that will disable just some notifications while leaving the core ones in place.  I haven't tested it personally but another person on the thread confirmed that it worked:

Another potential option is to delay an AppDomain recycle when pushing changes to the server so that you can get a full upload of your content before it starts recycling.  Otherwise you may get rapid recycles during deployment:  Search for maxWaitChangeNotification and waitChangeNotification.

Tess has a good post on AppDomain recycles now too which is a good read:


  • Besides losing the Inproc Session state on a recycle, Do you lose all of your cached items as well?

  • Yep, the cache is lost as well.

  • This is a very intresting observation. in fact a very trouble some one too.. many times there are temp files like XML/XSLT that get generated and deleted on the fly for applications (like file system based cache's etc.) Now if these were to trigger an app domain restart that would really suck!

  • This seems like it would cripples systems that allow users to manage files through the site, or systems that allow uploads/directory creation of any form.

    Does this happen only in the new model, or does it also occur in the recently released web project model as well?

  • Yes, it can have a crippling affect on the site. In fact that is how I discovered it. Changes to a small number of files won't hurt anything, but if there is a large number of file changes, I believe 15 is the magic number, in a very short time, it will cause this. "Any" folder changes will cause this.

    I'm still working with Todd on a particular case and he just let me know that the App_Data folder is excluded from the FCN (file change notification) checking, so that is a safe place to put things that change often. I tested and confirmed this is the case.

    This is a function of the v2.0 framework so as far as I know the web project model doesn't change this at all. It will happen there as well.

  • Hopefully this is documented somewhere or another. Otherwise, you have to love magic settings and values like this. Anyway, who would ever create folders and files while the app is running? :) That's crazy talk, I'm sure only 65-85% of app devs do it.

  • I developed an application using Version 2.0.50215 of the Framework.Using a combination of command line aspnet_regiis.exe -ua and aspnet_regiis.exe -i I uninstalled all version of the framework and reinstalled version v2.0.50727. I keep getting the Server Application Unavailable message in the browser.

    In the event log I get a message with Event ID:1088 and a message of "Failed to execute request because the App-Domain could not be created. Error: 0x80004005 Unspecified error ". What could be the cause? Been on it for 3 days

  • Thanks Scott,

    I hate giving up but I had to.After countless permutations and combinations of varying installs and uninstalls,I just reinstalled Windows Server 2003 and progressively installed all my programs.Glad to say I am back at Version 2.0.50215 and Visual Studio 2005 Beta. Planning to buy the release version and install that.

    Latest problem is getting constructing a TreeView dynamically and programmatically from an HttpHandler.Keep getting an "Object Reference not set to an instance of an object" error. But I guess this is not the forum for that.......

  • OldManChild, sometimes it comes to a reinstall after working with Beta builds. If you've exhausted all your options and it still doesn't work, doing a reinstall is a completely acceptable solution.

    My suggestion on the TreeView is to use a bare bones sitemap and comment out as much of code as possible until you've isolated the exact line that is causing it. That's about the most common, most generic error around, so it's just a matter of trial and error to find out what is throwing it.

  • Thanks once again Scott,If you say so then I am at peace with myself.Will take your suggestion and see how it goes.

  • Any news on how to configure ASP.NET 2.0 to NOT restart the AppDomain if files change? I would prefer to not have to relocate my logs, files, temp, and xml directories outside of my web application. Anyone heard of the web.config setting "numRecompilesBeforeAppRestart"? What I would like is the setting "numFileChangesBeforeAppRestart" which I would set to infinity, because I change files all the time.

  • Hi Phreshview. I don't believe there is a solution for it at this time. That appears to be the offical word from MS. A numFileChangesBeforeAppReset property would be a great idea. The other thing that would be great is to be able to specify which folders will cause the app reset and have all others be ignored.

  • Very good blog entry.

    I was developing my first app in ASP.NET 2.0, and I was wondering why I'm constanly loosing session. Now I know.

  • I have an application with a filemanager and now I get the session timeout behavior whenever a directory gets deleted/renamed! What im curious is how DotnetNuke solved this problem since it uses also a filemanager. Anyone knows what is DNN using to get over this "bug"?

  • This is extremely annoying; I actually went back to 1.1 because of this. A reasonable solution would be for Microsoft to allow for a config file that specifies which dirs/files cause a restart rather than just restarting at any change. It's actually unbelievable that they would even consider something so stupid.

    If a config solution ever becomes available will you post it here? Thanks for the info btw – although I knew about it, it’s good to see that others are pushing for a solution as well.

  • I am having an issue where my session state is lost on my shared hosting environment. Locally, I log in and my session remains active. However, on the my shared hosting site, not long after I log in and store a session variable, I seem to lose the session variable fairly quickly.

    My application does allow the uploading of files to the web server, however, the site is not launced yet and no one is using it. I don't upload any files. I only log in and go to a page over and over again that checks for my session state. Usually in under 5 clicks, it seems to lose my session info and redirects me to the login page.

    Any ideas?

    On an unrelated question, it seems that when I deploy my ASP.Net 2.0 application, I have to copy my .CS (code behind) files to the web hosting server in order to get it to run correctly. This was not necessary in ASP.Net 1.1. Only the compiled DLL files were needed. Is this something new in ASP.Net 2.0 or is it something wrong with my configuration?

    Thanks for your help.


  • Compiled Solutions / workarounds so for

    Sol 1: Use out of process session state.
    Sol 2: Use Directory Junction between seperate Web folder and content folders
    Sol 3: Disable FCNotifications in ASP.NET2.0 by adding DWORD FCNMode =1 under
    HKLM\Software\Microsoft\ASP.NET key

    Sol 4: Use .NET framework 1.1.4322 in side by side

    Most of the time solution 4 seems to be easy way out till MS releases fix for this problem.

  • I am having the issue at the time of login into my project/application. it gives an exception like:
    "system.threading.threadabortexception thread was being aborted" this and it redirects to that page which I am requesting for. But still giving an exception.
    So please give me solution for this.

  • Hi Prakash,

    There is likely something in the code that opens a thread but doesn't have a chance to finish it. My recommendation for narrowing it down is to break the code isn't smaller chunks. For example, comment out as much code as you can and see if the issue still occurs, then continue to follow that pattern until you've determined exactly what causes this. Then it will hopefully become more clear what fix is necessary.

Comments have been disabled for this content.