什么会导致 Outlook 将 COM 插件的 LoadBehavior 更改为 2 - 除了未处理的异常? [英] What can cause Outlook to change a COM-addin's LoadBehavior to 2 - other than unhandled exceptions?

问题描述

几个星期以来，我们一直在解决一个问题，即在少数客户中，我们的 Outlook 插件由于尚未确定的原因被卸载和禁用.禁用"是指 Outlook 将以下注册表值从 3 更改为 2，这实际上意味着下次启动时不会加载该插件:

For some weeks now we have been fighting with an issue where at a small number of customers our Outlook addin gets unloaded and disabled for yet undetermined reasons. By "disabled" I mean that Outlook changes the following registry value from 3 to 2 which in effect means that the addin will not be loaded on next startup:

HKEY_LOCAL_MACHINESoftwareMicrosoftOfficeOutlookAddins[OurAddin.sProgID]LoadBehavior

没有错误消息，我们的插件自己生成的日志文件中也没有出现任何异常.

There is no error message and neither do any exceptions show up in the log files that our addin produces itself.

我已经找到了专门处理 LoadBehavior 更改问题的以下页面:http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx

I have already found the following page which specifically deals with the LoadBehavior change issue: http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx

但是，那里提出的所有可能原因似乎都不适用:

However, none of the possible reasons proposed there appear to be applicable:

• 该插件不仅列在禁用项目"列表中.
• IDTExtensibility2 方法和代码中的任何其他地方都没有未处理的异常.所有代码都包含在 try/catch 等效项中，所有异常输出仅通过 OutputDebugString 或日志文件发出.
• 该错误似乎与防病毒软件无关，即它也会在禁用防病毒软件的情况下发生.
• 禁用所有其他插件也不会对错误产生影响.

• The addin is not merely listed in the Disabled Items list.
• There are no unhandled exceptions neither in the IDTExtensibility2 methods nor anywhere else in the code. All code is wrapped in try/catch equivalents and all exception output is emitted only via OutputDebugString or into a log file.
• The error appears to be independent of anti-virus software, i.e. it also occurs with it disabled.
• Disabling all other addins also has no effect on the error.

那么，还有什么会导致 Outlook 禁用插件?

更多细节/观察:

• 到目前为止，我们还无法在我们的测试环境中重现该问题，因此我们还无法在问题发生时附加调试器.
• 当我们尝试通过远程支持 (TeamViewer) 观察发生的情况时，此问题从未发生.我怀疑这是因为 TeamViewer 使用钩子 DLL 将自身注入所有正在运行的进程(包括 Outlook)，从而影响内存布局、时间、线程顺序等.
• 每当我们编译新版本的插件来尝试新的东西时，插件通常会正常工作几个小时甚至几天，但最终会再次被禁用.一旦发生这种情况，所有后续尝试将插件加载到该机器上(通过手动更改 LoadBehavior 值)都将失败(即 LoadBehaviour 将简单地更改回 2)，直到我们编译并部署另一个构建(或尝试使用TeamViewer - 见上文).
• 通常情况下，插件会在 Outlook 启动时立即卸载，但偶尔也会在 Outlook 已经运行一段时间后发生.在这些情况下，日志文件看起来完全不明显 - 插件只是执行常规关闭步骤，就像 Outlook 已正常关闭一样.
• 据我所知，从我们的日志文件和通过 SysInternals ProcessMonitor 观察问题，当插件在 Outlook 启动时(而不是在会话期间)被禁用时，DLL 甚至在 COM 对象(即插件) 被实例化(构造函数中的日志消息永远不会显示).
• 我们已将 OutputDebugString 消息放在 initialization 部分(这是一个 Delphi DLL).当插件加载失败时，它们都不会显示.

• 只有极少数客户受到此问题的影响.我们有数以万计的安装，我们还没有收到任何关于此的报告.

