Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
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.
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”.
I know that my SharePoint application uses the “SharePoint – 80” web application pool, so I choose that one.
In the next window, choose “Exceptions” from the Advanced Settings panel at the bottom of the window.
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.
The next window allows you to name the rule and to configure the location where the userdump file is created.
The last window asks you if you want to activate the rule.
Once we configure the rule, you can see the rule and the number of userdumps that have been generated by the rule.
To test this, I created a very simple application page that throws a new System.ArithmeticException.
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.
DebugDiag runs for awhile, and generates a nice report letting me know what happened.
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.
Intro to WinDBG for .NET Developers
WinDBG and PssCor2 for SharePoint Developers