如何获取转换后的 Windows 应用商店 UWP 应用程序的故障转储(或任何可用的故障报告)? [英] How to get a crash dump (or any usable crash report) for a converted Windows Store UWP app?

问题描述

我向 Windows 10 Store 提交了我的 native Win32 应用程序，该应用程序是

然后我点击了它.新的Health 页面显示了崩溃发生的时间、市场等(这些内容无助于我调试问题.)

然后在底部我看到了这个:

我点击了上面写着 MOAPPLICATION_HANG_ 的蓝色链接，它打开了 Failure details 窗口.然后，如果我一直向下滚动(点击图表的过去日期和时间)，我会看到:

好的.堆栈跟踪并不完全符合我的预期，但我会看看.

所以如果我点击stack trace，我会弹出这个:

然后，如果我点击下载，我会得到一个很小的文本文件 stackTrace.tsv(117 字节)，里面确实有这个:

有没有办法检索功能

然后微软提供了这个小花絮:

这些都没有给我任何有用的信息来定位崩溃，就像以前一样(见下文.)而且我显然不想用 .pdb 文件发布我的应用程序，或符号，就像上面建议的那样.

因此，如果有人找到了可行的解决方案，我很想知道它...

<小时>

您知道，我可能应该感谢 Microsoft 从 UWP 应用程序崩溃中实际实施堆栈跟踪收集.我亲手处理了 Windows 应用商店 Win32/UWP 应用程序中的实际崩溃，这是我如何利用它来查找潜在错误.

首先，当您登录

如果是这样，请单击该编号/链接并一直向下滚动到详细说明Failure 的位置.就我而言，这是一个看起来像这样的崩溃:

点击它，会弹出另一个窗口.向下滚动到 Failure Log:

它会告诉你崩溃发生的时间、你的应用程序的版本、它发生在什么设备上(这非常好！)然后有一个堆栈跟踪链接.所以点击它:

这就是我的实际堆栈跟踪在崩溃时的样子.由于那个人的计算机没有带有我的可执行文件的符号(.pdb 文件)，我的应用程序中的所有方法都显示为空白偏移量.

以下是查找崩溃实际位置的方法:

使用崩溃文件的精确副本恢复您的 Visual Studio 解决方案.(我假设您已将解决方案的 release 版本与 .exe 和 .pdb 文件一起存档，然后再将其上传到 Windows 应用商店.)

启动Visual Studio，打开崩溃应用的版本，切换到Release配置和

就我而言，它是 0xD0000.然后切换到反汇编 (Alt+8) 并在顶部的 Address 栏中输入您的基地址 + 上面堆栈跟踪中的崩溃偏移量拆卸窗口.我的情况是:

0xD0000+0x1D500

并按 Enter 以显示代码中的位置.这将显示崩溃发生的位置.就我而言，这是这一行:

那就全看你的调试技巧了.就我而言，很容易看到 - nRow 索引超出范围.所以修复这个错误非常简单.

再次感谢微软提供这样的功能.我不知道我上面显示的错误，如果我只是在简单的最终用户报告之后试图发现应用程序崩溃的原因，我会很难受.

附注.最后，我认为我的第一个示例中没有收集堆栈跟踪的原因是应用程序挂起.因此，在这种情况下，可能不会收集调试信息.(此时只是猜测.)

I submitted to Windows 10 Store my native Win32 app that was converted to UWP app using Project Centennial converter. The app passed store certification and is available via a private link (while I'm testing it.)

While running my tests the app hung up and crashed once. So I was trying to retrieve any usable crash dumps to diagnose the problem.

I logged in to the Windows Dev account, then went to my Dashboard and sure enough the app was showing one crash:

I then clicked on it. The new Health page showed the time when the crash took place, market, etc. (Stuff that would not help me debug the issue.)

Then at the bottom I saw this:

I clicked the blue link where it said MOAPPLICATION_HANG_ and it opened up Failure details window. Then if I scrolled all the way down (past date and time of the hit graph), I see this:

OK. Stack trace is not exactly what I was expecting, but I'll take a look.

So if I click on stack trace, I get this pop up:

Then if I click download I get a tiny text file stackTrace.tsv (117 bytes) that literally had this in it:

Is there a way to retrieve a functional mini-dump .dmp file that I can use in Visual Studio C++ project to analyze this crash with a native debugger?

解决方案

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.)

这篇关于如何获取转换后的 Windows 应用商店 UWP 应用程序的故障转储(或任何可用的故障报告)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！