exception - 除了未处理的异常之外，是什么导致Outlook将COM加载项的LoadBehavior更改为2？

Question

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

HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior

没有错误消息，并且我们的插件自身产生的日志文件中也不会显示任何异常。

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

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


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


因此，还有什么可以导致Outlook禁用加载项？

一些更多的细节/观察：


到目前为止，我们还无法在测试环境中重现该问题，因此在出现问题时我们还无法附加调试器。
当我们尝试通过远程支持（TeamViewer）观察发生的情况时，永远不会发生此问题。我怀疑这是因为TeamViewer使用了一个钩子DLL，它将自身注入所有正在运行的进程（包括Outlook），从而影响了内存布局，时序，线程顺序等。
每当我们编译外接程序的新版本以尝试新功能时，外接程序通常可以正常工作几个小时甚至几天，直到最终再次被禁用。一旦发生这种情况，所有随后的尝试将外接程序加载到该计算机上（通过手动改回LoadBehavior值）都将失败（即LoadBehaviour将简单地改回2），直到我们编译并部署另一个构建（或尝试使用TeamViewer-参见上文）。
通常，加载项会在Outlook启动时立即卸载，尽管偶尔在Outlook已经运行一段时间后也会发生。在这种情况下，日志文件看起来完全没有问题-插件仅执行常规的关闭步骤，就像正常关闭Outlook一样。
据我从日志文件中看到的信息，以及通过SysInternals ProcessMonitor观察到的问题，当Outlook启动时（而不是在会话期间）禁用加载项时，甚至在实例化COM对象（即加载项）之前就已卸载了DLL。 （构造函数中的日志消息永远不会显示）。
我们在OutputDebugString部分（这是一个Delphi DLL）中放入了initialization消息。当加载项加载失败时，它们都不会显示。
我们的客户中只有很小一部分受到此问题的影响。我们有数以万计的安装程序，但尚未收到有关此安装程序的任何报告。
更新：似乎经常（但并非总是）在卸载加载项之前记录的最后一件事是文本为“ OLE错误800A01A8”的异常。该异常被我正在使用的框架（Add-in-Express）中内置的全局异常处理程序捕获，并且似乎不是源于我自己的代码的任何地方，而该代码的每个方法现在都完全包裹在try..catch中。这通常是在我从检查员的Activate事件处理程序设置CommandBarButtons的可见性后立即发生的。


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


Windows XP Professional，最新补丁程序级别
Outlook 2003 Professional，最新补丁程序级别
多种版本的McAfee Virus Scan（尽管将其禁用无效-参见上文）
用户是本地管理员组的成员


需要注意的另一件事也很重要（尽管可能不如我最初想象的那么重要）：
我们正在使用第三方供应商的许可/复制保护模块，该模块将已编译的DLL封装在“外壳”中，并且只能即时对其进行解压缩。自从我发现甚至在执行我们自己的任何代码之前就卸载了该插件之后，这一直是我的主要怀疑。但是，尽管供应商确认其代码中可能存在未处理的异常，但是由保护壳的特殊调试版本生成的日志文件显示，解压缩过程已成功完成，并且在Outlook卸载加载项之前，控制权已经交还给受保护的DLL。 。因此，看起来导致Outlook卸载加载项的原因发生在保护外壳初始化完成和我们自己的代码之间。

还有其他想法吗？

Answer 1

多年来，我的公司一直在忍受着听起来像您遇到的同样问题。我们拥有的插件是用于Outlook 2003的VB6 COM插件，已部署在数百台计算机上，每天要循环数百次（如果不是数千次）。我们经历了很多加载和卸载循环。

在加载了插件但未连接插件的情况下，我们会得到相当多的常规错误，并通过代码进行处理。 （显然不是生产质量）

Dim outlook As outlook.Application
Set outlook = CreateObject("Outlook.Application")
outlook.COMAddIns("MyFancyDancyPlugin").Connect = True

很少（但并非罕见），这并不是一件令人讨厌的事情，我们看到该插件已达到加载状态，可以在“工具>选项>其他>高级选项> Com加载项”中看到它，但是我们只是无法连接到东西。如果您尝试连接，则不会出现错误，它只会切换回断开状态。 [相当于在注册表项中切换回2。]就我所知，从未创建过COM对象。该项目未在“禁用”项目中列出。

实际上，我们无需重新部署即可纠正此错误。通过“ Com加载项”对话框删除对象，然后在此处重新添加对象似乎可以解决此问题。这仍然不是一个可以接受的解决方案，但是它确实可以使事情恢复原样并运行，而无需重新安装。



Windows XP Professional，最新
补丁级别
Outlook 2003
专业的最新补丁程序级别
各种版本的McAfee Virus Scan
（尽管禁用它无效-
往上看）
用户是
本地管理员组



这似乎很合适，我们不使用McAfee，但病毒扫描程序也不与Outlook或com加载项交互。我们也不会使用版权保护应用。

抱歉，我无法提供更多帮助，但是我想扎根。