.net - 如何更改我的IE扩展名以解决另一个模块(flash.ocx)崩溃的IE中的访问冲突？

Question

我有一个Internet Explorer扩展程序（BHO），可以在数千台计算机上很好地工作，但是在某些情况下，似乎会导致Flash因访问冲突而使iexplore.exe崩溃。我该怎么做才能避免这种冲突？

更多细节：

在一个客户的环境中，我们遇到一种情况，当使用Flash访问网站并关闭IE选项卡后，选项卡过程崩溃。仅当同时启用Flash和我的扩展程序且该文件在该公司环境之外的工作站上无法复制时，才会发生这种情况。如果我的扩展程序被配置为在该页面上不执行任何操作，则仍然会发生这种情况-即我的某些代码仍然可以执行，但执行得很少。

如果该网站不在“受信任的站点”中，则该选项卡在“保护模式”下运行，崩溃的结果是一个窗口，提示该网页要运行dw20.exe（即Watson博士）。

如果将网站添加到“受信任的站点”，则会将错误写入Windows应用程序事件日志，并且IE重新打开该选项卡，并带有一条小的信息栏消息，指出IE从崩溃中恢复了它。无论哪种方式都令人沮丧！用户确实不关心关闭标签页时进程是否崩溃，因此我很乐意采用一种解决方法，即不向用户显示错误消息并且标签页不会重新打开。

Windows应用程序事件日志说的不多，但确实说iexplore.exe进程因模块闪存故障而崩溃：

Error / Application Error / EventID=1000

Faulting application name: iexplore.exe, version 9.0.8112.16592, time stamp 0x544e95a7
Faulting module name: Flash32_13_0_0_214.ocx, version 13.0.0.214, time stamp 0x5359c422
Exception code: 0xc0000005
Fault offset: 0x00073678
Faulting application start time: 0x01d0099db319df49
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe
Faulting module path: C:\Windows\system32\Macromed\Flash\Flash32_13_0_0_214.ocx
ReportId: 0094988b-7591-11e4-93e6-6cf0492a8610

这是Flash的较新版本，但不是最新版本。他们已经尝试升级到最新版本，但是具有相同的症状。

他们的工作站运行着Sophos防病毒软件，在极少数情况下，我们已经看到防病毒软件导致扩展程序出现问题。我们在停止所有提到Sophos的Windows服务之后进行了测试，并且发生了相同的问题，因此我可以确定它与此无关。

我的扩展程序是使用.NET 3.5 SP1构建的，由于与其他扩展程序可能存在运行时冲突，因此这不是理想的实现方式，但这就是目前的方式。

如果我禁用扩展程序，问题将消失。如果禁用Flash，问题将消失。出现故障的模块 Flash32_13_0_0_214.ocx强烈指出它是那里的错误，但我认为从理论上讲这可能是我的代码中的问题。我的扩展程序没有正在执行的非托管代码，所以不是那样的，所以我想不到我的扩展程序可以做的任何事情都可能导致AccessViolation。这留下了Flash中似乎完全可能的bug或我与IE中的COM对象进行交互的方式的问题。但是，除非我能指出特定且可复制的内容，否则Flash团队不太可能会调查此类错误报告，并且现在我无法在任何开发机上进行复制，因此效果不佳。即使是Flash错误，从客户的角度来看，这与我产品中的错误没有什么不同：我将其修复或将其产品卸载并保留Flash。

选件

我希望获得一些有关以下方面的想法：


有什么我可以尝试在代码/产品中尝试避免与Flash冲突的内容吗？例如，将我的dll重新整理以将扩展名移动到不同的内存区域是否可以正常工作？ .NET 4.0 / 4.5的重新编译能否正常工作？
我该怎么做才能重现问题……为什么在其他数十家公司中这不是问题，而在这家公司中又是问题？是否对引发此问题的环境因素有什么想法，但对于设置不同的工作站没有任何想法吗？
是否有任何尝试获取故障转储或其他有关故障的诊断信息的信息（例如，发生故障时的ProcMon）？我没有专门的知识来进行此类诊断，因此我希望避免使用它，除非它有可能使我对我可以在产品中进行的不同操作或找出闪存模块中的确切错误（如果确实存在）提出了答案。是一个）。
我很乐意让它安静地崩溃，例如，当它崩溃时，有一些方法可以阻止IE重新打开选项卡。


我可能需要一段时间才能与客户一起测试不同的选项，所以我想尝试一些方法。任何想法都非常感谢。

到目前为止，我有一些随意的想法。他们中的任何一个听起来值得尝试吗？


使用.net 4重新编译
在我的SetSite（null）方法（卸载我的扩展程序时发生的事件）中，我有几行清除代码，例如 Marshal.FinalReleaseComObject(webBrowser)和 GC.Collect()。删除其中的一个或多个：也许GC或COM清理会破坏Flash的内存空间。
重新设置我的dll。
卸载并在工作站上重新安装IE9，以查看是否有任何效果。这种解决方案无法在全公司范围内使用，但可能表明其IE图像有些模糊。


更新资料

客户再次复制了问题，并且故障模块为 jscript9.dll，而不是Flash ocx。他们还报告说在 ntdll.dll上也看到了同样的情况，尽管我自己还没有看到。

Faulting application name: iexplore.exe, version: 9.0.8112.16575, time stamp: 0x53ee1acb 
Faulting module name: jscript9.dll, version: 9.0.8112.16575, time stamp: 0x53ee1c49 
Exception code: 0xc0000005 
Fault offset: 0x00007264 
Faulting process id: 0x1bb4 
Faulting application start time: 0x01cfec57f247cb53 
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe 
Faulting module path: C:\Windows\System32\jscript9.dll 
Report Id: 50b58f63-584b-11e4-bc66-6cf0492a8610 
Faulting package full name: %14 
Faulting package-relative application ID: %15

所以我想这会使它与Flash不相关...

Answer 1

问题是，使用.Net，您几乎无能为力地使内存混乱。因此，除非您经常玩Api调用，否则很难在代码中引起错误。

在我看来，重新定位dll是最有前途的事情。也不要搞乱GCC，这似乎是一个很好的选择（而且，不仅在这种情况下，总是这样）。

另一个问题是，发生错误的不是您的模块，这是要认真考虑的问题：尝试访问另一个dll分配的内存区域的不是您的代码，而是他们的代码试图弄乱您的dll的内存空间。

也许您最好的选择是DW；通过保存转储，您可以遍历堆栈跟踪以查找导致问题的代码。再次回溯，您可以找到某个参数变为垃圾的时刻。最后，您可以使用此https://msdn.microsoft.com/en-us/windows/hardware/hh852365实时调试崩溃。为什么所有这些？好吧，因为如果您没有在dll中做任何奇怪的事情（例如手动进行malloc'ing），那么在.Net中，您就不会以任何方式弄乱内存，从而“在另一个dll中造成了0x05。 99％的原因是特定的IE及其特定的配置是一切的原因，因此，最快的解决方案是调试，查找有问题的代码，然后压缩所有信息并将其邮寄给MS。