Word VSTO swallows exceptions at runtime without debugging?

Question

Place this code somewhere in a Word document level VSTO solution outside of ThisDocument_Startup (create a ribbon button, with a click event):

int zero = 0;
int divideByZero = 10 / zero;

Start without debugging (Ctrl + F5), Result: Exception is swallowed, the rest of the code fails silently.

The exception will be visible if placed in ThisDocument_Startup, but it appears nowhere else. Microsoft's VSTO forums and the MSDN documentation seem to feel Try...Catch should be used - which is not a big deal for known unknowns. What about the unknown unknowns?

All the common ways of dealing with unhandled exceptions for managed code don't seem to work, presumably because of VSTO using managed code with Office COM Interops:

//These don't work
AppDomain.CurrentDomain.UnhandledException ...
System.Windows.Forms.Application.ThreadException ...

I've read posts about troubleshooting VSTO code that always seems to lead to placing Try...Catch around practically everything!

Is there any better way to handle known and unknown (now invisible and silent!) failures?

Answer 1

Actually it is quite easy, set the environmental variable VSTO_SUPPRESSDISPLAYALERTS to 0 before running the office application, then Office will display exceptions and not kill your add-in during startup when there are issues.

There is also a useful powershell script which will do this sort of stuff for you and is handy when figuring out when VSTO not working at http://archive.msdn.microsoft.com/vstotroubleshooter Get started by running vstotroubleshooter.ps1 setdbg which will setup the VSTO_SUPPRESSDISPLAYALERTS env variable for you

Answer 2

I think the problem is isolated only to exceptions around the "add-in user interface" - which happens to be a direct setting found here (Word 2007):

Word Options > Advanced > General > "Show add-in user interface errors"

Answer 3

I had the same issue with an application-level add-in in Word.

If you are running your add-in by launching it from Visual Studio with F5, then you'll always get "unhandled by user code" in VS (eg 2008 SP1), unless:

• you uncheck the Visual Studio setting "Break when an exception is .. user-unhandled" for CLR exceptions, or

• you liberally apply the [System.Diagnostics.DebuggerNonUserCodeAttribute()] annotation.

Once you've done one of these, UnhandledException/ThreadException seem to work.