What are the possible causes for IIS to throw a ThreadAbortException and recycle the worker, with IIS logging "IIS configuration change"?

Question

I started seeing errors in a .Net MVC web app hosted on Appharbor whilst a background thread was running - after careful analysis - I can't work out the cause.

Firstly, the exception I noticed is a ThreadAbortException.

However, this is really just signifying that the thread is being killed. Before the thread is killed, you can see a new worker is created by IIS and Application_Start is called on the same machine. Once the new application is up and running, IIS kills the old app and new requests are handled as expected.

At the same time, IIS logs a message of:

ShutDown Message: IIS configuration change
HostingEnvironment initiated shutdown
HostingEnvironment caused shutdown
ShutDown Stack:    at System.Environment.GetStackTrace(Exception e, Boolean needFileInfo)
   at System.Environment.get_StackTrace()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownInternal()
   at System.Web.Hosting.HostingEnvironment.InitiateShutdownWithoutDemand()
   at System.Web.Hosting.PipelineRuntime.StopProcessing()

In .Net Health Monitor Logging you get a:

Message: Application is shutting down. Reason: Configuration changed.
Event Detail Code: 50004

A quick google reveals the source code I suspect is the reason for the error:

if (!HostingEnvironment.StopListeningWasCalled && !HostingEnvironment.ShutdownInitiated) {
    // If GL_STOP_LISTENING wasn't triggered, the reset is likely due to a configuration change.
    HttpRuntime.SetShutdownReason(ApplicationShutdownReason.ConfigurationChange, "IIS configuration change");
}

source: https://github.com/Microsoft/referencesource/blob/master/System.Web/Hosting/IPipelineRuntime.cs

My first thought was to check timestamps for file changes, both in the bin folder and the main application directory - however, this error is thrown without any file changes. Given it only happens on Appharbor, I can't attach to the process and debug that way. I've also monitored memory usage, and don't see any issues there.

The source code states:

If GL_STOP_LISTENING wasn't triggered, the reset is likely due to a configuration change.

Hence, what else could be causing the error and application recycle, if the web.config / other config files aren't changing?

Answer 1

There are many reasons, which are listed by this helpful blog entry.

• Application pool settings
• The processModel element of machine.config
• Memory limit
• Request limit
• Timeout