tags:

views:

117

answers:

5

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.

A: 

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.

sharptooth
Unfortunately this stops me on every exception that is thrown. I only want to break on uncaught exceptions.
pauldoo
+2  A: 

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.

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
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
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
A: 

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.

Remus Rusanu
+2  A: 

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.

eran
+1  A: 

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.

Johannes Passing