This is the first article in the series of the articles I have planned to write on Debug Diag tool. I am focusing purely on the troubleshooting and diagnosing of the StackOverflowException in IIS Application in this article.
It is very easy for us to diagnose an issue in local debug environment. It is even easier in testing environments. But it is a different scenario altogether, when we have issues in PROD environment. Custom logging helps to investigate most of the issues in PROD, but there are scenarios where our logging fails us and this is where Debug Diag helps us.
You can download Debug Diag here.
I have created a sample MVC application and hosted it on IIS on the Server. Inside the HomeController, I have created a method that calls itself recursively infinite times.
Now when try to access the deployed website, after performing some operations website fails to load and on hitting URL again following error comes up.
This happens because Web Application Pool is stopped.
This happens because of the “Rapid-Fail Protection” setting of Application Pool that shuts down application pool after set number of failures/crashes.
Now if we check the Event Log, we see series of warnings and errors:
Warning states that Application Pool suffered some error.
After 5 warnings of about errors, Application Pool is disabled with following error in Event Log.
There is one information and error in Application section of Event Log, which gives us more detail about the issue.
Error shows, that process w3wp.exe crashed with “Exception Code: 0xc00000fd”, which means StackOverflowException.
Information log, actually shows that it was StackOverflowException and some more details about Process/Application.
As you can see, there is not much information available on where the application is falling over, so to get more details I setup Debug Diag to catch the exception of type StackOverflowException on the server.
Open “DebugDiag 2 Collection” and on “Select Rule Type” screen, select option “Crash” and click Next.
On “Select Target Type” screen, select option “A specific IIS web application pool” and click Next.
On “Select Target” screen, select the “Web Application Pool” you have deployed website on and click Next.
On “Advance Configuration” screen, click on button “Exceptions” under “Advanced Settings”.
On “First Chance Exception Configuration” screen, click on button “Add Exception”.
From the list of Exceptions on left side, select “C00000FD – Stack Overflow”. Select “Action Type” as “Full User Dump” and “Action Limit”, just leave it default.
Click on “Save & Close” and click “Next”.
On the next screen, give the rule name and dump location of your choice and click Next.
Keep default selection of “Activate the rule now” and click on “Finish”.
Here the configuration of Debug Diag is done.
Now we again try to reproduce the issue and we get the same error as above.
However, we are interested in the Debug Diag dump generated at the log folder we setup earlier. Here are the dumps generated: (5 dump file are generated as exception was caused 5 times before Application Pool was disabled).
“xx__Log.txt” and “xx__ProcessList.txt” are of not much use here, our to go file is .dmp file.
You can open dump file with either with Debug Diag tool DebugDiag.Analysis or with Visual Studio. We will see how dump file is useful when opened with Visual Studio later in this post.
When you open dump file with DebugDiag.Analysis, system does some sort of processing and presents you the report in Internet Explorer.
The report Analysis Summary section clearly shows, that StockOverflowException was caused at “WebApplication.Controllers.HomeController.GoToInfiniteLoop()”. Can’t get any simpler than this. 🙂
Plus, if one wants to take a look at the Stack Trace, click on thread number (31 in my example) at the end of error summary.
However, here comes the interesting part, we can open dump file with Visual Studio and also debug the application if source code is available on your machine. For this to work, source code should be same as the deployed application.
Action links on the right top corner helps you to debug your code. I selected Debug with Managed Only and here is the output. The Visual Studio breaks directly on the line of code where error occurs and we found the culprit.
Same way you can configure multiple type of exceptions:
You can also create the dumps for any unconfigured exception that may occur in your application. Set the respective values in “Unconfigured First Chance Exceptions”.
I will definitely keep on sharing more articles on Debug Diag, as I understand it better.
