如何解释此堆栈跟踪

Fab*_*ini 50 c# c++ access-violation windows-phone-8

我最近发布了一款Windows phone 8应用程序.该应用程序有时似乎随机崩溃,但问题是它崩溃没有破坏,我得到的唯一信息是输出上的消息,告诉我有一个访问冲突没有给出任何细节.因此,在发布后,我可以从崩溃报告中获得更多信息,但它们对我来说有点隐秘.

信息是:

Problem function: unknown //not very useful
Exception type: c0000005 //this is the code for Access violation exception
Stack trace: 
Frame    Image        Function      Offset 
0        qcdx9um8960                0x00035426 
1        qcdx9um8960                0x000227e2
Run Code Online (Sandbox Code Playgroud)

我不习惯使用内存指针和similia,我不习惯看到像这样的堆栈跟踪.

所以我有这样的问题:

  1. 我该如何解读/阅读这些信息,每条信息的含义是什么?
  2. 有没有办法利用这些信息来搜索我的问题?
  3. 有没有办法在VS2012中调试时获取这些信息

笔记:

  • 我不是在询问访问冲突是什么
  • 我将其标记为c#和c ++,因为我的代码在c#中,但是通过WebBrowser组件的c ++实现生成异常(我是半猜)

编辑:

我尝试将Debug类型设置为Native,这让我获得了与开发中心崩溃报告中相同的信息.这种方式调试器在抛出异常时中断并让我看到反汇编的代码,遗憾的是没有qcdx9um8960 .pdb文件(即使在Microsoft Symbol Server上),所以我不知道导致错误的函数名称.

Cᴏʀ*_*ᴏʀʏ 17

奇怪的是,在Web上搜索图像名称"qcdx9um8960"会返回引用Windows Phone 8和WebBrowser控件的几个结果.收集答案和答复(有些甚至是MSFT),这是你应该看到的:

  • 如果您将应用程序从Windows Phone 6/7升级到8,请确保您仍未引用任何6/7 DLL.1
  • 确保您没有在调试模式下测试或发布您的软件.有一个"qcdx9um8960.pdb"文件可能会丢失,导致访问冲突.1
  • "......如果应用程序打开了多个WebBrowser副本,则可能存在竞争条件已知问题.请查看您的代码是否可能无意中发生了多个实例." 1
  • 该图像"qcdx9um8960"引用了Qualcomm DirectX驱动程序DLL.也许这不是WebBrowser组件的错,而是它可能用于呈现网页的DirectX驱动程序.2
  • 该图像的名称表明,崩溃发生在由Qualcomm Snapdragon S4 Plus驱动的设备上,型号为MSM8960.3
  • 假设上面的处理器,并交叉引用使用该芯片的Windows手机,您可能会看到诺基亚Lumia 920T上出现的问题.3这并不是说驱动程序不适用于多种处理器架构或手机.

还有其他一些关于崩溃的问题,并且在存在DLL的情况下调试问题,所以不幸的是,对于你,我认为你可能会受到一些第三方软件的支配,这些软件有一些未解决的问题.


参考

1 更新到WP8后访问冲突

2 [工具包] [WP8] DepthStencilBuffer的性能问题

3 Snapdragon(片上系统)

  • @FabioMarcolini:我通过参考文献2发现了Qualcomm驱动程序,特别是[这篇文章](http://sharpdx.org/forum/4-general/2068-toolkit-wp8-performance-issues-with-depthstencilbuffer#2115) .名称中的"qc"是Qualcomm,"dx9"是DirectX 9,我不确定"u",然后我用Google搜索"m8960 qualcomm",发现它可能是指处理器型号.然后我使用参考3(维基百科)来匹配处理器和手机.例如,您还可以找到以"m8930"结尾的DLL,这是Snapdragon的另一个型号. (2认同)

Bob*_*bHy 8

这种崩溃"应该"永远不会由托管代码引起,因此您可以去寻找您的应用程序错误地调用某些系统或库API的情况.那太乏味了.问题可能与您的应用程序无关,它可能完全是其他人的代码内部.例如,当用户浏览某个恶意页面时,WebBrowser可能会崩溃.或者失败的代码可以在一个甚至从不运行代码的线程上运行.根据您的观察,调试器在访问冲突之前没有显示任何消息,并且调用堆栈上只有2个帧,我怀疑这是最有可能的.

所以你应该首先关注一个(相当)可靠的repro场景:(通常或通常)产生崩溃的(最小)步骤集.这可能涉及对遇到崩溃的用户进行访谈,或者可能需要一些测试自动化来尝试加速故障率.

一旦你有了这个,微软(或其他第三方)将承担责任 - 托管代码永远不会导致未处理的异常,如访问冲突.该方案可能会为您提供有关如何更改应用程序行为以避免此问题的提示,因为实际修复可能需要很长时间才能发布和分发.