How to get a crash dump (or any usable crash report) for a converted Windows Store UWP app?

Question

I submitted to Windows 10 Store my native Win32 app that was converted to UWP app using Project Centennial converter. The app passed store certific

Answer 1

You can try this method to create a dump file.

1. While you are debugging a process in Visual Studio, you can save a dump file when the debugger has stopped at an exception or at a breakpoint. Choose Save Dump As, Debug. In the Save Dump As dialog box, in the Save as type list, you can select Minidump or Minidump with Heap (the default).
2. With Just-In-Time Debugging enabled, you can attach the debugger to a crashed process that is running outside the debugger, and then save a dump file. See Attach to Running Processes.
3. Other method to create dump file. More detail info, you can refer to using Dump files.

Hope this may be helpful to you.

Answer 2

EDIT: I want to point out that the following does not seem to work in the updated Windows Store anymore. Now if one goes to App -> Analytics -> Health a crash may look as such:

and then Microsoft provides this little tidbit:

Neither of those gave me any useful information to locate the crash, as it was before (see below.) And I obviously do not want to ship my app with a .pdb file, or symbols, like it is suggested above.

So if anyone finds a working solution, I'd be interested to know it...

---

You know, I should probably give credit to Microsoft for actually implementing a stack trace collection from the UWP app crashes. I got my hands on the actual crash in my Windows Store Win32/UWP app and here's how I was able to utilize it to find a latent bug.

First, when you log in to your dashboard, check the app listing and see if there are any crashes:

If so, click on that number/link and scroll all the way down to where it details the Failures. In my case it was a crash that looked like this:

Click it, that will bring up another window. Scroll down to Failure Log:

It will show you when the crash took place, the version of your app, what device it occurred in (which is very nice!) and then have a link for the stack trace. So click it:

That is how my actual stack trace looked like at the moment of the crash. Since that person's computer did not have symbols (.pdb file) with my executable, all methods in my app show as blank offsets.

Here's how to find the actual location of the crash:

Restore your Visual Studio solution with the exact copy of the crashed files. (I'm assuming that you archived the release build of your solution along with .exe and .pdb files before uploading it to the Windows Store.)

Start Visual Studio, open the version of the crashed app, switch to Release configuration and disable builds. (This part is important, because otherwise Visual Studio will try to build your project before you begin debugging it, which may mess up your function offsets that you got from the stack trace!)

Then place a breakpoint somewhere in one of the first constructors that will load up immediately with your app. You need to make sure that it triggers before the crash.

Start debugging (hit F5) and wait for the breakpoint to hit. Then display Modules pane (Ctrl+Alt+U) and locate your executable and get its base address:

In my case it was 0xD0000. Then switch to disassembly (Alt+8) and type in your base address + crash offset from the stack trace above in the Address bar on top of the disassembly window. It my case it was:

0xD0000+0x1D500

and hit Enter to display the location in the code. This will show you where the crash took place. In my case it was this line:

Then it all depends on your debugging skills. In my case it was pretty easy to see -- the nRow index was out of bounds. So it was pretty trivial to fix this bug.

Again, I want to express gratitude to Microsoft for providing such a feature. I was not aware of the bug that I showed above and I would be hard-pressed if I was trying to discover what crashes an application after just a plain end-user report.

PS. Lastly, I think the reason my stack trace was not collected in my first example was because the app was hung. So in that case the debugging information is probably not collected. (Just a guess at this point.)