This problem still remains in all versions of 4.x from only a single user browsing the site on Win2k, Sql2000 (Does not happen in 3.x):

6/16/2006 8:59:14 PM   Application Started        ... Server Name: DELLHOME

6/16/2006 8:58:43 PM   Application Shutting Down        ... Server Name: DELLHOME

6/16/2006 8:56:24 PM   Application Started        ... Server Name: DELLHOME

6/16/2006 8:55:52 PM   Application Shutting Down        ... Server Name: DELLHOME

6/16/2006 8:54:49 PM   Application Started        ... Server Name: DELLHOME

6/16/2006 8:54:08 PM   Application Shutting Down        ...

I think I may have narrow down the cause of these application restarts.  Using the technique published here: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx

I have captured the reason for the shutdowns:

shutDownMessage=Overwhelming Change Notification in C:\WINNT\Microsoft.NET\Framework\v2.0.50727\Config
CONFIG change
CONFIG change
HostingEnvironment caused shutdown

shutDownStack=   at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at System.Web.HttpRuntime.ShutdownAppDomain()
   at System.Web.Configuration.HttpConfigurationSystem.OnConfigurationChanged(Object sender, InternalConfigEventArgs e)
   at System.Configuration.Internal.InternalConfigRoot.OnConfigChanged(InternalConfigEventArgs e)
   at System.Configuration.BaseConfigurationRecord.OnStreamChanged(String streamname)
   at System.Web.Configuration.WebConfigurationHostFileChange.OnFileChanged(Object sender, FileChangeEvent e)
   at System.Web.DirectoryMonitor.FireNotifications()
   at System.Web.Util.WorkItem.CallCallbackWithAssert(WorkItemCallback callback)
   at System.Web.Util.WorkItem.OnQueueUserWorkItemCompletion(Object state)
   at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state).

Maybe someone in the coreteam can make sense of this info..

So the theory as explained in that forum thread...

Basically, ASP.Net 2.0 runtime uses a FileSystemWatcher to monitor each subdirectory in a web app's root folder. It not only picks up files that got modified, but also files whose last access time changed. If the changes in the folders reach over a certain threshold, ASP.Net will initiate a new deployment. In ideal world, this will work perfectly.

The problem is the files and directories are constantly accessed by many processes (including IIS itself, NAV and other Windows services). We have noticed that a file can be accessed many times in seconds. And the Win32 FileSystemWatcher base has a pitiful small event buffer. At the time that the files' last access times got bombarded, FileSystemWatchers pick up too many change events almost at the same time. It's buffer simply overflowed. And exception is thrown from ASP.Net runtime (not from an individual web app). And IIS/ASP.Net catches the exception and has to reload the web app.

Note that the web app shutdown is not caused by the changes in the file system, it is because of the FileSystemWatcher's buffer overflow...

...sadly, what this means 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.

So is this fact or fiction?