Analyzing crash reports
All apps must be fully functional when they go through the certification process. (This prerequisite is covered under certification requirement 1.2.) If your app crashes or becomes unresponsive during certification, you’ll receive a certification report that contains additional files that you can use to identify what happened.
Depending on the type of error that occurred, you’ll receive either:
- A crash dump file. This file contains the most important parts of a crashed application. It’s called a crash dump file because it does not contain a full dump of the application process space. Instead, a crash dump file contains only the most critical information—such as the stack trace at the time of the crash. It also contains the list of threads, their contexts, and the memory behind their stacks.
To examine these files, we recommend that you use either Microsoft Visual Studio or the Windows Debugger Tools.
To open a crash dump file in Microsoft Visual Studio, either double-click the file or select Open from the File menu in Visual Studio. After Visual Studio loads the file, you’ll see a summary of the crash dump.
This summary includes the process name that crashed, along with the exception code and a description of the exception. You can also find a list of the modules the process loaded.
To debug the crash dump further, you need to set the symbol path and debug the file. You can find the options to do these tasks on the right-hand side of Visual Studio.
To set your symbol path
- Click on Set Symbol Paths.
- Enable the Microsoft Symbol Servers check box.
- In the Cache symbols for this directory box, type
c:\symbolsor the directory of your choice.
- Click OK.
For more information on symbols, see Find Symbol (.pdb),Source, and Binary Files.
After you set up your symbol path, click either Debug with Native Only or Debug with Mixed, as appropriate. Setting one of these options downloads the relevant symbols, after which you should see a dialog box containing more exception information:
To view the full call stack at the time of the exception, click Break, then choose whether to load the source code or show disassembly. If the symbols for your app loaded correctly, you should now see the source code of your app. This should give you the information you need to identify what caused the crash.
To open an ErrorInfo file, either double-click the file or select Open from the File menu. Here’s what a typical ErrorInfo file looks like:
ErrorDescription='thisFunctionDoesNotExist' is undefined ErrorType=3 ErrorTypeText=Reference error ErrorNumber=800A1391 SourceFile=ms-appx://microsoft.wer.tailored.faultoid/default.html Line=64 Character=9 DocumentURL=/default.html OSProduct=Windows 8 Pro OSVersion=6.2.9200.0 OSServicePack=0 UserAgentString=Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; MSAppHost/1.0) StackTraceAvailability=2 StackTrace=ms-appx://microsoft.wer.tailored.faultoid/default.html:64:9 CallMissingFunction() ms-appx://microsoft.wer.tailored.faultoid/default.html:128:1 onclick(object) StackTraceHash=d5221125b1e4d806414f07cc117c68c9 PackageFullName=microsoft.WER.Tailored.Faultoid_18.104.22.168_x64__8wekyb3d8bbwe AppUserModelID=microsoft.WER.Tailored.Faultoid_8wekyb3d8bbwe!WER.Tailored.Faultoid IsTerminal=True DependentPackageList=(null)
- The exception occurred on line 64, character 9, of the default.html file for the app.
- The exception was a reference error with description " 'thisFunctionDoesNotExist' is undefined". (The ErrorNumber value provides a numeric status for the error that can also be used to obtain additional information about the cause of the exception.)
- The stack trace at the time of the exception. This information uses the following template:
[App source file]:[Line Number]:[Character Position] [Function Name]
With this information, you can further investigate the cause of the exception in your app.
Note After your app is available in the Windows Store, you can get information about crashes and other performance issues that occur while customers are using your app.