In previous posts, I talked about using WinDBG to debug.  Another incredibly handy tool to have at your disposal is the Debug Diagnostic Tool, or DebugDiag 1.2.  This tool can be used to automatically capture a memory dump when an exception occurs.  To understand some of the tools at your disposal to troubleshoot issues, see my previous posts:

Those posts show how to read a dump file, but don’t go into how to capture a dump file.  I want to write a dump file when an exception occurs so I can see what the stacktrace for it is, the state of local variables, and what modules were loaded.  For instance, I am seeing a System.ArithmeticException in my logs, but I can’t seem to figure out where it is coming from.  It would be nice to capture a full memory dump when the problem occurs.  DebugDiag does just that.

Open the tool and click the Add Rule button and create a new Crash rule.

image

Next, select the target type.  Since I am debugging a SharePoint application, I know it is occurring in a single web application, so I choose “A specific IIS web application pool”.

image

I know that my SharePoint application uses the “SharePoint – 80” web application pool, so I choose that one.

image

In the next window, choose “Exceptions” from the Advanced Settings panel at the bottom of the window.

image

After you click the Exceptions button, you can configure a new Exception.  We want to capture a dump whenever a System.ArithmeticException occurs, so we choose Exception Code E0434F4D – CLR (.NET) 1.0 – 3.5 Exception from the list, and type System.ArithmeticException in the .NET Exception Type text box.  Finally, change the Action Type to Full Userdump so that a memory dump is created when the condition is met.

image

The next window allows you to name the rule and to configure the location where the userdump file is created.

image

The last window asks you if you want to activate the rule. 

image

Once we configure the rule, you can see the rule and the number of userdumps that have been generated by the rule.

image

To test this, I created a very simple application page that throws a new System.ArithmeticException.

using System;
using Microsoft.SharePoint;
using Microsoft.SharePoint.WebControls;

namespace ArithmeticExceptionPage.Layouts.ArithmeticExceptionPage
{
    public partial class ApplicationPage1 : LayoutsPageBase
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            throw new System.ArithmeticException("oops");
        }
    }
}

When I browse to the page, the exception is thrown, and DebugDiag sees the exception.  The Userdump Count column is incremented to 2 and the .DMP file is written to the directory that I configured.  Be mindful that the length of time required to create the dump depends on a few factors, including how much memory your process is consuming and how fast your disk is. 

Looking at the directory, I can right-click on the file and see a new shell extension to Analyze Crash/Hang Issue.

image

DebugDiag runs for awhile, and generates a nice report letting me know what happened.

image

Of course, we already knew that the problem was a System.ArithmeticException, but the resulting stack information can often give us a better idea of what is going on with the process.  And if we don’t see our problem in the generated report, we know how to open WinDBG and take a look ourselves.

For More Information

Intro to WinDBG for .NET Developers

WinDBG and PssCor2 for SharePoint Developers