After calling a COM-dll component, C# exceptions are not caught by the debugger

I'm using a COM dll provided to me by 3rd-party software company (I don't have the source code). I do know for sure they used Java to implement it because their objects contain property names like 'JvmVersion'.

After I instantiated an object introduced by the provided COM dll, all exceptions in my C# program cannot be caught by the VS debugger and every time an exception occurs I get the default Windows Debugger Selection dialog (And that's while executing my program in debug mode under a full VisualStudio debugging environment).

To illustrate:

throw new Exception("exception 1");
m_moo = new moo();   // Component taken from the COM-dll
throw new Exception("exception 2");

Exception 1 will be caught by VS and show the "yellow exception window".

Exception 2 will open开发者_运维知识库 a dialog titled "Visual Studio Just-In-Time Debugger" containing the text "An unhandled win32 exception occurred in myfile.vshost.exe[1348]." followed by a list of the existing VS instances on my system to select from.

I guess the instantiation of "moo" object overrides C#'s exception handler or something like that. Am I correct and is there a way to preserve C#'s exception handler?

Well, that's not good. You however haven't proven yet that the CLR's exception handling logic is completely borked. What you describe could also be explained by something detaching the debugger. The Java JVM would certainly be a candidate. Check if a try still works, if it does you still stand a chance to use this COM server.

Debugging is however going to be painful. With some luck, the detach happens only once. Try writing System.Diagnostics.Debugger.Break() after the very first call to the server, click "Debug" on the dialog you'll get.

Also test if a null reference exception still works, that's a hardware exception that's liable to be redirected by a VM calling Windows' SetUnhandledExceptionFilter(). If that can't be caught then you should not use this COM server as-is, it will destabilize your process too much. Running it in a separate process and talking to it with WCF or Remoting is a desperation move that could work out.

Needless to say, this component vendor is violating the COM server contract badly. You shouldn't have to put up with it.

Adding the following line (as the first line) in my main() (in Program.cs file) made exceptions work again:

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

The above line overides the Automatic handler which (I guess) for some reason stopped working after using the COM component.