Got Exceptions? AppHub Windows Phone Application Crash Reporting


Any developer will tell you that debugging applications in production environments presents them with some unique challenges and applications on Windows Phone are no different. 

With the new version of the AppHub developers portal debugging exceptions occurring within your applications on phones out in the wild just got a little easier. AppHub now allows registered developers to explore the relative health of their applications by seeing the recent crash count and then exploring the exceptions behind those crashes.

Opening the AppHub you’ll now see a section entitled App Highlights which lists your applications and their recent downloads as well as crashes.

AppHub Crash Reporting 1

AppHub – App Highlights showing most downloaded applications as well as associated crash count.

Windows Phone Stopwatch, for example, has experienced 34 recent crashes (with nearly 50,000 downloads total) and the details of these exceptions can be accessed by clicking on the crash count. If you inadvertently click the name of the application it will take you to the application summary page instead of the crash count page.

Within the crash count page you can see a graph detailing the crashes within the application over time or see crashes within all of your applications at one time. What is most useful however is the ability to then download details of these crashes within an Excel spreadsheet.

AppHub Crash Reporting 2

AppHub – Crash Count showing graph or recent crashes by application.

If you then download the spreadsheet you’ll then be able to access the level of detail necessary to further investigate the exceptions behind the crashes such as the exception message and associated stack trace.

An example spreadsheet containing details of exceptions is shown here:

StackTraceData

Microsoft Excel Spreadsheet containing exception details.

If you then download the spreadsheet you’ll then be able to access the level of detail necessary to further investigate the exceptions behind the crashes such as the exception message and associated stack trace.

You’ll most likely want to explore the stack traces of exceptions and therefore you’ll want to enable the Wrap text option (see below) for that column within the spreadsheet.

WrapText

Microsoft Excel Format Cells allows the stack trace to be more readable if the Wrap text option is enabled.

With the Wrap text option selected the stack trace information is now more readable as shown in the following spreadsheet.

StackTraceData 2

Microsoft Excel Spreadsheet containing exception details.

Comments (2)

  1. As a developer, I appreciate the crash count and graphs available in the app hub.  Unfortunately, I feel the detail provided in the downloadable spreadsheet is almost useless to me because it lacks a couple of very important pieces of data.

    1 – App Version – I have made updates to my app, but when I download the spreadsheet, I have no idea which entry is tied to which version of my app.  Did my fix not work, or did someone not update their copy and is still using an older version?  Each entry in the spreadsheet should indicate the app version being reported on.

    2 – Exception date – On a related note, if app version information is not available for reporting, at least include the exception date for each entry.  When looking at my exception spreadsheet, I can't even tell if the first entry is the most recent or from several months ago.  That might help me determine the likely release version associated with the exception.

    3 – Report date range – In the app hub, we can change the exception graph duration from the default of one month.  But I think when we download the excel spreadsheet, we get some preset range of dates (all dates?) rather than what was set for the graph.  If the graph date ranges could apply to the generation of the exception report, we could at least indirectly infer which app version is being a problem by narrowing the report scope around our release dates.

    Although reasonably functional, I think the app hub (even with it's redesign) has a long way to go.  For instance, when I want to look at sales, I get relatively little information out of the app hub.  Fortunately, I have an account at http://www.mopapp.com which does a great job of refining download and sales data.  I think the App Hub team might do well to take a look at mopapp.com and the capabilities and UI they provide.  I know their focus is analytics, but take a look at their usability and reporting detail.

    Another UI example is when a developer would like to see his global reviews.  In App Hub, we need to select each country individually and wait for screen updates to see if any posts have been made in that region.  Instead, I use a windows phone app called AppTracker that gives me a quick summary of review counts and recent changes in a single glance.  mopapp.com also provides access to reviews filtered by date which is nice (although they don't provide region filtering).

    Anyway, just some thoughts for the next interation of app hub.  Keep up the improvements!  

    Steve

    PS – Sorry if this is a repeat post as my initial post didn't seem to take at least on my screen…

  2. Mick says:

    How do you interpret the stack trace?

    What is the offset?

    Am I mistaken or are there no actual details of the type of exception being thrown?

    Have to agree with Rayzzor, as a developer I don't think there is enough information for a developer to be able to make a fix and know with certainty they have fixed the problem.