Getting sensible info from CLR-to-SEH exceptions in a mixed mode C++ project

Question

Mixed mode C++ project. Native code is calling managed code. Managed code might throw an exception. I can catch said exception in native mode using a vectored exception handler; I can see its PEXCEPTION_POINTERS. The telling code 0xE0434F4D, meaning it's a CLR exception, is there.

Question: is there any way to get any sensible information (exception class, message, stack trace etc.) from the attendant data? There's one parameter in the ExceptionInformation, and it looks like a pointer to something...

No, that's too late. All you got is the exception code. You might get something in ExceptionInformation if the original managed exception was caused by a processor fault. Like NullReference or AccessViolation. This won't be helpful since you don't know the original SEH exception anymore. Using COM give you a better mouse trap, the CLR implements IErrorInfo. But the managed code you're trying to run is probably not [ComVisible]. Calling the code through a managed stub that catches Exception might be a better angle. — Hans Passant, Nov 04 '11 at 21:54
@HansPassant, no offence - but that's not a comment, it's an answer. Make it so! — Moo-Juice, Nov 04 '11 at 21:58
"managed stub that catches Exception" - elaborate, please. Is there a way to install a single stub that somehow catches all managed-to-native transitions? I have several entry points into managed code, and I don't want to place a try{}catch(){throw} around each. — Seva Alekseyev, Nov 04 '11 at 22:25

score 1 · Accepted Answer · answered May 30 '12 at 15:00

No, that's too late. All you got is the exception code. You might get something in ExceptionInformation if the original managed exception was caused by a processor fault. Like NullReference or AccessViolation. This won't be helpful since you don't know the original SEH exception anymore. Using COM give you a better mouse trap, the CLR implements IErrorInfo. But the managed code you're trying to run is probably not [ComVisible]. Calling the code through a managed stub that catches Exception might be a better angle.

I'm posting this as answer in spirit of following blog post http://www.joelonsoftware.com/items/2008/09/15.html — Willem D'Haeseleer, May 30 '12 at 15:01

score 1 · Answer 2 · edited Nov 07 '12 at 18:49

There is similar answer to this question here:
Catching a CLR exception through unmanaged code

This was resolved in the following manner:

#import <mscorlib.tlb> raw_interfaces_only no_smart_pointers named_guids no_implementation

ATL::CComPtr< IErrorInfo > spErrorInfo;
ATL::CComPtr< mscorlib::_Exception > spCLRException;
ATL::CComPtr< mscorlib::_Exception > spCLRInnerException;

ATL::CComBSTR bstrCLRStackTrace;
ATL::CComBSTR bstrCLRMessage;

GetErrorInfo(0, &spErrorInfo)
spErrorInfo.QueryInterface(&spCLRException)
spCLRException->get_InnerException(&spCLRInnerException)
spCLRInnerException->get_StackTrace(&bstrCLRStackTrace)
spCLRInnerException->get_Message(&bstrCLRMessage)

Getting sensible info from CLR-to-SEH exceptions in a mixed mode C++ project

2 Answers2

Linked