编辑:我想指出以下内容似乎不再适用于更新的 Windows 应用商店。现在,如果一个人去 App -> Analytics -> Health 崩溃可能看起来像这样:
然后微软提供了这个小花絮:
这些都没有给我任何有用的信息来定位崩溃,就像以前一样(见下文。)而且我显然不想像.pdb
上面建议的那样用文件或符号发送我的应用程序。
因此,如果有人找到可行的解决方案,我很想知道...
你知道,我应该感谢微软实际上从 UWP 应用程序崩溃中实现了堆栈跟踪收集。我在我的 Windows Store Win32/UWP 应用程序中得到了实际的崩溃,这就是我如何利用它来找到潜在的错误。
首先,当您登录仪表板时,检查应用列表并查看是否有任何崩溃:
如果是这样,请单击该数字/链接并一直向下滚动到详细说明Failures
. 就我而言,这是一个看起来像这样的崩溃:
单击它,将弹出另一个窗口。向下滚动到Failure Log
:
它会显示崩溃发生的时间、应用程序的版本、它发生在什么设备上(这非常好!),然后有一个堆栈跟踪的链接。所以点击它:
这就是崩溃时我的实际堆栈跟踪的样子。由于该人的计算机在我的可执行文件中没有符号(.pdb
文件),因此我的应用程序中的所有方法都显示为空白偏移。
以下是如何找到崩溃的实际位置:
使用崩溃文件的精确副本恢复您的 Visual Studio 解决方案。(我假设您在release
将解决方案的构建.exe
以及.pdb
文件上传到 Windows 应用商店之前将其存档。)
启动 Visual Studio,打开崩溃应用的版本,切换到Release
配置并禁用构建。(这部分很重要,因为否则 Visual Studio 将在您开始调试之前尝试构建您的项目,这可能会弄乱您从堆栈跟踪中获得的函数偏移量!)
然后在第一个构造函数中的某处放置一个断点,该构造函数将立即与您的应用程序一起加载。您需要确保它在崩溃之前触发。
开始调试(命中F5
)并等待断点命中。然后显示Modules
窗格 ( Ctrl
++ Alt
)U
并找到您的可执行文件并获取其基地址:
就我而言,它是0xD0000
。然后切换到反汇编 ( Alt
+ ) 并在反汇编窗口顶部的栏中8
输入您的基地址 + 从上面的堆栈跟踪中的崩溃偏移量。Address
我的情况是:
0xD0000+0x1D500
并点击Enter
以显示代码中的位置。这将向您显示崩溃发生的位置。就我而言,它是这一行:
那么这一切都取决于你的调试技巧。就我而言,这很容易看出——nRow
索引超出了范围。所以修复这个错误非常简单。
再次,我要感谢 Microsoft 提供这样的功能。我不知道上面显示的错误,如果我试图在简单的最终用户报告之后发现应用程序崩溃的原因,我会感到非常难过。
PS。最后,我认为在我的第一个示例中没有收集堆栈跟踪的原因是因为应用程序已挂起。所以在这种情况下,调试信息可能不会被收集。(此时只是猜测。)