VC + + Runtime Error exception capture of the program __c++

VC + + Runtime error, for many friends, this is a very annoying error hint, you may not know how to start debugging: What is the cause of this error? It is true that only by knowing the direct cause of this error can you debug this error.

Just encountered this error, is the video decoding, because the decoding has been working state, so I do not know how to debug, when this error occurred, we mostly ignored, want to solve from other places, improve stability, and even doubt the stability of the decoder; Later, I contacted the decoding library, began debugging such a mistake, the beginning of such a mistake is not easy to reproduce, often a few hours, when this error recurs, the program is still running, but one of the threads interrupt the execution, which the thread popped up "VC + + Runtime Error "Such a dialog box, if you click on it, then the entire application will exit directly." In order to debug, I can not click on this dialog, but use VC2005 attachment to the process, and then directly interrupt the process, this time, there will be a thread breakpoint in the dialog box in the message loop, carefully look at the stack, found a function: Msvcrt.dll!_abort (), here is the time Check out MSDN:

Function Name: abort

Function: Exception terminates a process

Usage: void abort(void);

In a single or multithreaded windows-based application, abort calls the Windows MessageBox function to create a M Essage box to display the "message" with aOK button. When the user clicks OK, the program aborts immediately.

Our program is based on the WinDOS window of multi-threaded applications, called Abort will pop-up dialog, in release version, is a confirmation dialog box, click on the program prompts error and exit.

    in normal programs, we will not invoke abort unless we encounter a serious, unrecoverable error .  so exactly how this abort is invoked, our own code is clearly not this function, Then look at the stack,  discovery is in a C language version of the Open Source Library .  Our program is required to run 7 * 24 hours, the occurrence of the decoding exception should be ignored by us, rather than application crashes. Open source Cross-platform Decoding library is C language written,  in a serious error, directly abort this is understandable, however, such procedures in our code is obviously to avoid .  eldest brother, now is what era, a lot of procedures are needed to run, I have to change the library source code to recompile the program to solve this problem, how to change, if to analyze the logic of decoding, we do not have professional talent .  I want to simply start from the Abort function here, directly return the success value, but this to the decoding logic more impact, may lead to greater errors,   I think of the exception mechanism of the operating system, because we are working on the Windows platform, so we can take advantage of Windows structured exception,  we could cancel the abort call, where we use code to produce a structured exception (SEH), Structured exceptions are divided into hardware exceptions and software exceptions, the CPU can check the illegal access to memory and exceptions such as 0 errors, then we will replace the abort in addition to 0 statements, such as int i = 10/0;

When the program executes here, the CPU catches the exception and prompts the user that we can catch the error by adding SEH capture code where the decoding function is invoked, so that the program can ignore the error and continue executing.  Later facts also proved that the omission of this error has no obvious effect on the program.  How to write this capture code, the operating system supports the Seh capture code block is __try-__finally block and __try-__except block, and __try-__finnaly block can realize our function.  Write here, may have a friend to say, we usually see the most is the Try-catch statement, then I want to explain, Try-catch is a C + + exception handling mode, and __try-__finnaly is the operating system SEH exception handling mode. Try-catch in the C + + language does not capture operating system-structured exceptions (such as CPU exceptions, memory access violations, except 0 errors). C + + exceptions can only catch software exceptions, usually the exception that is generated by invoking throw, such as the CException common in MFC exceptions.

SEH exceptions and C + + exceptions are intrinsically different, SEH is an exception handling technique provided by the operating system that can be used in any programming language that supports the operating system, and C + + exception handling can only be used when writing C + + code.  However, it should be known that the VC + + compiler for Windows uses operating system-structured exceptions to implement C + + exceptions. In other words, C + + 's try block when compiled in VC + +, will become a __try block, C + + catch block will become SEH __except block: Catch test becomes SEH exception filter, catch code is changed into __except code. In fact, C + + throw block, in the compile time will also become SEH raiseexception function call, by the C + + exception to SEH exception.

The advantage of __finnally is that sometimes more detailed exception information doesn't help us much, and we just need to catch the exception and ignore it. Above mentioned C + + exception in VC + + is converted to Seh anomaly, then in VC under the use of Try-catch can catch hardware anomalies?  For example, our common 0x0000000c can not be read or written. VC + + Compiler has provided support:

try {;} catch (...)   {;}  Such statements can catch all exceptions: including CPU exceptions, and C + + exceptions; However, it should be noted that in VC6.0, it is supported by default. However, in VC2005, CPU exceptions are not caught by default. The difference is that a C + + compilation option is/EHa and only this option is open to capture SEH exceptions with the above Try-catch ().

The program occasionally appears:
Microsoft Visual C + + Runtime Library Runtime error!
Program: [AppPath] Abnormal termination
A dialog box with a red fork at the same time.

Open VC, attach the corresponding process, the Thread tab to find similar MessageBox words, found that is the pop-up dialog box, right button, go to the thread, view the call stack, generally can find the problem

According to the function call stack just now, you can find that this box is indirectly generated by ABORT, according to the ABORT source, you can find that the result is the option _write_abort_msg and _call_reportfault these two signs, One of these two flags is generated as described in the dialog box, one that produces that common Error reporting dialog box. In MSDN, there is also a function _set_abort_behavior associated with abort that can change the behavior of abort through this function.

A common error box is similar to this: the pure virtual function is a call to pure virtual functions, and its process is similar to the abort.

Test Example:

Seh Exception-handling filter
Static LONG __stdcall Myunhandledexceptionfilter (pexception_pointers pexptrs)
{
AfxMessageBox ("glllll");
return exception_execute_handler;
}
void Signalhandler (int signal)
{
AfxMessageBox ("Application aborting...\n");
}
HANDLE HANDLE;
DWORD WINAPI ThreadProc (LPVOID LP)
{
Todo:add your control notification handler code here
int a = 0;
int b = 6/a;
char* pbuffer = (char*) (int) (rand ());
Char szbuff[10];
StrCpy (pbuffer, "Hello, crash!");
MessageBox (pbuffer);
strcpy (pbuffer, Szbuff);
CloseHandle ((HANDLE) HANDLE);
Abort ();
Throw Bad_alloc ("aaaaa");
Terminate ();
RaiseException (0, 0, 0, NULL);
AfxMessageBox ("good");
return 0;
}
Char PPP;
static char pppp;
const char P5 = ' a ';
const static Char P6 = ' B ';
void Ccrashtestdlg::onbnclickedbutton1 ()
{
_set_abort_behavior (0, _write_abort_msg);
_set_abort_behavior (0, _call_reportfault);
SetUnhandledExceptionFilter (Myunhandledexceptionfilter);
typedef void (*signalhandlerpointer) (int);
Signalhandlerpointer Previoushandler;
Previoushandler = Signal (SIGABRT, Signalhandler);
MessageBox ("ddd", NULL);
Abort ();
DWORD dwid = 0;
Handle = CreateThread (NULL, 0, ThreadProc, handle, 0, &dwid);
CloseHandle (handle);
WaitForSingleObject (handle, INFINITE);

}