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

问题描述

几个星期以来，我们一直在争取一个问题，在少数客户端，我们的Outlook加载项由于尚未确定的原因而被卸载和停用。通过禁用我的意思是，Outlook将以下注册表值从3更改为2，这实际上意味着下一次启动时不会加载插件：

HK $ _ $ _ $ >没有错误信息，我们的插件自己生成的日志文件中也不会出现任何异常。

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

但是，建议的可能原因似乎不适用：

• 加载项不仅列在禁用项目列表中。


• 在$ code中没有未处理的异常> IDTExtensibility2 方法或代码中的其他任何地方。所有代码都包含在try / catch等效项中，所有异常输出仅通过 OutputDebugString 或日志文件发出。


• 错误似乎是独立于防病毒软件，也就是它也会被禁用。


• 禁用所有其他加载项也不会对错误产生影响。

那么还有什么可以导致Outlook禁用加载项？

细节/观察：

• 到目前为止，我们还没有能够在测试环境中重现这个问题，所以我们还没有在发生问题时附加调试器。


• 当我们尝试观看通过远程支持（TeamViewer）发生的情况时，不会发生此问题。我怀疑这是因为TeamViewer使用一个钩子DLL，将其自身注入到所有正在运行的进程（包括Outlook）中，从而影响内存布局，时序，线程顺序。无论何时我们编译新版本的插件可以尝试一些新的插件，通常可以在几个小时甚至几天内正常工作，最终再次被禁用。一旦发生这种情况，所有后来尝试将该加载项加载到该机器上（通过手动更改LoadBehavior值）将失败（即LoadBehaviour将简单地更改为2），直到我们编译和部署另一个构建（或尝试观看使用TeamViewer - 见上文）。


• 通常，在Outlook启动时，插件将被卸载，但偶尔也会在Outlook已经运行一段时间后发生。在这些情况下，日志文件看起来完全不正确 - 加载项简单地执行正常的关机步骤，就像Outlook正常关闭一样。


• 根据我可以从我们的日志文件和通过SysInternals ProcessMonitor观察问题，当Outlook启动时（而不是在会话期间）禁用了addin，甚至在COM对象（即，addin）被实例化之前DLL也被卸载（构造函数中的日志消息永远不会出现）。


• 我们将 OutputDebugString 消息放在初始化部分（这是一个Delphi DLL ）。当加载无法加载时，它们都不会显示。



• 只有极少部分客户受到此问题的影响。我们有几万个安装，我们尚未收到任何有关这方面的报告。




• 更新：似乎经常（但不总是）在插件卸载之前记录的最后一件事情之一是文本OLE错误800A01A8的异常。该异常被我正在使用的框架中构建的全局异常处理程序所捕获（ Add-in-Express ） ）并且不出现在任何地方，我自己的代码，每一个单一的方法现在完全包裹在 try..catch 中。这通常在我从Inspector的Activate事件处理程序设置我的CommandBarButton的可见性之后发生。

受影响的机器：

• Windows XP Professional，最新的修补程序级别


• Outlook 2003 Professional ，最新补丁级别


• 不同版本的McAfee Virus Scan（尽管禁用它没有任何效果 - 见上文）


• 用户是成员的本地管理员组

还有一件事要注意，这很可能是重要的（尽管也许不如我第一次想到的那么多）：

我们正在使用来自第三方供应商的许可/复制保护模块，该模块将编译的DLL包装在shell中，并且仅在运行时解包。自从我发现即使在我们自己的代码执行之前，加载项也被卸载，这是我的主要嫌疑人。然而，虽然供应商确认他们的代码中可能存在未处理的异常，但由保护shell的特殊调试版本生成的日志文件显示拆包过程已成功完成，并且控制权已经在Outlook卸载了加载项之前被转回到受保护的DLL 。所以看来，无论什么原因导致Outlook卸载我们的加载项都会在保护shell的初始化完成和我们自己的代码之间发生。

有更多的想法？

解决方案

只是为了关闭这个问题：最终这个问题是由我们使用的第三方许可包装器中的错误引起的。已由供应商确认，并在最新版本中修复。

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_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior

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

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:

• 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.

So, what else can cause Outlook to disable an addin?

Some more details / observations:

• 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.

• 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, up-to-date patch level
• Outlook 2003 Professional, up-to-date patch level
• varying versions of McAfee Virus Scan (though disabling it has no effect - see above)
• Users are members of the local Administrators group

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.

Any more ideas?

解决方案

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-addin的LoadBehavior更改为2 - 除了未处理的异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！