Outlook 2007 AddIn being disabled

[rob_tt08]

Our company has been working on an Outlook AddIn using VSTO which has a
number of issues which we have not been able to resolve yet.

We would appreciate any insight or assistance you can offer.

We have sometimes experienced errors which cause Outlook to disable the
AddIn even when no errors have occurred in the managed code or been caught by
our exception handling.

How can we most easily diagnose the causes of these errors and track their
occurrence?

Thanks

 

[Ken Slovak - [MVP - Outlook]]

Are the errors occurring when your addin is loaded or when it's already
running? You can set up an exception handler for unhandled exceptions and
see if that helps at all. Or if the problem is during loading you can check
the Fusion logs to see where that occurs.

See
http://blogs.msdn.com/vsod/archive/2008/04/22/Troubleshooting-com-add-in-load-failures.aspx
for more troubleshooting information.

 

[rob_tt08]

Ken,

The addin installs and loads successfully and works at first but sometimes
when the user starts Outlook at a later date the addin does not start and
needs to be re-enabled.

Users have not reported anything out of the ordinary immediately prior to
experiencing this problem so we are unsure of its cause. I will follow your
advice and add more exception handling (using the
System.Windows.Forms.Application.ThreadException event) in case there are
still unhandled exceptions, and see if the problem is reported again.

Outlook has sometimes crashed during ordinary use for these users but the
addin was not disabled after this. The error handling code which we are
already using (try/catch blocks around the code in the event handlers and
methods of our addin) did not catch or log any errors on these occaisions.

Will the ThreadException event catch all possible errors or is it possible
that the addin could be causing problems for Outlook which make it unstable
without actually throwing an exception?

Thank you for your advice.

 

[Ken Slovak - [MVP - Outlook]]

I usually also add a handler for unhandled exceptions this way:

AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

private static void CurrentDomain_UnhandledException(object sender,
UnhandledExceptionEventArgs e)
{
}

One thing to look at is if those users with problems are running any code
that integrates with and starts Outlook with no UI (no Explorers or
Inspectors). Some applications that do that include synching software that
synchs with PDA's, IPods or IPhones, etc. That's also called "headless"
mode.

The earlier versions of the VSTO runtime terminated the addin if Outlook was
started in headless mode, a fix for that was made in the latest version of
the VSTO runtime. Make sure your users have the latest VSTO runtime, and see
if what I mentioned applies to any of them.

 

[rob_tt08]

Ken,

I have added a handler as you suggest. I have previously added code to allow
for Outlook being started in headless mode and have tested it on one of the
machines which suffers from the problem. It appears to be functioning
correctly when started with no UI, so I do not think this is the cause.

We will release a new version with the improved error handling and see if
the problem occurs again. I will repost if it has not been resolved.

Thank you for your assistance.

 

[Ken Slovak - [MVP - Outlook]]

The headless mode fix is in the latest version of the VSTO runtime, If you
aren't using and deploying that version the addin would terminate when
started in headless mode before you even get a crack at the code in startup.

With the latest version of the runtime you'd need to test for UI (Explorers
and/or Inspectors) to decide if you want to instantiate various parts of
your addin. I usually wait on that in those cases until a NewExplorer() or
NewInspector() event fires and I know I have UI.