（1）       調(diào)用abort函數(shù)，并且設(shè)置了_CALL_REPORTFAULT選項（這個選項在Release版本是默認(rèn)設(shè)置的）。

（2）       啟用了運(yùn)行時安全檢查選項，并且在軟件運(yùn)行時檢查出安全性錯誤，例如出現(xiàn)緩存溢出。（安全檢查選項 /GS 默認(rèn)也是打開的）

（3）       遇到_invalid_parameter錯誤，而應(yīng)用程序又沒有主動調(diào)用

_set_invalid_parameter_handler設(shè)置錯誤捕獲函數(shù)。

所以結(jié)論是，使用VS2005（VC8）編譯的程序，許多錯誤都不能在SetUnhandledExceptionFilter捕獲到。這是CRT相對于前面版本的一個比較大的改變，但是很遺憾，Microsoft卻沒有在相應(yīng)的文檔明確指出。

解決方法

       之所以應(yīng)用程序捕獲不到那些異常，原因是因為新版本的CRT實現(xiàn)在異常處理中強(qiáng)制刪除所有應(yīng)用程序先前設(shè)置的捕獲函數(shù)，如下所示：

 /* Make sure any filter already in place is deleted. */

 SetUnhandledExceptionFilter(NULL);

 UnhandledExceptionFilter(&ExceptionPointers);

解決方法是攔截CRT調(diào)用SetUnhandledExceptionFilter函數(shù)，使之無效。在X86平臺下，可以使用以下代碼。

#ifndef _M_IX86

       #error "The following code only works for x86!"

#endif

void DisableSetUnhandledExceptionFilter()

{

    void *addr = (void*)GetProcAddress(LoadLibrary(_T("kernel32.dll")),

                                                         "SetUnhandledExceptionFilter");

    if (addr)

    {

              unsigned char code[16];

              int size = 0;

              code[size++] = 0x33;

              code[size++] = 0xC0;

              code[size++] = 0xC2;

              code[size++] = 0x04;

              code[size++] = 0x00;

               DWORD dwOldFlag, dwTempFlag;

              VirtualProtect(addr, size, PAGE_READWRITE, &dwOldFlag);

              WriteProcessMemory(GetCurrentProcess(), addr, code, size, NULL);

              VirtualProtect(addr, size, dwOldFlag, &dwTempFlag);

       }

}

在設(shè)置自己的異常處理函數(shù)后，調(diào)用DisableSetUnhandledExceptionFilter禁止CRT設(shè)置即可。

其它討論

       上面通過設(shè)置api hook，解決了在VS2005上的異常捕獲問題，這種雖然不是那么“干凈”的解決方案，確是目前唯一簡單有效的方式。

       雖然也可以通過_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT), signal(SIGABRT, ...), 和_set_invalid_parameter_handler(...) 解決（1）（3），但是對于（2），設(shè)置api hook是唯一的方式。


http://blog.csdn.net/WinGeek/article/details/3942995
[Windows編程] 如何捕捉程序異常/crash 并生成 dump 文件

  VC++ Runtime Error,  對不少朋友來說, 這是一個十分討厭的錯誤提示,  您可能不知道如何著手調(diào)試: 產(chǎn)生這個錯誤的原因是什么? 確實只有知道了產(chǎn)生這個錯誤的直接原因, 才能去調(diào)試這個錯誤.

     剛碰到這個錯誤的時候, 是發(fā)生在視頻解碼的時候,  由于解碼一直在工作狀態(tài),  所以我也不知道如何去調(diào)試, 當(dāng)出現(xiàn)這個錯誤之后, 我們大多數(shù)時候就忽略了, 想從其他地方解決, 提高穩(wěn)定性, 甚至懷疑解碼器的穩(wěn)定性;  后來, 我接觸解碼庫之后,  開始調(diào)試這樣的錯誤, 剛開始這樣的錯誤并不容易重現(xiàn), 往往要幾個小時,  當(dāng)這個錯誤重現(xiàn)之后,  程序還是在運(yùn)行的, 只是其中的某一個線程中斷了執(zhí)行,  其中的這個線程彈出了 "VC++ Runtime Error" 這樣的對話框, 如果你點擊它, 則整個應(yīng)用程序會直接退出. 為了調(diào)試, 我就不能點擊這個對話框, 而是使用VC2005附件到進(jìn)程, 然后再直接中斷進(jìn)程, 這個時候, 會有一個線程中斷點就在對話框的消息循環(huán)中, 仔細(xì)查看堆棧, 發(fā)現(xiàn)了一個函數(shù): msvcrt.dll!_abort() ,  到這里是時候查看MSDN了:

      函數(shù)名: abort

　　功 能: 異常終止一個進(jìn)程

