In my Qt application (VC12, Qt Creator, Qt 5.3) I see an issue when I close my application:
As I have no idea why (where caused?, my fault?) I have tried to find the root cause. I have used the breakpoint types (see also here)
Break when C++ exception is thrown
Break when C++ exception is caught
However, these breakpoints are never hit (or, at least the application never stops at such a breakpoint). I wonder:
How can it be, that I see an exception issue, but being unable to detect it with one of the breakpoints above?
Related
A variety of other questions hint that it is possible to continue debugging past an "Exception Unhandled" popup like this:
This is the popup from Visual Studio 2019, but VS 2015 gives similar behaviour. In both cases, for all combos of Win32/x64 and Debug/Release I have tried, the debugger refuses to go past the point that throws the unhandled exception - the same popup pops up again on each attempt to continue. I would like to push past this point and continue into the code I have set up via SetUnhandledExceptionFilter(). Is that possible?
This strongly upvoted answer suggests that it might be, via an option under Tools -> Options then Debugging -> General regarding unwinding the stack... but a comment on the answer suggests the option may have disappeared from VS2017. I found the option in VS 2015, but it does not have the desired effect. Is the accepted answer to that question therefore correct despite fewer votes - that continuing to debug past an unhandled exception is not possible by design?
Yes - it's possible. If you get to that pop up repeatedly, and the exception settings are such that the exception is NOT intercepted by the debugger (and therefore passed to the application's own exception handling), then it could be that your "unhandled" exception handling has already run, or does not exist in the form you think it does. Double-check where you have set breakpoints and make sure they are ones that stand to be hit.
Note also that if you have something like this to catch SEH exceptions (such as integer divide by zero):
__try
{
// set up and run the application
}
__except( RecordUnhandledException( GetExceptionInfo() ) )
{
}
... then the debugger can hide RecordUnhandledException() from you. That is, if you set a breakpoint on the line where the exception is (deliberately) thrown, and try to step into it, the debugger may step straight back to that point by executing the handling code in a single step that makes it invisible to you. However, if it produces other output, you should be able to see that output. If not, it may take an explicit breakpoint within RecordUnhandledException() to reveal that it exists and step through its logic.
I making a WinAPI DLL using CLion and debugging via LLDB debugger (inside CLion). So breakpoints work fine, however, if there's uncaught exception in my DLL target process crashes and debugger doesn't break when it does. But if there's exception in the target process, debugger breaks fine. Is there any workaround?
Did you enable breaking on exception in Run menu - View breakpoints window?
this happens to me often and almost always the culpret is that the section marked Disable until hitting the following breakpoint: is set to Any Exception. simply change that value to None and the debugger will break when an exception is thrown.
i have no idea how or why this setting is changing itself to that value but, whenever it does, exception breakpoints stop working.
I'm a beginner with the windows api so there must be something i don't understand here. In my main function i'm using a try-catch to catch all uncaught exceptions, but for some reason, exceptions i throw from somewhere else in the code are never caught. My application uses a single (main) thread.
I'm throwing like this :
throw "ClassName::methodName() - Error message";
And catching the exceptions outside of the message loop :
try {
while(GetMessage(args...)) {
TranslateMessage(args...);
DispatchMessage(args...);
}
}
catch( const char * sExc ) {
::MessageBox(args...);
}
I first thought it was a problem of types mismatching, but then i added a catch(...) with ellipsis and i still caught nothing. If you ask, yes, i'm sure the exception is thrown. Isn't it a problem related to some kind of asynchronousness or something like that ?
Thanks for your help !
It depends on the specific message that's getting dispatched. But no, not all of them allow the stack to be unwound through Windows internal code. Particularly the messages that involve the window manager, WM_CREATE for example. There's a backstop inside Windows that prevents the stack from being unwound past that critical code. There's also an issue with exceptions in 32-bit code that run on the 64-bit version of Windows 7, they can get swallowed when the message needs to traverse the Wow64 boundary several times. Fixed in Windows 8.
On later Windows versions this can also activate "self-healing" code, automatically activating an appcompat shim that swallows the exception. You'll get a notification for that, easy to dismiss. You'll then see the first-chance exception notification in the VS Output window but your program keeps running. Okayish for the user perhaps but not great while you are debugging of course. Run Regedit.exe and navigate to HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted and check if your program is listed there. Just delete the entry.
Long story short, it is not safe to catch exceptions outside of the message loop. You have to do it inside the window procedure.
You are talking about "Windows Structured Exception Handling" (http://msdn.microsoft.com/en-us/library/windows/desktop/ms680657%28v=vs.85%29.aspx). C++ exceptions are not thrown.
If you want to go the troublesome route: _set_se_translator
See also: Can a C program handle C++ exceptions? (The windows API is not C++)
I am using the debug_new tool that come in the pack of tools NVWA made by Wu Yongwei. http://wyw.dcweb.cn/
I turned it off once to track a heisenbug, that now is fixed. But as I turned it on, my program throws a bizarre error:
It loads, but before accepting any input it quits and writes on the console:
"This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information
Process returned 3 (0x3) execution time : 0.828s"
How I debug that? I have no idea what on the code is throwing the error (since when using a debugger it still quits the same way, and the debugger reports no errors with exit of the debugger being 0)
EDIT for those that don't read tags: I am using C++, compiling with MingW on Windows.
If you're running under the Visual Studio debugger, go to the Debug/Exceptions menu and check the box for the "C++ Exceptions" item - this will cause the debugger to break whenever an exception is thrown.
You might need to fiddle with the various sub-options (std:exception, void, etc) for the exception types if your code throws a lot of exceptions that it catches and you're not interested in breaking into the debugger when they get thrown.
KB884538 -- try installing the hotfix.
This might be a GDB question.. but I'd like to run my app in the debugger and have the debugger break when an exception is thrown, so I can see where the code is and what its doing at that time.
I do this often in Visual Studio using the Debug -> Exceptions dialog, checking the 'Thrown' column beside the type of exceptions I'd like to stop on.
Alex
You can get the equivalent of gdb catchpoints in eclipse by:
From breakpoints view, invoke action(small triangle pointing downwards near the maximize button) -> Add Event Breakpoint (C/C++) -> Exception Thrown.
The best I found is news.eclipse.tools.cdt: Re: Catching C++ exceptions at point of throw:
Meanwhile, you can go at the GDB
console in eclipse and type "catch
throw", like you are did with gdb,
'til we find away to integrate this
feature in CDT.