（1）       調用abort函數，并且設置了_CALL_REPORTFAULT選項（這個選項在Release版本是默認設置的）。

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

（3）       遇到_invalid_parameter錯誤，而應用程序又沒有主動調用

_set_invalid_parameter_handler設置錯誤捕獲函數。

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

解決方法

       之所以應用程序捕獲不到那些異常，原因是因為新版本的CRT實現在異常處理中強制刪除所有應用程序先前設置的捕獲函數，如下所示：

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

 SetUnhandledExceptionFilter(NULL);

 UnhandledExceptionFilter(&ExceptionPointers);

解決方法是攔截CRT調用SetUnhandledExceptionFilter函數，使之無效。在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);

       }

}

在設置自己的異常處理函數后，調用DisableSetUnhandledExceptionFilter禁止CRT設置即可。

其它討論

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

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


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

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

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

      函數名: abort

　　功 能: 異常終止一個進程

　　用 法: 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窗口的多線程應用程序,  調用了abort就會彈出對話框, 在release版本中, 就是一個確認對話框, 點擊后程序就提示出錯并退出.

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

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

    SEH異常和C++異常有本質的區別, SEH是操作系統提供的異常處理技術, 在任何支持該操作系統的編程語言中, 都可以使用, 而C++異常處理只能在編寫C++代碼時使用。然而, 應當知道WINDOWS的VC++編譯器是使用操作系統結構化異常來實現C++異常的.  也就是說, C++的try塊在VC++下編譯時, 會變成__try塊,  C++的catch塊會變成SEH的 __except塊: catch測試則變成SEH異常過濾器, catch中的代碼則變為__except中的代碼. 事實上, C++的throw塊, 在編譯的時候也會變成SEH的RaiseException函數調用, 由c++異常變為SEH異常.

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

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

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

打開VC，附加對應的進程，在線程選項卡里查找類似MessageBox的字樣，找到的那個就是彈出對話框的線程，右鍵，轉到線程，查看調用堆棧，一般就能找到問題了

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

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

測試例子：

//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);
  
}