　　用 法: void abort(void);

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

    我們的程序就是基于WINDOS窗口的多線程應(yīng)用程序,  調(diào)用了abort就會彈出對話框, 在release版本中, 就是一個確認(rèn)對話框, 點擊后程序就提示出錯并退出.

    在正常的程序里, 我們是不會調(diào)用abort的, 除非是遇到了嚴(yán)重的, 不能恢復(fù)的錯誤.  那么到底這個abort是怎么被調(diào)用的呢, 我們自己寫的代碼顯然是沒有這個函數(shù), 再仔細(xì)查看堆棧,  發(fā)現(xiàn)是在一個C語言版本的開源庫中.  我們的程序是需要7*24小時運(yùn)行的, 出現(xiàn)了解碼異常應(yīng)該要被我們忽略, 而不是應(yīng)用程序崩潰. 開源的跨平臺解碼庫是C語言寫的,  在出現(xiàn)了嚴(yán)重錯誤時, 就直接abort這也是可以理解的, 不過, 這樣的程序在我們的代碼中顯然要避免.  大哥, 現(xiàn)在都是什么年代了, 很多程序都是需要一直跑的, 我只好改的庫的源代碼來重新編譯程序才能解決這個問題了, 該怎么改了, 如果去分析解碼的邏輯, 我們沒有專業(yè)的人才.  我想就干脆從abort函數(shù)這里入手, 直接返回成功值, 但是這樣對解碼邏輯影響更大, 可能導(dǎo)致更大的錯誤,  我想到了操作系統(tǒng)的異常機(jī)制, 由于我們是在WINDOWS平臺上工作, 所以可以利用WINDOWS結(jié)構(gòu)化異常,  我們可取消abort調(diào)用, 在這里我們使用代碼產(chǎn)生一個結(jié)構(gòu)化異常(SEH), 結(jié)構(gòu)化異常分為硬件異常和軟件異常, CPU可以檢查到內(nèi)存非法訪問和除零錯誤等異常, 那么我們就將abort替換成除零語句, 比如 int i = 10/0;

     當(dāng)程序執(zhí)行到這里的時候,  CPU會捕捉這個異常, 并提示用戶, 我們可以在調(diào)用解碼函數(shù)的地方, 增加SEH捕捉代碼, 來捕捉這個錯誤, 那么程序就能忽略這個錯誤并繼續(xù)執(zhí)行了. 后來的事實也證明了這個錯誤的忽略對程序并沒有什么明顯的影響.  怎么寫這個捕捉代碼呢, 操作系統(tǒng)支持的SEH捕捉代碼塊為 __try - __finally 塊和 __try - __except 塊, 而__try - __finnaly塊就可以實現(xiàn)我們的功能.  寫到這里, 可能有朋友要說了, 我們平時見的最多的是try-catch語句,  那么我要解釋一下了, try-catch 是C++異常的處理方式,  而__try-__finnaly是操作系統(tǒng)SEH異常處理方式.  在C++語言的try-catch并不能捕捉操作系統(tǒng)結(jié)構(gòu)化異常(比如CPU異常, 內(nèi)存訪問沖突, 除零錯誤等). C++異常只能捕獲軟件異常, 通常是調(diào)用throw而產(chǎn)生的異常, 比如MFC異常中常見的CException.  

    SEH異常和C++異常有本質(zhì)的區(qū)別, SEH是操作系統(tǒng)提供的異常處理技術(shù), 在任何支持該操作系統(tǒng)的編程語言中, 都可以使用, 而C++異常處理只能在編寫C++代碼時使用。然而, 應(yīng)當(dāng)知道WINDOWS的VC++編譯器是使用操作系統(tǒng)結(jié)構(gòu)化異常來實現(xiàn)C++異常的.  也就是說, C++的try塊在VC++下編譯時, 會變成__try塊,  C++的catch塊會變成SEH的 __except塊: catch測試則變成SEH異常過濾器, catch中的代碼則變?yōu)開_except中的代碼. 事實上, C++的throw塊, 在編譯的時候也會變成SEH的RaiseException函數(shù)調(diào)用, 由c++異常變?yōu)镾EH異常.

    __finnally的好處在于, 有時更詳細(xì)的異常信息對我們沒有更大幫助, 我們只需要捕獲到異常并忽略它。上面提到C++異常在VC++里被轉(zhuǎn)換成SEH異常, 那么在VC下使用try-catch是否能捕獲硬件異常呢? 比如我們常見的 0x0000000C 不可讀或?qū)?  VC++編譯器已經(jīng)提供了支持:

      try {;}  catch(...){;}   這樣的語句就能夠捕獲所有異常:包括CPU異常, 以及C++異常;  不過需要注意的是, 在VC6.0中, 是默認(rèn)支持的. 但是在VC2005中,  是默認(rèn)不捕獲CPU異常的. 區(qū)別在于一個C++編譯選項/Eha , 只有這個選項打開才能用上面的try-catch()捕捉SEH異常.

程序偶爾會出現(xiàn)：
Microsoft Visual C++ Runtime Library Runtime Error! 
Program: [APPPATH] Abnormal program termination
同時帶有紅色叉叉的對話框。

打開VC，附加對應(yīng)的進(jìn)程，在線程選項卡里查找類似MessageBox的字樣，找到的那個就是彈出對話框的線程，右鍵，轉(zhuǎn)到線程，查看調(diào)用堆棧，一般就能找到問題了

根據(jù)剛才的函數(shù)調(diào)用堆棧，可以發(fā)現(xiàn)，這個框框是由abort間接產(chǎn)生的，根據(jù)查看abort的源碼，可以發(fā)現(xiàn)，產(chǎn)生結(jié)果是有選項_WRITE_ABORT_MSG和_CALL_REPORTFAULT這兩個標(biāo)志決定的，這兩個標(biāo)志一個是產(chǎn)生如上所述的對話框，一個是產(chǎn)生那個常見的錯誤報告對話框。在msdn里，和abort相關(guān)的還有個函數(shù)_set_abort_behavior，可通過此函數(shù)，改變abort的行為。

還有個常見的錯誤框與此類似，是pure virtual function 就是純虛函數(shù)的調(diào)用，它的過程與abort相類似。

測試?yán)樱?/span>

//SEH的異常處理過濾器
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);
  
}