IIS: Unexpected behavior in case of unhandled exception in Application_Start

Question

I'm using Windows 7, IIS 7.5.7600.16385 and currently .NET 4.6.1 is installed and we have a MVC application.

Some days ago we had some strange behavior at our application. Unfortunately a service which is called inside Application_Start was not available and an unhandled exception was thrown inside. My expected behavior was that the Application_Start() is called again with the next request or the the next request is starting directly with Application_BeginRequest() like mentioned in What happens if an unhandled exception is thrown in Application_Start?.

Unfortunately I get the following result:

In case of exception inside Application_Start() I get an error 500 at the first request. That's ok.

After this all other requests are returning the exception which is thrown at the first request. I verified it by throwing an exception with timestamp inside at my local environment. Each response contains the exception with the timestamp from first request and the HTTP answer is still 500. It has no dependency which url is called. At our code no breakpoint is hit but the IIS log show the requests. It seems that the answer is cached somewhere.

Personally I like the behavior because the application doesn't respond to the requests with undefined initialization status.

And yes I know that calling other service resources inside Application_Start() is not the best idea and we will probably remove it next time :)

My Questions:

• Is it possible to configure the behavior in case of an exception is thrown at Application_Start()?

• Maybe somebody know when this behavior was changed or does it exists already a long time?

Answer 1

Well I analyzed this scenario and search through many sites, but coould not find any info about it. However, I managed to observe so behavior:

• When unhandled error is thrown inside Application_Start then IIS returns error page and web app starts to shut down.
• During the shutdown (in my case that was 10 sec.) any new request are handled by IIS and the response is the same as in the first request. If you think about it its logical, because IIS knows that website is shutting down so its obvious that last error cause it.
• After some time application raises Application_End event to let know that shutting down is complete. After that event the next request to the website will raise Application_Start again and new response will be generated.

I don't think you can alter this behavior, because application just need some time to restart.

Answer 2

Today I had some time to check the behavior again. We introduced Serilog some releases ago and it seems that the configuration has an effect to the restarting behavior.

protected void Application_Start()  
{  
  SerilogManager.Configure(); //own class  
  using (LogContext.PushProperty(SerilogManager.PROPERTY_NAME_ComponentName, "xxx")){}    
  throw new Exception(DateTime.Now.ToString("hh:mm:ss"));  
}  

If I remove the PushProperty line from Application_Start then the restart will work without any problem. With this line no Application_End will be called.

Now I can reproduce it on private und business computer. Not sure why my demo application didn't call Application_end on my business machine last time.