Site crash in production is a real pain in the ass.

Chances are extremely high that your boss wants this to be resolved by yesterday, otherwise you are so fired =\

IIS can write reasons of an application pool recycle to Windows Event Logs.

You need to find Application Pool in which you application is hosted:

And enable all options in Generate Recycle Event Log Entry:

We will use embedded into Windows Event Viewer Application. You can type view event logs in quick search panel:

The Event Viewer UI would be like:

One will get old analyzing tons of records without filters.

I recommend to show records logged during Last 12 hours, all but Verbose Event level from given Event sources:

• .NET Runtime
• Application
• Application Error
• Application Hang
• ASP.NET 4.0.30319.0
• Windows Error Reporting
• WAS

HINT use Page Up/Down keyboard buttons to avoid spending a few minutes on scrolling.

Checking 4 records one by one from image has narrowed the problem to the following exception:

Exception: System.Exception

Message: Tuesday strike, sorry.

StackTrace: at SitecoreUtils.StartupProcessor.b__7(Object o) in e:\8.2\code\Sitecore\Custom\SitecoreUtils\StartupProcessor.cs:line 92

We can inspect StartupProcessor code more precisely, find faulting code (why did strike take place on Tuesday), and become a white knight who resolved complicated problem.

Under some circumstances ( f.e. not replying to Ping ), IIS/WAS will recycle application, and shut application down if number of failures exceeded maximum allowed count per interval.

A sample WAS message with Warning level:

A process serving application pool 'your_pool' suffered a fatal communication error with the Windows Process Activation Service. The process id was '13728'.

Or with Error level showing too many failures:

Application pool 'your_pool' is being automatically disabled due to a series of failures in the process(es) serving that application pool.

Thereby a memory snapshot during crash is needed.