If you are a developer with applications published in the Windows Store for Windows or Windows Phone, then you have probably come across crash reports. These reports include basic information on the crash and a crash dump file for you to look at. Since this is an unexpected termination of your application, it is imperative to understand why the crash occurred. However, we see quite a few questions come into support with questions on what to do with the triage dump provided in the report. This blog will walk you through how to set up an environment you can run triage dumps through, which may provide actionable results for the developer to fix their application.
Setting up your Analysis Environment
Our environment will use a DebugDiag 2.0 automated crash dump rule to analyze the dumps provided to the developer. The complete source code for this rule is provided as part of this blog. To set up this environment we have to complete the following 3 tasks.
Download and Install DebugDiag 2.0
Download and Install DebugDiag 2.0 from the following location:
There is an x86 and x64 installer. Choose the version that matches your computers CPU architecture and use the default options.
Install the Debugging Tools for Windows
This step is required as the DebugDiag 2.0 script we develop requires a debug extension from the Debugging Tools for Windows installation. To install Debugging Tools for Windows we have to run the Windows SDK Setup and choose the Debugging Tools For Windows option. Start the install by clicking the following link:
During the installer only choose the debugging tools for windows:
This will install the Debugging Tools for Windows to the following locations:
C:\Program Files (x86)\Windows Kits\8.1\Debuggers\x64
C:\Program Files (x86)\Windows Kits\8.x1Debuggers\x86
After the install finishes we have to copy the debugging extensions needed for analyzing dump files to the DebugDiag extensions directory. The following commands can be used to do that.
Installing the Analysis Script
DebugDiag 2.0 introduced the ability to write custom debug analysis rules in C#. Rules written in C# are compiled into managed assemblies. For this blog I have written a DebugDiag 2.0 analysis rule that runs a debugger extension which outputs detailed information about the dump file. The first step is to install the managed assembly containing this rule. For this blog I included the entire DebugDiag 2.0 C# Project used to create the analysis rule as a zip file at the end of the blog. Download this zip file and extract it. Copy the \bin\Release\StoreCrashDataAnalysis.dll to C:\Program Files\DebugDiag\AnalysisRules to install the rule.
Running the Automated Crash Analysis
All of the hard work is done. Yay! Now, anytime you get a report for your Windows Store application that contains a Triage Dump you can do the following to get a simple report with a callstack and possibly additional information to assist you in determining why your application crash occurred.
- First rename the dump file from triagedumpname.hdmp to triagedumpname.dmp. This is so the DebugDiag analysis engine can open it. This will be fixed in future versions of DebugDiag.
- Start the DebugDiag.Analysis.exe from C:\Program Files\DebugDiag\DebugDiag.Analysis.exe
- By default symbols will be set to download from the Microsoft public symbol server. However, you may want to add your symbols to the path DebugDiag uses to load symbols to get better stack information. To do that click the Settings Button in the upper left corner, and configure your symbol paths as shown here:
- Click the Add Data Files button and point it to the triagedumpname.dmp.
- Under Analysis Rules you should see a category named “Windows Store Analysis Rules” and one rule named “TriageDumpAnalysis”. Put a check mark next to this rule. The application should look like this:
- Click the Start Analysis button
The analysis will start. The first time an analysis is run may take a while because DebugDiag will download symbols from the Microsoft Public Symbol servers. Once it is complete you should see a report launch in your web browser. If you do not you can go to the following path to look at the report:
Here is an example of what the report should look like:
In this case there are a few key items to look at in the report. The Exception address and the exception code. This means the crash occurred in the following code:
Windows_Networking_BackgroundTransfer!Microsoft::WRL::Details::RuntimeClass 00007ff9`f191f1bc f00fc15810 lock xadd dword ptr [rax+10h],ebx
And the Exception Code is c0000005 (Access Violation) with the indication that it attempted to write to address 00000010.
The first thing that probably comes to a developers mind is, Microsoft’s code is broke. I have worked in support for 16 years, and most of the time, even when the crash occurs in a Microsoft component that is actually not the case. Don’t get me wrong, our code does have bugs and we get those reported as well and work to fix them. I just want folks to keep in mind ,when reviewing these reports, that even though it is failing in a Microsoft component it might be an issue with the way the application is using that component. In the case of this report it was an issue with how the application was using the Background downloader.
This blog is intended to make it easier for application developers to get information from triage dumps provided in the developer dashboard. It is also recommended to read the Windows blog on Understanding and Resolving failures in Windows Store Apps. Until next time, have fun coding!
Don’t forget to follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.
– Bret Bentzinger(Microsoft) @awehellyeah