• We haven't been able to reproduce the issue in our test environments so far so we haven't yet been able to attach a debugger while the issue occurs.
• The issue never occurs while we try to watch what happens via remote support (TeamViewer). I suspect this is because TeamViewer uses a hook DLL that injects itself into all running processes (including Outlook) and thus affects the memory layout, timing, thread order, whatever.
• Whenever we compile a new version of the addin to try out something new the addin will typically work fine for a couple of hours or even days only to eventually get disabled again. Once this has happened all subsequent attempts to get the addin to load on that machine (by manually changing back the LoadBehavior value) will fail (i.e. LoadBehaviour will simply change back to 2) until we compile and deploy another build (or try to watch using TeamViewer - see above).
• Typically the addin will get unloaded right on Outlook startup though occasionally it also does happen after Outlook has already been running for some time. The log file in those cases looks completely inconspicious - the addin simply goes through the regular shutdown steps just as if Outlook had been closed normally.
• As far as I can tell from our log files and by observing the issue via SysInternals ProcessMonitor, when the addin get disabled on Outlook startup (rather than during the session) the DLL gets unloaded even before the COM object (i.e. the addin) gets instantiated (log messages in the constructor never show up).
• We have put OutputDebugString messages in initialization sections (this a Delphi DLL). None of them show up when the addin fails to load.

• Only a very small fraction of our customers is affected by this issue. We have several tens of thousands of installations from whom we haven't received any reports about this.

更新: 似乎经常(但不总是)在加载项卸载之前记录的最后一件事是文本OLE 错误 800A01A8"的异常.该异常被我正在使用的框架中内置的全局异常处理程序捕获 (Add-in-Express) 并且不会出现在我自己的代码的任何地方，其中每个方法现在都完全包含在 try..catch 中.这通常发生在我从 Inspector 的 Activate 事件处理程序设置我的 CommandBarButtons 的可见性之后.

UPDATE: It seems that often (but not always) one of the last things that gets logged before the addin gets unloaded is an exception with text "OLE error 800A01A8". That exception gets caught by a global exception handler built into the framework I'm using (Add-in-Express) and does not appear originate from anywhere it my own code every single method of which is by now entirely wrapped in try..catch. This typically occurs right after I set the visibility of my CommandBarButtons from an Inspector's Activate event handler.

所有受影响机器的共同属性:

Common properties of all affected machines:

• Windows XP Professional，最新补丁级别
• Outlook 2003 Professional 的最新补丁级别
• 不同版本的 McAfee Virus Scan(尽管禁用它没有任何效果 - 见上文)
• 用户是本地管理员组的成员

还有一件事需要注意，这很可能也很重要(尽管可能没有我最初想的那么重要):
我们正在使用来自第三方供应商的许可/复制保护模块，该模块将编译后的 DLL 包装在外壳"中，并且仅在运行时对其进行解包.自从我发现插件在我们自己的任何代码被执行之前就被卸载了，这一直是我的主要嫌疑人.然而，虽然供应商确认他们的代码中可能存在未处理的异常，但由保护壳的特殊调试版本生成的日志文件显示解包过程成功完成，并且在 Outlook 卸载插件之前，控制权已经交还给受保护的 DLL.因此，似乎任何导致 Outlook 卸载我们的插件的原因都发生在保护外壳的初始化完成和我们自己的代码之间.

One more thing to note which very probably is significant as well (though maybe not as much as I first thought):
We are using a licensing / copy protection module from a third-party vendor which wraps the compiled DLL in a "shell" and only unpacks it on-the-fly. Ever since I found out that the addin gets unloaded even before any of our own code gets executed this has been my prime suspect. However, while the vendor confirmed that there may be unhandled exceptions in their code a log file produced by a special debug version of the protection shell showed that the unpacking process completed successfully and control was already handed back to the protected DLL before Outlook unloaded the addin. So it appears that whatever causes Outlook to unload our addin happens between the completion of the protection shell's initialization and our own code.

还有什么想法吗?

推荐答案

总结一下:问题最终被证明是由我们使用的第三方许可包装程序中的错误引起的.它已得到供应商的确认，并在最近的版本中得到修复.

Just to close this up: The problem did eventually turn out to be caused by a bug in the third-party licensing wrapper we were using. It has been confirmed by the vendor and was fixed in more recent releases.

这篇关于什么会导致 Outlook 将 COM 插件的 LoadBehavior 更改为 2 - 除了未处理的异常?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！