title: What can cause Outlook to change a COM-addin's LoadBehavior to 2 - other than unhandled exceptions?
body: <p>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:</p>
  
  <p><code>HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins\[OurAddin.sProgID]\LoadBehavior</code></p>
  
  <p>There is no error message and neither do any exceptions show up in the log files that our addin produces itself. </p>
  
  <p>I have already found the following page which specifically deals with the LoadBehavior change issue: <a href="http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx" rel="noreferrer">http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx</a></p>
  
  <p>However, none of the possible reasons proposed there appear to be applicable:</p>
  
  <ul>
  <li>The addin is not merely listed in the Disabled Items list.</li>
  <li>There are no unhandled exceptions neither in the <code>IDTExtensibility2</code> methods nor anywhere else in the code. All code is wrapped in try/catch equivalents and all exception output is emitted only via <code>OutputDebugString</code> or into a log file.</li>
  <li>The error appears to be independent of anti-virus software, i.e. it also occurs with it disabled.</li>
  <li>Disabling all other addins also has no effect on the error.</li>
  </ul>
  
  <p><strong>So, what else can cause Outlook to disable an addin?</strong></p>
  
  <p>Some more details / observations:</p>
  
  <ul>
  <li>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.</li>
  <li>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.</li>
  <li>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).</li>
  <li>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.</li>
  <li>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).</li>
  <li>We have put <code>OutputDebugString</code> messages in <code>initialization</code> sections (this a Delphi DLL). None of them show up when the addin fails to load.</li>
  <li><p>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.</p></li>
  <li><p><strong>UPDATE:</strong> 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 (<a href="http://add-in-express.com" rel="noreferrer">Add-in-Express</a>) and does not appear originate from anywhere it my own code every single method of which is by now entirely wrapped in <code>try..catch</code>. This typically occurs right after I set the visibility of my CommandBarButtons from an Inspector's Activate event handler.</p></li>
  </ul>
  
  <p>Common properties of all affected machines:</p>
  
  <ul>
  <li>Windows XP Professional, up-to-date patch level</li>
  <li>Outlook 2003 Professional, up-to-date patch level</li>
  <li>varying versions of McAfee Virus Scan (though disabling it has no effect - see above)</li>
  <li>Users are members of the local Administrators group</li>
  </ul>
  
  <p>One more thing to note which very probably is significant as well (though maybe not as much as I first thought):<br>
  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.</p>
  
  <p>Any more ideas?</p>