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.
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 keep getting the following error in visual studio:
http://i.stack.imgur.com/qKyk8.png
However if I click continue my application runs perfectly fine, every time I run it it does this. As you can imagine this is incredibly annoying. I have gone through the exception settings to try and find something under runtime, error, runtime_error, std and so on. I was not able to find anything that matched the description of the error. Additionally I have no idea what is causing this to popup in the first place, as how am I supposed to know what is using that memory location?
You can disable it by properly handling the cause of the exception being thrown. Debug your code to find what is causing the exception.
Try going to exception settings, add new C++ exception: std::runtime_error and uncheck it. Or just stop breaking in any C++ exceptions at all.
I'm working on the development of a software in C++ on Visual Studio 2010. As this software should be run on servers where human interaction is not available, I really really need to get rid of this "program.exe has stopped working" window that pops up in the release version in case of errors. I just want the program to terminate (maybe also give an error message, but not necessarily) and not have it remain blocked waiting for someone to click the "Close the program" button. I have to mention that I have 64 bit Windows 7 Professional on my machine.
I have read about several things, such as:
the _set_abort_behavior function. This solves the case when abort() is called, but that is not the case for errors like "vector subscript out of range".
I know I could be solving some of these errors by doing exception handling, but not all errors are exceptions, therefore this would not solve my entire problem.
I've also read something about the Dr. Watson debugger, which is supposed to terminate the application silently, but I have the impression that this debugger is not available for Windows 7. Plus I don't know if this debugger would solve my problem in the release mode...
I don't find that disabling Error Reporting on my entire machine is an elegant option, although I read that this could also be an alternative (not really one that I want to take).
How can I do this in Visual Studio? Are there any settings I could use?
Is there maybe a way to turn all errors in exceptions in Visual Studio, so that I can solve the problem with the exception handling mechanism? (please be tolerant if this was a stupid question)
I'm looking forward to your proposals. Many thanks for your time!
Best regards,
Cornelia
You can use
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
MSDN documentation for SetErrorMode
You can also refer here
Hope this will solve your problem...
A good way is to add your own unhandled exception filter (see SetUnhandledExceptionFilter() docs) and then write a log and a mini dump so that you can do whatever error handling you need to (eg close devices/handles) and you also have a crash dump that you can analyse later. Useful information in this answer: https://stackoverflow.com/a/1547251/188414
Sometimes this error occurs only because you have not added a & sign before the value you have used in scanf
Try the following which solved my problem
From
scanf("%d",code);
To
scanf("%d",&code);
I am writing a C++ COM object in Visual Studio 2008 that is an Internet Explorer Browser Helper Object. Recently, when running in IE, IE has started frequently popping up a dialog titled "Microsoft Visual C++ Runtime Library" with an error message "Runtime Error!" and going on to say that "The application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." Unlike usual, this dialog only has an OK button but no debug button, so IE then terminates and I'm not left with so much as a stack trace or even a hint of what part of my code could have been so buggy. I'm not sure where in my code it is crashing.
How does one troubleshoot a "Runtime error" problem? What are possible causes of a runtime error? (memory related bugs perhaps?) What sort of problems should I be checking my code for to attempt to eliminate this sort of crash? I need some ideas on how to troubleshoot this one, its a bit elusive.
When you see that dialog, start VS2008 with your COM object project.
Then use the menu Debug->Attach to process to attach the debugger to the IE process which has your COM object loaded.
Then break into the process (Debug->break all) and you get the stack trace.
It bombs due to an unhandled exception. That gives you a chance to make the debugger stop on the first chance exception, right at the point where it is raised. Open your project, make iexplorer.exe the startup program. Debug + Exceptions, check the Thrown flag on the unmanaged exceptions. Make it crash to get the breakpoint.
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.