Can I stop COM from swallowing uncaught C++ exceptions in the callee process?

Go To


I am maintaining a project which uses inter-process COM with C++. At the top level of the callee functions there are try/catch statements directly before the return back through COM. The catch converts any C++ exceptions into custom error codes that are passed back to the caller through the COM layer.

For the purpose of debugging I want to disable this try/catch, and simply let the exception cause a crash in the callee process (as would normally happen with an uncaught C++ exception). Unfortunately for me the COM boundary seems to swallow these uncaught C++ exceptions and I don't get a crash.

Is there a way to change this behaviour in COM? Ie, I want it to allow the uncaught C++ exception to cause a crash in the callee process.

I want this to happen so that I can attach a debugger and see the context in which the exception is thrown. If I simply leave our try/catch in place, and breakpoint on the catch, then the stack has already unwound, and so this is too late for me.

The original "COM masters" who wrote this application are all either unavailable or can't remember enough details.

2009-06-16 10:04
by pauldoo
The descriptions looks strange. Is it an in-proc COM server? My experience is that witha n in-proc server all exceptions are happily propagated through the COM boundary and crash the caller process - sharptooth 2009-06-16 10:16
"I am maintaining a project which uses inter-process COM with C++. - pauldoo 2009-06-16 10:18
Can you enable first-chance exceptions in the debugger or are you worried only about the ones that make it all the way back to the entry point - Adrian McCarthy 2018-04-12 17:47


This just in, a year and a half after the question was asked -

Raymond Chen has written a post about "How to turn off the exception handler that COM 'helpfully' wraps around your server". Seems like the ultimate answer to the question. If not for the OP, for future readers.

2011-01-25 07:32
by eran


I don't think you can disable this behaviour, however there is a way around it if you are using Visual Studio and don't mind getting flooded in exceptions. If you go to Debug>Exceptions in VS and select "When the exception is thrown>Break into the Debugger" for C++ exceptions, it will drop into the debugger at the point the exception is thrown. Unfortunately you then get to work out which exceptions you can ignore and which ones are of interest to you.

The default setting for this is "Continue" with "If the exception is not handled" being set to "break into the debugger". If it doesn't do that already this would suggest that you'll have to find out exactly where the exceptions are being caught.

2009-06-16 10:13
by Timo Geusch
I have a problem here in that I'd like to not necessarily be attached to the process prior to the crash. I'd like to run the application normally, but have the option of attaching when I see the crash dialogue. (Exactly as you can for normal application crashes - pauldoo 2009-06-16 10:16
I tried investigating where COM was swallowing the exception and it led me deep into the bowels of COM that I didn't really understand. Perhaps I should pursue this - pauldoo 2009-06-16 10:20
There might be another way around this if you know roughly whereabouts in the code the exception is thrown. It's a tad nasty and strictly debug only, but you could conceivably replace 'throw' with a macro that emits a "__asm int 3;" before the actual throw statement. That way, you'd get a debug breakpoint on every statement. Of course, leaving that in production code is a really bad idea - Timo Geusch 2009-06-16 10:34


If I understand correctly, your problem is essentially the inability to get a stack trace from a C++ exception. I've never tried it myself, but it should actually be possible to get the stack trace even from within the catch block.

See: Getting an exception call stack from the catch block

The article describes the process of getting the stack trace using a debugger, but if you don't want one to be attached you can create a dump in the catch clause (one way, another), and then go through the process on your leisure.

2009-06-16 10:43
by eran


Have a look at Vectored Exception Handlers -- depending on your exact use case, VEH could be used to intercept SEH exception handling and force crashes/dumps/whatever.

2009-06-16 11:52
by Johannes Passing


You can set up a level 2 break in debugger with sxe/sxd -c2 eh that will catch only unhandled C++ exceptions. You can also attach the debugger on the fly to your process at load time using GFlags. Of course you'd have to give up the mickey mouse debugger and use the real deal.

2009-06-16 10:32
by Remus Rusanu


What you need is to enable "break when an exception is thrown" in your debugger. This way you will stop immediately when an exception is thrown and have the entire call stack at your service.

2009-06-16 10:10
by sharptooth
Unfortunately this stops me on every exception that is thrown. I only want to break on uncaught exceptions - pauldoo 2009-06-16 10:11