Crash reports help you certify your Windows Store app
As the Windows Store continues to grow and offer app builders a significant market opportunity, we want to clarify the app certification process, so you know what to do to get your app into the Windows Store. We also want you to know how to proceed if your app fails certification.
Most commonly, an app fails certification because it crashed or didn’t respond during the certification process. Due to any number of reasons an app might crash, it can be hard to know what happened and how to fix it, especially if you don’t experience the crash locally.
Starting on Monday, 1/28, when an app fails certification for either of these reasons, we’ll send a crash file with the certification report. You’ll be able to see exactly what happened during the crash, which should help you identify and fix the issue.
These crash files come in one of two formats:
- A crash dump (.dmp) file contains critical info about the crashed application. These can be opened in Visual Studio 2012 or with our Windows Debugger Tools.
- An ErrorInfo (.txt) file contains info about crashes related to an unhandled JavaScript exception.
Both files provide info that can help determine what happened when the app crashed or became unresponsive. Once you’ve fixed the problem, you can resubmit your app.
We’ve updated our Dev Center to include info about analyzing these crash reports. Check it out to learn more about what these files contain, along with specific steps to open and review their contents. And don’t forget, you can also access crash data for published apps through the Quality reports available in your Windows Store Dashboard.
--Dave Smith, Principal Test Manager
Comments
Anonymous
January 28, 2013
This is waaaaaaaaayy overdue. I've been trying to get an app certified for 3 months because the crash only happens in MS certification environments. I feel like I've just been released from a prison camp! I want to complain about the lost time, the hours of labour and the walk home but I'm just happy I can see the light.Anonymous
January 28, 2013
Hi, Can this report not be embedded in Windows ACK tool? It would be alot easier not to mention quicker than having to go through Windows store only to find out app crashed, hope it makes sense.Anonymous
January 28, 2013
@Zubiar: If the app crashes on your side, you can debug that yourself. You should not submit an app that crashes on your own PCs. This is only for unexpected app crashes that occur at MS certification site, which you cannot reproduce yourself.Anonymous
January 28, 2013
I know broken apps should not be submitted, what I am trying to say is what are those 'unexpected app crashes' that dont appear on developer PC and tablets that do in MS certification? Does Windows ACK generate crash dumps and Error Info other than in Windows Event viewer?Anonymous
January 28, 2013
@Zubair the crashes these dumps will come from are most often those that the tester experience while manually testing your application as part of the certification process. That said, your application could crash while the automated WACK tool is running, in which case there are files created to review what may have happened, but you should be catching those before you submit to Microsoft for certification as @Lukas pointed out.Anonymous
February 01, 2013
The comment has been removedAnonymous
February 02, 2013
One should test an app in a clean test machine, or at least with a clean test account, in order to get closer to the certification environment. The dev machine/account can end up with persistent settings in the user profile that can mask issues, like nickm324 found out. Testing without network or simulating network failures, full disk and things like that are also interesting ways to find bugs that might cause an app to crash in user's machine but not in the dev machine. Two things to remember:
- it always works in the dev machine;
- you don't ship the dev machine. :-)
- Anonymous
February 13, 2013
Why an app will crash in the certification environment and not on deleveloper machines is simply that they are developers machines. Few try testing on PERFECTLY NEW MACHINE. Often they forget to clean out old .dlls or they are compliling on the same machine as testing, missing something but it runs fine on the compiling machine because it is there on it and doesn't need to be compiled in. I run a software company, and as much as I say this, programmers continually try to shortcut the hassle of re-installing a clean copy of the OS on a separate machine everytime they want to test a finished product. And new programmers always say this is impossible and not the cause because everything was removed from the last install. Not.