Windows Dev Center

Reviewing app quality

The charts and info displayed on the Quality page show a summary of data related to the performance and quality of your app. We track the percentage of customers who are experiencing failures (crashes, unresponsive events, and JavaScript exceptions), the failure rate, and the most common causes of the issue.

Note  In order to view app quality data, you must enable telemetry data collection for your account. If you have not been not collecting telemetry data and then enable it, it might take several days before you start to see any data.

Accessing Quality reports

To view the Quality page:

  1. Go to your Windows Store Dashboard and find the app.
    Note  You can view your app's quality only if the app is listed in the Windows Store and appears below the Apps in the Store title.
  2. Click Details in the app's tile to see the App summary page.
  3. In the left menu, click Quality.
  4. Review the filters at the top of the page and set the criteria that you want to review.
    Note  If you have published separate packages targeting both Windows 8 and Windows 8.1, we show your quality data for Windows 8.1 by default. You can change this filter to see your quality data for Windows 8.

Three different types of failures can be tracked through the Quality report.

  • Crashes: When an app exits unexpectedly, a crash is recorded along with the location in the program code where the crash occurred. The chart displays the average crash rate per computer per day. The table lists the most common places where a crash occurred and for which we've collected data.
  • App unresponsive events: When an app stops responding to user input, an unresponsive event is recorded. The app's module in which the event occurred is also recorded. The chart displays the average unresponsive rate per computer per day. The table lists the most common places where the app has become unresponsive and for which we've collected data.
  • JavaScript exceptions: When a JavaScript exception occurs (in an app that uses JavaScript), it is recorded and tabulated. The chart displays the average rate that these exceptions occurred per computer per day. The table lists the most common exceptions for which we've collected data.

Failure rate data and most common failures

The failure rate data comes from a sampled set of customers. This sample is designed to closely represent the actual customers who have installed the app, and is not limited to those who have experienced failures. The data only considers failures that occurred during the initial period of usage, since the measured reliability of an app tends to stabilize over time and after a certain amount of usage we see very little variation in the failure rates.

Note   You may see a warning that the sample set is not statistically significant. This means that we have not yet obtained enough data yet to consider it an accurate representation of your app's quality and performance.

The data for the most common failure list comes from all customers of your app. If a majority of these customers have not met the usage requirements due to failures, the failure rate will be 0, but you will still see the most common failures for the app, as shown here.


Understanding the top failures seen by your customers enables you to fix them and publish updates to your app in the Windows Store.

Understanding crashes and hangs

For crashes and hangs, we show you the five most common failures from your latest app release. The Count represents the total occurrences of the failures among all customers of your app. The Download link points to a .cab file containing the process dump for that failure (if you built your app's .appxupload package with debugging data). You can download the .cab file and open it in the Microsoft Visual Studio debugger to get more details about the problem. For more information, see Debugging and testing.


A failure is uniquely identified by a failure name. Here is an example of a Failure name for hangs and crashes:


The failure can be broken down into the following elements:


Problem class


Error code





You can determine the reason for the crash or hang in your app by downloading the associated .cab file, which contains a process dump associated with the failure. You can get the stack traces and other details for the failure from the process dump.

In order to process the .cab file and extract the stack traces, you'll need:

  1. WinDbg.exe installed on your machine. WinDbg.exe is the recommended debugging tool to get stack traces from the process dump. If you do not have WinDbg.exe already, you can get it here.

  2. The symbols for the application. To get the stack traces from the process dump, you should have the symbols corresponding to the current version of your app in the Windows Store.

Getting stack traces for crashes and hangs

These steps are not intended to be a thorough debugger tutorial, but they should enable you to get the stack traces for failures in your app.

  1. Click the Download link next to the failure name for any associated problem with your app (crash or hang). Let's assume that the failure name is:

  2. Save the .cab file to a location of your choice.

  3. Launch WinDbg.exe.

  4. On the File menu, click Open Crash Dump.


  5. In the Open Crash Dump dialog box, point to the location of the file you saved, then open it.


  6. On the File menu, click Symbol File Path, then type the path for the symbols corresponding to the version available in the Windows Store. Check the Reload check box, then click OK.


    If you want to point to the publicly available symbols from Microsoft (for binaries other than that of your app), use the following format for the symbols path:

    Srv*;<<your symbols path here>>

    If your symbols path is c:\symbols, the equivalent path per the above guidance would be:

  7. In the prompt on the Command Window, enter:

    !analyze –v

    If there are any errors and warnings about binary files, it means that the debugger was not able to find the correct symbols for your app. You should identify the correct path for where the symbols are stored and add it as described in step 6.

  8. The stack trace is displayed in the command window as follows:


    You can see from the call stack that the failure was a "divide by zero" exception in a function called DivideByZero in FaultoidEx.Engine.dll. This corresponds to the failure name we saw in step 1, helping you to understand the failure and what you can do to fix it.

Understanding JavaScript exceptions

The JavaScript exception rate and most common JavaScript exceptions are applicable only to apps that use JavaScript.


By default, we first list the top five failures for JavaScript exceptions. Clicking Show All button expands this list to show up to fifteen failures. Here is an example of a list entry for a JavaScript exception:

WinRT error_8007007E_msappx://Contoso.ContosoApp8wekyb3d8bbwe/ContosoApp/program.js!scenario1Run

The JavaScript exception name is broken down into the following elements:



WinRT error






Getting stack traces for JavaScript exceptions

You can check the reason for the JavaScript exception associated with a failure by executing the following steps:

  1. Click the Download link next to theJavaScript exception name associated with your app.

  2. Save the .cab file to a location of your choice.

  3. The .cabfile contains a file with a name starting with ErrorInfo. Extract this file and save it to a location of your choice.

  4. Open the ErrorInfo file from the location chosen in step 3 using Notepad.

  5. The ErrorInfo file has the stack traces associated with the failure. Here's an example:


    In this example, the error was due to an undefined function. The call stack leading up to the failure is also in the ErrorInfo file.


All dates and times used in the analytics reports, charts, and downloaded data are shown in UTC.

Related topics

Releasing improved versions
Collecting telemetry data from your apps



© 2015 Microsoft