Learn how to use DebugDiag after an IIS Application Pool Crash. Our IIS Support team is here to help you with your questions and concerns.

How to Use DebugDiag after an IIS Application Pool Crash

Have you been running into the following error messages under the system logs in Event Viewer?

A process serving application pool ‘%1’ suffered a fatal communication error with the Windows Process Activation Service.

A process serving application pool ‘%1’ terminated unexpectedly.

These messages indicate an application pool crash, often caused by issues within the application itself. Once the pool crashes, the corresponding `w3wp` process terminates, wiping out any cached or session-based data.

Application Pool Crash Behavior

When an application pool crashes, IIS spawns a new `w3wp` process to handle incoming requests. However, if the pool crashes more than five times in five minutes, it will automatically stop. In this case, we will see the following log entry:

Application pool ‘%1’ is being automatically disabled due to a series of failures.

This setting, called Rapid-Fail Protection, can be adjusted in the application pool’s Advanced Settings.

Capturing a Crash Dump

To identify the cause of a crash, we need a crash dump of the `w3wp` process before it terminates. DebugDiag is a powerful and user-friendly tool for this purpose.

Let’s look at how to set up DebugDiag to capture dumps:

1. Launch DebugDiag and select the Crash rule.
2. Choose A specific IIS web application pool as the target.
3. Select the crashing application pool. If the application pool isn’t listed, manually type the application name.
4. In the Advanced Configuration section, add a Breakpoint:
   • Select `Ntdll!ZwTerminateProcess` as the Breakpoint Expression.
   • Set Action Type to `Full userdump`.
   • Set Action Limit to `10`.
5. Save and activate the rule.
6. Specify a dump location with sufficient disk space.
7. Finish and activate the rule.

When a crash occurs, DebugDiag will capture the dump file.

Analyzing Crash Dumps

1. Open DebugDiag Analysis and load the captured dump file.
2. Ensure the symbol path is configured correctly. So, set the symbol path to

   srv*c:\symcache*https://msdl.microsoft.com/download/symbols
3. Run the analysis and review the generated report.

Key Details in the Analysis Report

• Thread Information: CPU time, stack traces, and exceptions.
• Exception Details: Type and cause of the crash.
• Call Stack: Analyze the crashing thread’s stack trace from bottom to top.
• Process Details: Up-time, process ID, and other diagnostics.

Advanced Debugging with WinDbg

For deeper analysis, use WinDbg:

1. Load the dump file in WinDbg.
2. Set the symbol path:

   
.symfix
.sympath

3. Load .NET extensions for detailed analysis:

   
.loadby sos clr
.reload

4. Use commands like `!ClrStack` to view the stack trace and `!analyze -v` for detailed exception information.

Configuring IIS for Stability

In the application pool’s Advanced Settings, modify these properties:

• Enabled: Set to `True` to stop the pool after repeated failures.
• Maximum Failures: Default is `5`.
• Failure Interval: Default is `5 minutes`.

Also, configure exceptions, breakpoints, and events to capture specific scenarios like unhandled exceptions or process terminations.

Publishing Applications on IIS

1. Configure the project properties to use the Local IIS Web Server.
2. Test the application under load to simulate crashes.
3. Use DebugDiag to collect and analyze dumps.

[Need assistance with a different issue? Our team is available 24/7.]

Conclusion

DebugDiag and WinDbg are invaluable for diagnosing IIS application pool crashes. We can pinpoint the root cause and apply fixes to ensure stability by capturing and analyzing crash dumps.

In brief, our Support Experts demonstrated how to set up Sendmail with ClamAV and MILTER Support.