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.
Related
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?
I have a C++ app that will throw an exception when I try to single step from a breakpoint. For example:
1) Start app from VS2010 0 debugger is attached.
2) Set a breakpoint. It doesn't seem to matter where.
3) Do something in the app so that it hits the break point.
** VS2010 hits the break point
4) Single step the debugger to the next line of code.
VS2010 pops up a message box with this exception:
"Unhandled exception at 0x087df66f in SimpleGraphSDI.exe: 0xC0000005: Access violation."
Note that if I set a breakpoint on two consecutive lines of code, and press run to advance from one line to another, the app "runs" to the next line of code with no issues. The access violation is only when I use the single step command from VS2010.
Some code in the app has been around since VC6 and maybe earlier. However do not know if this is relevant.
UPDATE: The exception when single stepping the debugger does not occur if I start the app, and then attach the debugger after the app has started.
I had this exact same issue. I was able to solve it by starting VS from the command line telling it to reset the UI to default (/ResetSettings) Details on the command line arguments are here
I did not need to reboot after resetting VS, but I did a full rebuild of the project after completing the reset of the environment.
A work around for this problem is to disable RPC debugging.
In the Visual Studio 2010, Visual Studio 2010 SP1 toolbar select below steps -
Tools->Options->Debugging->Native and deselect "Enable RPC debugging"
There maybe exist a thread that somehow detects that the code is being debugged step by step and pagefaults in response to prevent you from debugging. Try to locate that thread by suspending threads one by one.
Also, is address 0x087df66f always the same? If it is then you can set a breakpoint there and look around when the breakpoint is hit.
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.
I have a Windows application written in C++ that occasionally evaporates. I use the word evaporate because there is nothing left behind: no "we're sorry" message from Windows, no crash dump from the Dr. Watson facility...
On the one occasion the crash occurred under the debugger, the debugger did not break---it showed the application still running. When I manually paused execution, I found that my process no longer had any threads.
How can I capture the reason this process is terminating?
You could try using the adplus utility in the windows debugging tool package.
adplus -crash -p yourprocessid
The auto dump tool provides mini dumps for exceptions and a full dump if the application crashes.
If you are using Visual Studio 2003 or later, you should enable the debuggers "First Chance Exception" handler feature by turning on ALL the Debug Exception Break options found under the Debug Menu | Exceptions Dialog. Turn on EVERY option before starting the debug build of the process within the debugger.
By default most of these First Chance Exception handlers in the debugger are turned off, so if Windows or your code throws an exception, the debugger expects your application to handle it.
The First Chance Exception system allows debuggers to intercept EVERY possible exception thrown by the Process and/or System.
http://support.microsoft.com/kb/105675
All the other ideas posted are good.
But it also sounds like the application is calling abort() or terminate().
If you run it in the debugger set a breakpoint on both these methods and exit() just for good measure.
Here is a list of situations that will cause terminate to be called because of exceptions going wrong.
See also:
Why destructor is not called on exception?
This shows that an application will terminate() if an exceptions is not caught. So stick a catch block in main() that reports the error (to a log file) then re-throw.
int main()
{
try
{
// Do your code here.
}
catch(...)
{
// Log Error;
throw; // re-throw the error for the de-bugger.
}
}
Well, the problem is you are getting an access violation. You may want to attach with WinDBG and turn on all of the exception filters. It may still not help - my guess is you are getting memory corruption that isn't throwing an exception.
You may want to look at enabling full pageheap checking
You might also want to check out this older question about heap corruption for some ideas on tools.
The most common cause for this kind of sudden disappearance is a stack overflow, usually caused by some kind of infinite recursion (which may, of course, involve a chain of several functions calling each other).
Is that a possibility in your app?
You could check the Windows Logs in Event Viewer on Windows.
First of all I want to say that I've only a moderate experience on windows development.
After that I think this is a typical case where a log may help.
Normally debugging and logging supply orthogonal info. If your debugger is useless probably the log will help you.
This could be a call to _exit() or some Windows equivalent. Try setting a breakpoint on _exit...
Have you tried PC Lint etc and run it over your code?
Try compiling with maximum warnings
If this is a .NET app - use FX Cop.
Possible causes come to mind.
TerminateProcess()
Stack overflow exception
Exception while handling an exception
The last one in particular results in immediate failure of the application.
The stack overflow - you may get a notification of this, but unlikely.
Drop into the debugger, change all exception notifications to "stop always" rather than "stop if not handled" then do what you do to cause the program failure. The debugger will stop if you get an exception and you can decide if this is the exception you are looking for.
I spent a couple hours trying to dig into this on Visual Studio 2017 running a 64-bit application on Windows 7. I ended up having to set a breakpoint on the RtlReportSilentProcessExit function, which lives in the ntdll.dll file. Just the base function name was enough for Visual Studio to find it.
That said, after I let Visual Studio automatically download symbols for the C standard library, it also automatically stopped on the runtime exception that caused the problem.