在客户环境中调试崩溃的后续步骤

Posted 2023-04-15

【中文标题】在客户环境中调试崩溃的后续步骤

【英文标题】：Next steps debugging crash in customer environment

【发布时间】：2012-01-25 04:55:29

【问题描述】：

我们产品的一部分是一个 IE 插件 (BHO)，它可以在多个操作系统版本/IE 版本的许多不同环境中愉快地运行。

但是，在一个客户的试用设置中，通过 citrix XenDesktop 运行 XP SP3 机器，当满足以下两个条件时，IE 7 会崩溃：

我们的插件已加载 Shockwave flash 对象插件已加载（最新版本 - Flash11e.ocx）

一些额外的信息：

当我们尝试向用户显示一个对话框时，或者在此之后不久，就会发生崩溃。但是崩溃不会发生在我们的代码中，它都是用 C# 编写的，它发生在不同的地方，通常是 ole32.dll。 我们的对话框是在 webbrowser 控件中呈现的 html 页面，通过 BHO 中的 form.ShowDialog(ownerWindow) 显示在表单中。

这两个插件似乎都可以独立工作。禁用 flash 或跳过任何使用 flash 的网站可以防止崩溃。

客户非常乐于助人，我能够使用 MS 调试工具运行 IE，以便在崩溃时捕获一些转储。我现在在解释转储时遇到了一些麻烦。认为这是堆损坏，我在启用完整页堆的情况下运行了调试工具，但这并没有触发断点。

调试工具分析如下：

在 iexplore_PID_5064_日期_12_20_2011__Time_11_19_26AM_161_Second_Chance_Exception_C0000005.dmp ole32!HandleIncomingCall+e2 中的汇编指令 Microsoft Corporation 的 C:\WINDOWS\system32\ole32.dll 导致 尝试读取时访问冲突异常 (0xC0000005) 线程上的内存位置 0x03ce4ff8

崩溃点的堆栈跟踪是：

Thread 7 - System ID 1140
Entry point   ieframe!CTabWindow::_TabWindowThreadProc 
Create time   20/12/2011 19:18:08 
Time spent in user mode   0 Days 0:0:19.828 
Time spent in kernel mode   0 Days 0:0:10.468 


Full Call Stack


Function                                Arg 1     Arg 2     Arg 3     Arg 4   Source 
ole32!HandleIncomingCall+e2                 0f9aafbc     00000034     00000001     07e8ab6c    
ole32!STAInvoke+24                          17444f80     00000001     0781efc0     077e8f10    
ole32!AppInvoke+7e                          17444f28     077e8f10     0781efc0     07e8ab6c    
ole32!ComInvokeWithLockAndIPID+2c2          17444f28     077ec420     00000000     17444f28    
ole32!ComInvoke+60                          17444f28     00000400     0774ee30     07bcfe48    
ole32!ThreadDispatch+23                     17444f28     07bcfeb0     7752b096     00000000    
ole32!ThreadWndProc+fe                      005d0594     078b6ee0     0000babe     17444f2c    
user32!InternalCallWinProc+28               7752b096     005d0594     00000400     0000babe    
user32!UserCallWinProcCheckWow+150          00000000     7752b096     005d0594     00000400    
user32!DispatchMessageWorker+306            7bcff64     00000000     07bcffb4     3e25e69b    
user32!DispatchMessageW+f                   07bcff64     0013e490     0013e5b8     07868ff0    
ieframe!CTabWindow::_TabWindowThreadProc+189 07e03e30     0013e490     0013e5b8     07868ff0    
kernel32!BaseThreadStart+37                 3e25e464     07868ff0     00000000     00000000    

我将看看我还能从这个转储文件中得到什么，但我希望这里的某个人会有一个好主意。我想在客户现场测试更多的东西，但我们只有这么多机会，所以我需要非常明智地使用任何时候。

对我来说，接下来的几个步骤似乎是：

如果问题是 flash 弄乱了我们显示对话框的方式，我想测试一个完全精简的只显示对话框的 BHO，以表明问题不在于我们的代码。 机器上安装了很多其他插件，最好从一个精简的图像开始并从那里构建，看看问题何时开始触发。

有时崩溃发生在 pseuoserverinproc.dll 中，它是 HDX MediaStream 的一部分，它在本地而不是在服务器上运行 flash 内容。

== 更新

我在 WinDbg 分析我拥有的转储方面取得了相当大的成功。我认为尝试在有问题的桌面上使用 gflags/windbg 并对其进行实时调试是很有意义的。

这将是我向目前处于类似位置的任何人推荐的下一步，当我有机会应用它时，我会更多地了解这个建议有多好。

【参考方案1】：

有一个调试器版本的 Flash 播放器可以输出可能对您有所帮助的诊断信息。我意识到这个问题不一定是闪现的，但它可能会提供一些对可能问题的洞察。

我必须承认我已经有一段时间没有安装它了，但我相信这些链接可能会对您有所帮助：

关于如何配置调试器版本输出日志的说明：

http://kb2.adobe.com/cps/403/kb403009.html

调试器版本的下载链接：

http://www.adobe.com/support/flashplayer/downloads.html

【参考方案2】：

您可以在客户站点之外做的一件事是通过静态分析器（例如 pclint）运行您的代码，以查看您自己的代码中是否存在在特殊情况下触发的明显错误。

【讨论】：

也许，我们所有的代码都是托管代码，而且崩溃位置的变化使它看起来像是堆损坏。虽然在那种情况下，应该通过运行调试工具并将 pageheap 设置为 full 来获取一些东西，但什么都没有。

【参考方案3】：

我们最终解决了这个问题（解决得很好）。如果有人感兴趣，我们就是这样做的。

使用 WinDbg（这是一个很棒的工具）分析堆栈转储。我们发现，在 XenDesktop 部署中加载 Flash 后，问题被隔离为在 iexplore.exe 中显示 WinForms。知道了这一点，我们就能解决这个问题。

关键是获得良好的故障转储、制定最小的复制方案并拥有一个让我们测试我们的理论的好客户！