多軟件通過設置自己的異常捕獲函數，捕獲未處理的異常，生成報告或者日志（例如生成mini-dump文件），達到Release版本下追蹤Bug的目的。但是，到了VS2005（即VC8），Microsoft對CRT（C運行時庫）的一些與安全相關的代碼做了些改動，典型的，例如增加了對緩沖溢出的檢查。新CRT版本在出現錯誤時強制把異常拋給默認的調試器（如果沒有配置的話，默認是Dr.Watson），而不再通知應用程序設置的異常捕獲函數，這種行為主要在以下三種情況出現。
（1）調用abort函數，并且設置了_CALL_REPORTFAULT選項（這個選項在Release版本是默認設置的）。
（2）啟用了運行時安全檢查選項，并且在軟件運行時檢查出安全性錯誤，例如出現緩存溢出。（安全檢查選項/GS 默認也是打開的）
（3）遇到_invalid_parameter錯誤，而應用程序又沒有主動調用_set_invalid_parameter_handler設置錯誤捕獲函數。
所以結論是，使用VS2005（VC8）編譯的程序，許多錯誤都不能在SetUnhandledExceptionFilter捕獲到。這是CRT相對于前面版本的一個比較大的改變，但是很遺憾，Microsoft卻沒有在相應的文檔明確指出。
下面列出三種解決方法。
方法一：windows進程崩潰時禁止彈出錯誤對話框
在程序初始化的時候加入以下代碼。如果程序中通過SetUnhandledExceptionFilter捕獲異常，需要在SetUnhandledExceptionFilter后面增加以下代碼。
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
_set_abort_behavior(0,_WRITE_ABORT_MSG | _CALL_REPORTFAULT);
或者
// 關閉微軟堆轉儲的噪音
_CrtSetReportMode(_CRT_WARN, _CRTDBG_MODE_FILE);
_CrtSetReportFile(_CRT_WARN, CreateFileA("NUL", GENERIC_WRITE, 0, nullptr, OPEN_EXISTING, 0, 0));
SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
//在abort上禁用令人困惑的“helpful”文本消息
_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT);_CrtSetReportMode：設置開發編譯環境報告類型為警告，報告的輸出方式為文件輸出。
_CrtSetReportFile：創建一個空的文件，把警告消息輸出到這個文件中。即關閉警告消息。
_set_abort_behavior：處理在VS環境下的只會強制把異常拋給默認的調試器的問題，用該函數把異常拋給異常捕獲函數。SetErrorMode：控制指定類型的嚴重錯誤是由windows處理還是由應用程序處理。
方法二：攔截CRT調用SetUnhandledExceptionFilter函數，使之無效。
之所以應用程序捕獲不到那些異常，原因是因為新版本的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);
}
}
WIN8.1上VirtualProtect報錯C0000005，解決方法如下：
bool AdjustPrivileges()
{
HANDLE hToken;
TOKEN_PRIVILEGES tp;
TOKEN_PRIVILEGES oldtp;
DWORD dwSize=sizeof(TOKEN_PRIVILEGES);
LUID luid;
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken))
{
if (GetLastError()==ERROR_CALL_NOT_IMPLEMENTED) return true;
else return false;
}
if (!LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &luid))
{
CloseHandle(hToken);
return false;
}
ZeroMemory(&tp, sizeof(tp));
tp.PrivilegeCount=1;
tp.Privileges[0].Luid=luid;
tp.Privileges[0].Attributes=SE_PRIVILEGE_ENABLED;
/* Adjust Token Privileges */
if (!AdjustTokenPrivileges(hToken, FALSE, &tp, sizeof(TOKEN_PRIVILEGES), &oldtp, &dwSize))
{
CloseHandle(hToken);
return false;
}
// close handles
CloseHandle(hToken);
return true;
}
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;
//提升debug權限
VirtualProtect(addr, size, PAGE_EXECUTE_READWRITE, &dwOldFlag);
WriteProcessMemory(GetCurrentProcess(), addr, code, size, NULL);
VirtualProtect(addr, size, dwOldFlag, &dwTempFlag);
}
}在設置自己的異常處理函數后，調用DisableSetUnhandledExceptionFilter禁止CRT設置即可。雖然也可以通過_set_abort_behavior(0, _WRITE_ABORT_MSG | _CALL_REPORTFAULT), signal(SIGABRT, ...), 和_set_invalid_parameter_handler(...) 解決（1）（3），但是對于（2），設置api hook是唯一的方式。
方法三：禁止彈出“停止工作”對話框
在Win7及以后的系統中，如果一個程序發生了奔潰，系統會彈出一個“XX已停止工作”的對話框，如果不去這個窗口上點擊“關閉程序”，那么這個窗口會一直存在，最為關鍵的是，奔潰的進程并沒有真正結束，還一直掛起在那里。這在自動化無人值守程序開發中是不允許的，有時候有的程序只能運行一個實例，如果奔潰的這個進程一直沒有真正結束，新進程就無法啟動。根據網上資料，在Windows服務管理器中關閉這個錯誤報告服務，仍然會彈出停止運行的對話框。最后在MSDN上找到了Windows的錯誤報告服務配置說明：https://msdn.microsoft.com/en-us/library/windows/desktop/bb513638(v=vs.85).aspx
那如何禁止 werfault 窗口的彈出呢？
在 stackoverflow 上找到一個方法，可以通過修改注冊表，抑制這個錯誤窗口的彈出。
具體方法如下所示：
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Windows Error Reporting]
"Disabled"=dword:00000001
"DontShowUI"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting]
"Disabled"=dword:00000001
"DontShowUI"=dword:00000001修改注冊表后應該就可以了。
如果還有問題， 可能需要重新加載注冊表
1.進程中關閉 explorer.exe
2.運行 explorer.exe
我們知道，編譯時可以有不同的編譯選項及組合。在編譯器中，有兩種編譯選項組合，分別是release與debug，編譯時，選擇release或者debug，編譯出來的程序分別稱為release版或者debug版，前者優化較多，文件較小，后者因為調試的需要，文件較大。當然，不管是releas選項，還是debug選項，其中的一些編譯選項可以在工程設置中做修改，從而得到優化過的調試版本或是帶跟蹤語句的發布版本。
Debug 版本： /MDd /MLd 或 /MTd 使用 Debug runtime library(調試版本的運行時刻函數庫) /Od 關閉優化開關 /D "_DEBUG" 相當于 #define _DEBUG,打開編譯調試代碼開關(主要針對 assert函數) /ZI 創建 Edit and continue(編輯繼續)數據庫，這樣在調試過 程中如果修改了源代碼不需重新編譯 /GZ 可以幫助捕獲內存錯誤 /Gm 打開最小化重鏈接開關，減少鏈接時間
Release 版本： /MD /ML 或 /MT 使用發布版本的運行時刻函數庫 /O1 或 /O2 優化開關，使程序最小或最快 /D "NDEBUG" 關閉條件編譯調試代碼開關(即不編譯assert函數) /GF 合并重復的字符串，并將字符串常量放到只讀內存，防止被修改。
Debug版本包括調試信息，所以要比Release版本大很多（可能大數百K至數M）。至于是否需要DLL支持，主要看你采用的編譯選項。如果是基于ATL的，則Debug和Release版本對DLL的要求差不多。如果采用的編譯選項為使用MFC動態庫，則需要MFC42D.DLL等庫支持，而Release版本需要MFC42.DLL支持。
Release Build不對源代碼進行調試，不考慮MFC的診斷宏，使用的是MFC Release庫，編譯時對應用程序的速度進行優化，而Debug Build則正好相反，它允許對源代碼進行調試，可以定義和使用MFC的診斷宏，采用MFC Debug庫，對速度沒有優化。
Debug版與Release版的的編譯選項組合及一些編譯選項的具體差異和細節：
鏈接哪一種運行時刻函數庫通常只對程序的性能產生影響。調試版本的 Runtime Library 包含了調試信息，并采用了一些保護機制以幫助發現錯誤，因此性能不如發布版本。編譯器提供的 Runtime Library 通常很穩定，不會造成 Release 版錯誤；倒是由于 Debug 的 Runtime Library 加強了對錯誤的檢測，如堆內存分配，有時會出現 Debug 有錯但 Release 正常的現象。應當指出的是，如果 Debug 有錯，即使 Release 正常，程序肯定是有 Bug 的，只不過可能是 Release 版的某次運行沒有表現出來而已。
這是造成錯誤的主要原因，因為關閉優化時源程序基本上是直接翻譯的，而打開優化后編譯器會作出一系列假設。這類錯誤主要有以下幾種：
2.1 幀指針(Frame Pointer)省略（簡稱 FPO ）：在函數調用過程中，所有調用信息（返回地址、參數）以及自動變量都是放在棧中的。若函數的聲明與實現不同（參數、返回值、調用方式），就會產生錯誤。但 Debug 方式下，棧的訪問通過 EBP 寄存器保存的地址實現，如果沒有發生數組越界之類的錯誤（或是越界“不多”），函數通常能正常執行；Release 方式下，優化會省略 EBP 棧基址指針，這樣通過一個全局指針訪問棧就會造成返回地址錯誤使程序崩潰。C++ 的強類型特性能檢查出大多數這樣的錯誤，但如果用了強制類型轉換，就不行了。你可以在 Release 版本中強制加入 /Oy- 編譯選項來關掉幀指針省略，以確定是否此類錯誤。
char* pjPath()
{
char * path=new char[66];
::GetCurrentDirectory(66,path);
CString cpath=path;
cpath +="test.txt";
return cpath.GetBuffer(0);// release版OK，debug版是隨機值
}2.2 volatile 型變量：volatile 告訴編譯器該變量可能被程序之外的未知方式修改（如系統、其他進程和線程）。優化程序為了使程序性能提高，常把一些變量放在寄存器中（類似于 register 關鍵字），而其他進程只能對該變量所在的內存進行修改，而寄存器中的值沒變。如果你的程序是多線程的，或者你發現某個變量的值與預期的不符而你確信已正確的設置了，則很可能遇到這樣的問題。這種錯誤有時會表現為程序在最快優化出錯而最小優化正常。把你認為可疑的變量加上 volatile 試試。
2.3 變量優化：優化程序會根據變量的使用情況優化變量。例如，函數中有一個未被使用的變量，在 Debug 版中它有可能掩蓋一個數組越界，而在 Release 版中，這個變量很可能被優化掉，此時數組越界會破壞棧中有用的數據。當然，實際的情況會比這復雜得多。與此有關的錯誤有：
非法訪問，包括數組越界、指針錯誤等。例如：
void fn(void)
{
int i;
i=1;
int a[4];
{
int j;
j=1;
}
a[-1]=1;//當然錯誤不會這么明顯，例如下標是變量 a[4]=1;
} j 雖然在數組越界時已出了作用域，但其空間并未收回，因而 i 和 j 就會掩蓋越界。而 Release 版由于 i、j 并未使用可能會被優化掉，從而使棧被破壞。
如：
char buffer[10];
int counter;
lstrcpy(buffer, "abcdefghik"); 在debug版中buffer的NULL覆蓋了counter的高位，但是除非counter>16M，什么問題也沒有。但是在release版中，counter可能被放在寄存器中，這樣NULL就覆蓋了buffer下面的空間，可能就是函數的返回地址，這將導致ACCESS ERROR。
當定義了 _DEBUG 時，assert() 函數會被編譯，而 NDEBUG 時不被編譯。除此之外，VC++中還有一系列斷言宏。這包括：
ANSI C 斷言：void assert(int expression );
C Runtime Lib 斷言：_ASSERT( booleanExpression ); _ASSERTE( booleanExpression );
MFC 斷言：ASSERT( booleanExpression ); VERIFY( booleanExpression ); ASSERT_VALID( pObject ); ASSERT_KINDOF( classname, pobject );
ATL 斷言：ATLASSERT( booleanExpression );
此外，TRACE() 宏的編譯也受 _DEBUG 控制。所有這些斷言都只在 Debug版中才被編譯，而在 Release 版中被忽略。唯一的例外是 VERIFY() 。事實上，這些宏都是調用了 assert() 函數，只不過附加了一些與庫有關的調試代碼。如果你在這些宏中加入了任何程序代碼，而不只是布爾表達式（例如賦值、能改變變量值的函數調用 等），那么 Release 版都不會執行這些操作，從而造成錯誤。初學者很容易犯這類錯誤，查找的方法也很簡單，因為這些宏都已在上面列出，只要利用 VC++ 的 Find in Files 功能在工程所有文件中找到用這些宏的地方再一一檢查即可。另外，有些程序員可能還會加入 #ifdef _DEBUG 之類的條件編譯，也要注意一下。
ASSERT宏是這樣定義的：
#ifdef _DEBUG
#define ASSERT(x) if( (x)==0) report_assert_failure()
#else #define ASSERT(x)
#endif 實際上復雜一些，但無關緊要。假如你在這些語句中加了程序中必須要有的代碼 比如
ASSERT(pNewObj=new CMyClass);
pNewObj->MyFunction(); 這種時候Release版本中的pNewObj不會分配到空間 所以執行到下一個語句的時候程序會報該程序執行了非法操作的錯誤。這時可以用VERIFY ：
#ifdef _DEBUG
#define VERIFY(x) if( (x)==0) report_assert_failure()
#else
#define VERIFY(x) (x)
#endif 這樣的話，代碼在release版中就可以執行了。
需要注意的是 VERIFY()這個宏允許你將程序代碼放在布爾表達式里，這個宏通常是用來檢查 Windows API 的返回值。有些人可能為這個原因而濫用 VERIFY() ，事實上這是危險的，因為 VERIFY() 違反了斷言的思想，不能使程序代碼和調試代碼完全分離，最終可能會帶來很多麻煩。因此，專家們建議盡量少用這個宏。
GZ 選項主要包括：
4.1 初始化內存和變量。包括用 0xCC 初始化所有自動變量，0xCD ( Cleared Data ) 初始化堆中分配的內存（即動態分配的內存，例如 new ），0xDD ( Dead Data ) 填充已被釋放的堆內存（例如 delete ），0xFD( deFencde Data ) 初始化受保護的內存（debug 版在動態分配內存的前后加入保護內存以防止越界訪問）。這樣做的好處是這些值都很大，作為指針是不可能的（而且 32 位系統中指針很少是奇數值，在有些系統中奇數的指針會產生運行時錯誤），作為數值也很少遇到，而且這些值也很容易辨認，因此這很有利于在 Debug 版中發現 Release 版才會遇到的錯誤。要特別注意的是，很多人認為編譯器會用 0 來初始化變量，這是錯誤的（而且這樣很不利于查找錯誤）。
下面的一段代碼在debug中運行的很好，而在release中卻不行，因為debug中會自動給變量初始化found=FALSE，而在release版中則不會：
thing * search(thing * something);
BOOL found;
for(int i=0; i < whatever.GetSize(); i++)
{
if(whatever[i]->field==something->field)
{ /* found it */
found=TRUE;
break;
} /* found it */
}
if(found)
return whatever[i];
else return NULL;
所以盡可能的給變量、類或結構初始化。
4.2 通過函數指針調用函數時，會通過檢查棧指針驗證函數調用的匹配性（防止原形不匹配）。
4.3 函數返回前檢查棧指針，確認未被修改（防止越界訪問和原形不匹配，與第二項合在一起可大致模擬幀指針省略 FPO ）。
通常 /GZ 選項會造成 Debug 版出錯而 Release 版正常的現象，因為 Release 版中未初始化的變量是隨機的，這有可能使指針指向一個有效地址而掩蓋了非法訪問。 除此之外，/Gm /GF 等選項造成錯誤的情況比較少，而且他們的效果顯而易見，比較容易發現。
5.1 數組越界
CTime m_day=CTime::GetCurrentTime();
CString week=m_day.Format("%w");
int i=atoi(week.GetBuffer(0)); // 當星期天時i=0
//CString weeks=_T("一二三四五六七");
//weeks=weeks.Mid(i*2-2,2);
CString weeks[]={"Sun.","Mon.", "Tue.", "Wed.", "Thu.", "Fri.", "Sat."};
CString str="hi,\r";
str +="" + m_day.Format("%Y-%m-%d " + weeks[i-1]);//當星期天時i=0，改為weeks[i-1]另外需要注意的是，規模大一點的程序與玩具程序的錯誤是有所區別的，原因在于棧上數據的覆蓋，及內存地址篡改的概率不一致。
5.2 自定義消息的參數
MFC為我們提供了很好的消息機制，更增加了自定義消息，好處我就不用多說了。這也存在debug跟release的問題嗎？答案是肯定的。在自定義消息的函數體聲明時，時常會看到這樣的寫法：afx_msg LRESULT OnMessageOwn(); 當你在多線程或進程間使用了消息傳遞時就會導致無效句柄之類的錯誤。這個原因就是消息體的參數沒有添加，即應該寫成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); 否則Debug會過，而Release出錯。
6.1 內存泄漏
pDC=GetDC();
.......
ReleaseDC(pDC); //正確！不能忘記，不能是pDC->DeleateDC(); 要養成結對編程的習慣。
6.2 指針的初始化
//CTime m_tQueryTime;
SYSTEMTIME* m_tQueryTime; // 未初始化
m_dayCtrl.GetCurSel(m_tQueryTime); // m_dayCtrl是日歷控件的control變量
// 更改為以下即可：
SYSTEMTIME m_tQueryTime;
m_dayCtrl.GetCurSel(&m_tQueryTime);6.3 申請動態內存與實際需要內存的不一致
// 寫入UTF-8的BOM文件頭
char header[3]={(char)0xEF, (char)0xBB, (char)0xBF};
fwrite(header, sizeof(char), 3, fp);
char *chs=(char *)m_textblock.GetBuffer(0);
int k=m_textblock.GetLength();
wchar_t *wc=(wchar_t *)malloc(sizeof(wchar_t)*k+2); // 此處要+2
// 將ANSI編碼的多字節字符串轉換成寬字符字符串
int n=MultiByteToWideChar(CP_ACP, 0, chs, strlen(chs), wc, k);
if ( n > 0 )
{
wc[n]=0;
char *mb=(char *)malloc(sizeof(char)*k*4);
// 將寬字符字符串轉換成UTF-8編碼的多字節字符串
n=WideCharToMultiByte(CP_UTF8, 0, wc, wcslen(wc), mb, k*4, NULL, NULL);
if ( n > 0 )
{
mb[n]=0;
fwrite(mb, sizeof(char), strlen(mb), fp);
}
free(mb);
}
free(wc); // 如果上面動態內存字節數未+2，
//會出現DAMAGE: after Normal block(#4213) at 0x的錯誤綜上，release版和debug版的本質差異在于編譯選項的組合不一致，需要在release版和debug版之間交替編譯，以及早發現潛在的錯誤。
-End-