A More Sensitive Method of Troubleshooting Crashes in IIS Processes with DebugDiag 1.2

 

Applies to:

 

IIS 6.0; IIS 7.0; IIS 7.5

These steps presuppose that you’ve already tried a basic crash rule with debugdiag.

 

Preliminary Steps 

 

At your next server maintenance window, open up the IIS manager (start button > Run > Open: inetmgr) and drill down to the Application Pool(s), and remove any setting which could cause an application pool to recycle unexpectedly.  

 

Note the changes you make as you make them so you can set them back later.

 

The crash rule we’re going to create will be so sensitive that even a scheduled recycle of an Application Pool will produce a crash dump.   That dump file will not be of use to us.

 

LAUNCH DEBUGDIAG

 

Launch DebugDiag (Start Button >  Programs > Debug Diagnostics Tool 1.2)

 

 

SET UP A SENSITIVE CRASH RULE

 

When asked which rule type to choose, choose “Crash” and click NEXT

 

 

 

For select target type you should go with “All IIS/Com+ related processes.”   (However, if you know from the system event log events that it’s one specific iis application pool that is experiencing the crashes, you can instead select “A specific IIS web application pool.”)

 

 

 

 

Click the BREAKPOINTS button.

 

 

 

Click the ADD BREAKPOINT button.

 

 

 

If the crash is for an application pool and/or w3wp.exe, select the Ntdll!ZwTerminateProcess breakpoint.

 

If the crash is of a dllhost.exe, add ComSvcs!ComSvcsExceptionFilter.

 

If the crash is more specific to ASP.net, select the mscorwks breakpoint.

 

Set Action Type to Full Userdump.

 

 

 

Click SAVE & CLOSE

 

 

Click Next

 

 

 

 

Continue accepting the default settings and clicking next…

 

 

 

If you need the dmp files to be written to some place other than the default, select browse and give it another folder.

 

Click Next.

 

Activate the rule when you’re ready for the tool to start monitoring the IIS processes for a crash. . .

 

 

 

 

Note how the status is set to active and the userdump count is set to 0.  The userdump count should increase when a crash is detected.

 

 

 

WAIT

 

Feel free to log off the server while waiting for the crash to occur.  Since debugdiag runs as a service, you do not have to be logged into the machine.

 

This tool will monitor the iis processes, watching and waiting for a crash to occur.  When the process begins to crash, the debugger will interrupt the process temporarily, freeze that process, write out everything in that process to a .dmp file, and then allow the process to crash.

 

 

 

Preliminary Analysis of the Crash Dump

 

 

After the dump file has been created, you can switch to the Advanced Analysis tab, highlight Crash/Hang Analyzers,

Click Add Data Files

Find and select the .dmp file

And click the START ANALYSIS button.

 

[Note: you may prefer to do this on a workstation that has access to the .dmp file and access to the internet rather than do this on the web server.  It can be fairly cpu intensive.]

 

 

 

When the analysis script completes, Internet Explorer will launch and display the results.

 

 

 

Zipping the Dump

 

If you’d like to zip the dump file up to upload to a support team at Microsoft, here is a good way to do it.

Expand the debugdiag Tools menu, select Advanced Data Collection, select Create Full Cabinet file.   This will collect and compress the event logs, the .net config files, the deadlock dump files, and more into one convenient .cab file.

 

 

Create a support case with the Microsoft support and upload the .cab file to the workspace your support engineer provides.   

You can locate the .cab file by clicking the icon of the manila file folder.

 

 

 

 

 

 

 If this method does not trigger dump files when the crash occurs, you might consider trying to use WER to get the dump.