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);
Related
TLDR
When one of my applications executes _CrtDbgBreak() it just writes a .dmp file and exits. On any other application _CrtDbgBreak() causes the app.exe has stopped working -dialog where I can chose to break into my debugger (VS 2013).
This is my desired behavior.
Background
A few weeks ago I experimented with Windows Error Reporting to find out if/how the WER Dialog could be suppressed. Apparently I succeeded for my application and unfortunately I haven't found the way how to undo this.
In the meantime I have had to deal with a number of other things so that I no longer remember which steps I exactly took at the time. (Should have taken notes, I know.) Since it works for other applications, I am guessing a setting specific to my app needs to be reset.
I turned to the usual suspects on my machine but so far I haven't found anything:
HKCU\Software\Microsoft\Windows\Windows Error Reporting
HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting
Policy Editor: Computer Configuration\Administrative Templates\Windows Components\Windows Error Reporting
Policy Editor: User Configuration\Administrative Templates\Windows Components\Windows Error Reporting
WER Service is running
I have even removed all occurrences of my executable's name from my entire registry but this hasn't made any difference. What else am I missing?
One possible reason is your app/exe is added to the WER's exclusion list. See 'ExcludedApplications' at https://learn.microsoft.com/en-us/windows/desktop/wer/wer-settings.
https://learn.microsoft.com/en-us/windows/desktop/api/Werapi/nf-werapi-weraddexcludedapplication
Check registry at: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ExcludedApplications
If your app/exe name is found there, remove it.
Maybe you'd set the process error mode, like so
SetErrorMode(SEM_NOGPFAULTERRORBOX);
(see https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode)
[yes - the question is dated, but it's not marked as answered, and this alternative solution may help future readers]
I've experienced this with every version of Visual Studio starting from 2012 (2012, 2013, 2015 Preview), on multiple computers and multiple projects, but I haven't figured out how to fix it:
Whenever I'm debugging a 64-bit(?) C++ console program, after a few minutes and seemingly completely randomly (when I'm not clicking or typing anything), the console window for the program spontaneously closes and I can no longer debug or step through the program with Visual Studio. When I press Stop and attempt to restart debugging, I usually get ERROR_NETWORK_UNREACHABLE:
// MessageId: ERROR_NETWORK_UNREACHABLE
// MessageText:
// The network location cannot be reached. For information about network troubleshooting, see Windows Help.
#define ERROR_NETWORK_UNREACHABLE 1231L
If I try to attach to the process manually I get the error:
Unable to attach to the process.
The only fix I've found for this is to restart Visual Studio. I can't find any other way to fix it, and I've tried running Process Monitor but haven't found anything.
What causes this problem and how can I fix it?
(?) Upon further checking it seems that this only happens in 64-bit mode, but I'm not 100% sure.
Ok, this is just so wrong
I also have issues with this bug, and in my case it occurred every other debug session. Which meant debug -> stop -> debug -> bug -> restart visual studio -> go to start (repeat every minute during the whole day).
Needless to say I was driven to find a solution. So yesterday I tried procmon, spend hours looking at API monitor differences, looked at plugins, netstat, etc, etc, etc. And found nothing. I gave up.
Today
Until today.
To track down a stupid bug in my program today, I launched appverifier. For my application, I ran the 'basics' tests and clicked save. After a few hours this led me to the bug in my program, which was something like this (extremely simplified version):
void* dst = _aligned_malloc(4096, 32);
memcpy(dst, src, 8192);
Obviously this is a bug and obviously it needed fixing. I noticed the error after putting a breakpoint on the memcpy line, which was not executed.
After a stop and 'debug' again I was surprised to find that I could actually debug the program for the second time. And now, several hours later, this annoying bug here hasn't re-emerged.
So what appears to be going on
So... apparently data from my program is bleeding through into the data or execution space of the debugger, which in turn appears to generate the bug.
I see you thinking: No, this shouldn't happen... you're right; but apparently it does.
So how to fix it? Basically fixing your program (more particular: heap corruption issues) seems to make the VS debugger bug go away. Using appverifier.exe (It's in Debugging tools for Windows) will give you a head start.
Why this works
Since VS2012, VC++ uses a different way to manage the heap. Hans Passant explains it here: Does msvcrt uses a different heap for allocations since (vs2012/2010/2013) .
What basically happens is that heap corruption will break your debugger. The AppVerifier basic settings will ensure that a breakpoint is triggered just before the application does something to corrupt the heap.
So, what happens now is that before the process will break the heap, a breakpoint will trigger instead, which usually means you will terminate the process. The net effect is that the heap will still be in-tact before you terminate your program, which means that your debugger will still function.
"Test"
Before using appverifier -- bug triggered every 2 minutes
While using appverifier -- VS debugger has been stable for 5 days (and counting)
This is an environmental problem of course. Always hard to troubleshoot, SysInternals' utilities like Process Monitor and Process Explorer are your primary weapons of choice. Some non-intuitive ways that a network error can be generated while debugging:
Starting with VS2012, the C runtime library had a pretty drastic modification that can cause very hard to diagnose mis-behavior if your program corrupts the heap. Much like #atlaste describes. Since time memorial, the CRT always created its own heap, underlying call was HeapCreate(). No more, it now uses GetProcessHeap(). This is very convenient, much easier now to deal with DLLs that were built with /MT. But with a pretty sharp edge, you can now easily corrupt the memory owned by Microsoft code. Not strongly indicated if you can't reattach a 64-bit program, you'd have to kill msvsmon.exe to clear up the corruption.
The Microsoft Symbol Server supplies PDBs for Microsoft executables. They normally have their source+line-number info stripped, but not all of them. Notably not for the CRT for example. Those PDBs were built on a build server owned by DevDiv in Redmond that had the source code on the F: drive. A few around that were built from the E: drive, Patterns+Practices uses that (unlikely in a C++ program). Your debugger will go look there to try to find source code. That usually ends well, it gives up quickly, but not if your machine uses those drive letters as well. Diagnose by clearing the symbol cache and disabling the symbol server with Tools + Options, Debugging, Symbols.
The winapi suffers from two nasty viral infections it inherited from another OS that add global state to any process. The PATH environmental variable and the default working directory. Use Control Panel + System + Advanced + Environment to have a look at PATH, copy/paste the content of the intentionally small textboxes into a text editor. Make sure it is squeaky clean, some paralysis at the usual mess is normal btw. Take no prisoners. Having trouble with the default directory is much harder to troubleshoot. Both should pop out when you use Process Monitor.
No slamdunk explanations, it is a tough problem, but dark corners you can look in.
I have the same problem. Thought it was related to 64 bit console apps, where it is very easily triggered with almost any debug session. But, it also happens on 64 bit windows apps too. Now I am seeing it on 32 bit windows apps. I am running Windows 8.1 pro on a single desktop with the latest version of vs 2013 and no remote debugging. My (added) extensions are Visual Assist, Advanced Installer, ClangFormat, Code Alignment, Code Compare, Duplicate Selection, Productivity Power Tools 2013, and Visual SVN.
I discovered that the "Visual Studio 2013\Settings\CurrentSettings.vssettings" file gets corrupted. You can delete this file and recreate it by restarting VS or you can try to edit the XML. I then keep a copy of a good settings file that I use to replace when it gets corrupted again.
In my case, the corrupted line begins with
</ToolsOptionsSubCategory><ToolsOptionsSubCategory name="XAML" RegisteredName="XAML"
... and it is extremely long (I think this is why it is prone to corruption).
I just disabled in the Menu
Tools > Options
Debugging > Edit and Continue
Native-only options > Enable native Edit and Continue
and now it does not give the that stupid error which was preventing the starting of the debuggee application.
I also had the same problem with VS2015. It was so frustrating that a simple Hello World program gave this error when I ran debugger for the second time. Tried uninstall and reinstall and didn't work.
Finally, the solution mentioned in https://social.msdn.microsoft.com/Forums/vstudio/en-US/8dce0952-234f-4c18-a71a-1d614b44f256/visual-studios-2012-cannot-findlaunch-project-exe?forum=vsdebug
worked. Reset all visual studio settings using Tools->Import and Export settings. Now the issue is not occurring.
The problem
There seems to be a problem with my application, because it crashes unexpectedly. I'm trying to solve the problem, but I have the following problem:
On Windows 7, when the application crashes, instead of getting some useful information about the crash, the following window appears:
The question
Is it possible to make Windows (7) show some actual useful information? Like a stack trace? Memory dump? A weird error code? Anything? I highly doubt Microsoft can help me here... in fact, checking for a solution to the problem never found a solution for any application, I don't know why this window even exists.
I remember that on Windows XP, there was that Error report window, and somewhere there was a link to another window which actually displayed some information.
What I tried
I tried to handle application crashes myself, using signal handling. However signal handling using MinGW seems to be pretty broken: writing to a null pointer should send a SIGSEGV signal, but the program crashed. Looking up on the internet, I found this thread which led me to believe that signal handling may be broken.
Using GDB with multiple threads is giving me a lot of trouble, since there is some time-sensitive stuff being done.
Other note(s)
I am working on Windows 7 (obviously), using the MinGW compiler suite, Eclipse IDE.
when this window appears, don't click Cancel. About 1 or 2 minutes later it will become another window that allow you choose a specified compiler(on my computer it's visual studio 2010) and debug.
When the compiling of a project is complete (or at least when it says it does), I receive no window, no error message, or anything; VC++ freezes up and my computer basically stops responding altogether.
After about five minutes, Task Manager finally pops up and I'm able to close the program. Upon doing that, I see this:
I'm going to take a wild guess here and say something is wrong with the image above. On a side note, the process' (MSBuild.exe) don't (seem) to open all at once, but that may only seem that way because the computer becomes frozen multiple times until I shutdown vc++.
Is this a known issue and if so what should I do so I can compile programs without this issue once again?
Additional Information:
Windows 7
Microsoft Visual C++ 2010 xpress
Project Type(s): I've tried on "Windows Form Application" project and "Win32 Project", both produce the same results.
Compiling projects in VB works as it should. (in case this helps at all)
As suggested by Hans Passant, disabling avast! solved the problem.
Did any error pop up during installation?
The standard thing to do (that almost always helps) is rebooting, reinstalling, (rebooting,) and trying again. Chances are absolutely nobody knows what's going wrong (even MS).
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.