In MSVC, how can I make any unhandled C++ exception (std::runtime_error, for instance) crash my release-compiled program so that it generates a dump with the full stack from the exception throw location?
I have installed NTSD in the AeDebug registry and can generate good dumps for things like memory access violation, so the matter here comes down to crashing the program correctly, I suppose.
Thanks in advance.
I finally cracked it down.
Use the set_terminate() function to register a handler for every thread
In you main function(), make it impossible for external DLLs (event Windows') to successfully call SetUnhandledExceptionFilter(). A great article on how to do that here: http://www.debuginfo.com/articles/debugfilters.html#overwrite .
As for the handle itself, it is quite straightforward:
void Terminate()
{
OutputDebugStringA("Terminate\r\n");
RaiseException(0xE0000010, EXCEPTION_NONCONTINUABLE, 0, 0);
}
Calling RaiseException() like the above example is enough to make the process crash and produce my mush desired dump.
Just so you know, the problem I was having was:
The IPHelper Windows API loads dynamically another Windows DLL
This DLL uses Windows own version of the C runtime (MSVCRT instead of MSVCRT90)
The new C++ runtime calls SetUnhandledExceptionFilter() on startup to catch C++ exceptions. Since the latest filter for C++ exceptions is the one who gets to call the handle set by set_terminate(), my handle wasn't called.
SetUnhandledExceptionFilter and DebugBreak should probably do the job.
Edit: oops, rereading, you want to deal with uncaught C++ exceptions. That would be a bit trickier to do well -- by the time you (normally) get wind of a C++ exception, it's already unwound the stack back to the level of the handler. You don't have any real way to know an exception has been thrown until a catch is invoked, but by then the stack has been unwound.
Look into using the Windows Debugger.
Windbg – wraps KD and NTSD with a decent UI.
Also check out ADPlus that comes with the Windows Debugger.
Here is a good place to start learning how to use it.
Related
In GDB and other debuggers it's possible to ask the debugger (using catch throw) to stop anytime an exception is thrown before the process passes said exception to the respective exception handler.
By what mechanism is this possible? Is there an OS signal that can be used to hook in? Is there a function pointer to monkey patch to allow this? Does it single step to make this happen?
Is this mechanism otherwise available outside the debugger?
GDB sets a breakpoint on the library function which does the stack unwinding (__cxa_throw() for x86_64) to implement catch throw. It will use the same mechanism to set this breakpoint it uses to set any other type of code breakpoint.
By what mechanism is this possible? Is there an OS signal that can be used to hook in? Is there a function pointer to monkey patch to allow this? Does it single step to make this happen?
None of these. It is just a normal breakpoint on __cxa_throw(). GDB uses knowledge of the implementation of the C++ runtime, with all the disadvantages that brings. C++ exceptions are below the radar of the operating system, so the operating system would not know about them. The confusion stems from the fact that certain signals (e.g. segfaults) are called exceptions on Windows and can be handled in a very similar way to C++ exceptions on Windows when debugging. But this is making OS-signals (e.g. segfault) behaving like C++ exceptions, not the other way round.
See also ftp://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_30.html
I have an exception handler set up using SetUnhandledExceptionFilter, which works fine. However, if I throw an exception from within OpenMP code, I get the standard "the application crashed" window and the handler is not called -- however, I can attach a debugger just fine and see that the call stack is ending with _CxxThrowException and continues into KernelBase.dll!RaiseException. I know that an OpenMP program which throws exceptions inside the parallel regions is wrong, but I'd still like to get a crash dump. How can I get my exception handler get called in this case?
Should be possible, especially as the debugger manges to get an "Unhandled exception" window, when attached to the application after the crash (i.e. I can get a nice stack trace and stuff.) This is on Windows 7 with VC++ 2010.
(Eventually, each thread actually calls my exception handler. If it crashes, and I select 'Debug', and then continue on each unhandled exception, the handler eventually gets called and it also manages to write out a meaningful minidump. Wtf?)
Interesting. Going out on a limb, I'll wager that the OpenMP concurrency runtime doesn't honor the SetUnhandledExceptionFilter (which will work for "standard" threads), and isn't integrated into this feature of Structured Exception Handling.
Note this warning from the MSDN page on Exception Handling in the Concurrency Runtime
To prevent abnormal termination of your application, make sure that your code handles exceptions when it calls into the runtime. Also handle exceptions when you call into external code that uses the Concurrency Runtime, for example, a third-party library.
Perhaps you can try wrapping your OpenMP stuff in the style of exception handling outlined above, and then see if you can re-package and throw it (outside of OpenMP context) to get caught by the filter?
When my Visual Studio 2008 C++ command-line application crashes, it sometimes produces this dialog.
CommandProcessor.exe has encountered a problem and needs to close.
We are sorry for the inconvenience. If you were in the middle of something, the information you were working on might be lost. For more informaiton about this error, click here.
I tried this in Release and in Debug mode.
(By the way, the debugger shows that this is a divide by zero error.)
If it is going to crash, I don't want this dialog, which blocks the application. How do I compile my application so that crashes do not produce the dialog?
With /EHa option you can use catch(...) to catch all exceptions included structured exceptions and write a console message. You can also use VC++ - specific __try for structured exception handling instead, but that's a bit harder to code.
However this will not protect you against situations when terminate() is called by the C++ runtime - like when an exception escapes a destructor during stack unwinding - you will also have to change the terminate() handler by calling set_terminate().
Read series of articles Exception Handling and Crash Reporting. It is possible to catch exception and process it as you wish (you can save crash dump for instance).
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.
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.
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.
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.
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.
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.
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.
Our application is using mshtml. That dll is causing our application to exit ungracefully due to well known problems in mshtml since we don't install newer browsers on users' machines. We just use what they have already.
The SetUnhandledExceptionFilter() does not handle this, nor does a try/catch block around the calls into mshtml. The exception filter does catch other exceptions.
The exception settings are /EHa.
When I remote debug the crash I see:
unhandled exception - access violation
In mshtml but if I don't attach to the process with a debugger, the application just exits.
What do we need to do to catch the exception?
Edit:
This is an old version of IE6.
Seems to be that MSHTML functions passes necessary data to a separate thread. That separate thread processes your request and the exception takes place. That's why you cannot catch exception via try/catch block. You should check it in the debugger. If that is true the only way to catch exceptions from other threads is to set hooks for TerminateThread and TerminateProcess functions. Check out CApiHook class by Jeffrey Richter for that purpose(or other implementations). But it will make your program to be incompatible with /NXCOMPAT compiler flag.
Your second option is to install all important OS updates.
Almost there. It's not SetUnhandledExceptionFilter() but AddVectoredExceptionHandler you want. With that said, you can get the first shot at this exception.
Of course I'm wondering what you're going to do afterwards. TerminateThread is probably the only option you have, but that may very well deadlock MSHTML. So that needs killing too.