作為Windows程序員，平時(shí)最擔(dān)心見(jiàn)到的事情可能就是程序發(fā)生了崩潰（異常），這時(shí)Windows會(huì)提示該程序執(zhí)行了非法操作，即將關(guān)閉。請(qǐng)與您的供應(yīng)商聯(lián)系。呵呵，這句微軟的“名言”，恐怕是程序員最怕見(jiàn)也最常見(jiàn)的東西了。

在一個(gè)大型軟件的測(cè)試過(guò)程中，初期出現(xiàn)程序崩潰似乎成了不可避免的事。其實(shí)測(cè)試中出現(xiàn)程序崩潰并不可怕，反而是測(cè)試的成功。作為開(kāi)發(fā)的我們更需要關(guān)心的是程序中的哪個(gè)函數(shù)或哪一行導(dǎo)致了系統(tǒng)崩潰，這樣才能有針對(duì)性的進(jìn)行改正。

本文描述了自己總結(jié)的幾種定位崩潰的辦法。

? ?以下是幾種常見(jiàn)的崩潰現(xiàn)象及對(duì)應(yīng)的處理辦法：

1．??????? 對(duì)于Release版本必現(xiàn)的崩潰且在Debug版本上也崩潰的程序。

解決思路：去掉所有斷點(diǎn)，直接在Debug版本上運(yùn)行程序，在程序崩潰時(shí)，VC會(huì)自動(dòng)跳轉(zhuǎn)定位到崩潰代碼行， 這種方法最簡(jiǎn)單也最常用。

2．??????? 對(duì)于在Debug版本上不崩潰但Release版本崩潰的程序，很有可能是Debug和Release版本的差異。例如Debug版本所有成員在構(gòu)造時(shí)會(huì)被清0，而Release版本所有成員在構(gòu)造時(shí)是內(nèi)存里面的原始值，而且Debug有運(yùn)行時(shí)庫(kù)做保護(hù)，這些都會(huì)導(dǎo)致某些程序在Debug正常而Release崩潰。

解決思路：1）在程序中加打印，通過(guò)程序崩潰之前的打印定位出錯(cuò)位置； 2）逐段注釋代碼，直到程序不崩潰為止。這種方法耗時(shí)較長(zhǎng)，對(duì)程序員要求較高，而且對(duì)于那種不是必現(xiàn)的bug或者很難搭建執(zhí)行環(huán)境的情況就較難處理了。

3．??????? 對(duì)于在客戶現(xiàn)場(chǎng)崩潰的情況，顯然不適合直接帶一臺(tái)電腦去調(diào)試。

解決思路：應(yīng)該有文件記錄下崩潰信息，客服人員可以將崩潰信息文件發(fā)送給程序員，以便程序員查詢崩潰原因，然后利用編譯時(shí)生成MAP文件（工程信息文件，存放在版本編譯機(jī)中）的信息來(lái)定位問(wèn)題函數(shù)或問(wèn)題代碼行。下面就這種方法展開(kāi)討論一下：

對(duì)于上節(jié)第三種情況，也是最難解決的情況，解決過(guò)程如下：

1.????? 崩潰回調(diào)注冊(cè)，攔截Windows程序崩潰；

2.????? 在回調(diào)處理中，輸出崩潰原因，崩潰內(nèi)存地址，崩潰堆棧；

3.????? 工程輸出map文件；

4.????? 通過(guò)崩潰內(nèi)存地址以及map文件找出崩潰的函數(shù)。

5.????? 使用COD文件精確定位崩潰行

?

實(shí)際上，只靠Windows的錯(cuò)誤消息對(duì)話框提供的信息量是很有限的。用SetUnhandledExceptionFilter注冊(cè)自定義錯(cuò)誤處理回調(diào)函數(shù)，可以替換Win32默認(rèn)的異常處理過(guò)濾器(top-level exception filter)，而且能打印出崩潰堆棧，這對(duì)定位崩潰原因非常有用。

SetUnhandledExceptionFilter的函數(shù)原型：

LPTOP_LEVEL_EXCEPTION_FILTER SetUnhandledExceptionFilter(

LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter );?

功? 能：注冊(cè)和注銷(xiāo)異常處理回調(diào)；

用? 法：第一次調(diào)用注冊(cè)異常處理回調(diào)，第二次調(diào)用注銷(xiāo)；

返回值：返回當(dāng)前的exception filter。需要保存這個(gè)函數(shù)指針，在注銷(xiāo)異常處理回調(diào)的時(shí)候，以此為參數(shù)再次調(diào)用SetUnhandledExceptionFilter。打印異常處理也需要此值。

參數(shù)： 異常處理的回調(diào)函數(shù)；?

崩潰信息在異常回調(diào)函數(shù)中打印，輸出到程序執(zhí)行目錄下的文件：

異常處理回調(diào)的函數(shù)原形：

LONG WINAPI CallBackDebugInfo ( EXCEPTION_POINTERS *pException);?

功? 能：異常處理回調(diào)處理，打印崩潰信息；

用? 法：注冊(cè)自定義錯(cuò)誤處理回調(diào)：SetUnhandledExceptionFilter (CallBackDebugInfo)；

返回值：EXCEPTION_CONTINUE_EXECUTION – ?錯(cuò)誤已經(jīng)被修復(fù),從異常發(fā)生處繼續(xù)執(zhí)行

EXCEPTION_CONTINUE_SEARCH ???– ?繼續(xù)查找異常過(guò)濾器

EXCEPTION_EXECUTE_HANDLER?? – ?正常返回

參數(shù)： 崩潰信息結(jié)構(gòu)，包含崩潰原因、崩潰模塊、崩潰地址、崩潰堆棧等；

常見(jiàn)崩潰原因有：

EXCEPTION_ACCESS_VIOLATION = C0000005h?? 讀寫(xiě)內(nèi)存錯(cuò)誤

EXCEPTION_INT_DIVIDE_BY_ZERO = C0000094h ?除0錯(cuò)誤

EXCEPTION_STACK_OVERFLOW = C00000FDh? 堆棧溢出或者越界

EXCEPTION_GUARD_PAGE = 80000001h 由Virtual Alloc建立起來(lái)的屬性頁(yè)沖突

EXCEPTION_NONCONTINUABLE_EXCEPTION = C0000025h不可持續(xù)異常,程序無(wú)法恢復(fù)執(zhí)行,異常處理例程不應(yīng)處理這個(gè)異常

EXCEPTION_INVALID_DISPOSITION = C0000026h在異常處理過(guò)程中系統(tǒng)使用的代碼

EXCEPTION_BREAKPOINT = 80000003h? 調(diào)試時(shí)中斷（INT 3）

EXCEPTION_SINGLE_STEP = 80000004h? 單步調(diào)試狀態(tài)(INT 1)

?

3.3???? 輸出map文件

map文件記錄程序的全局符號(hào)、源文件和代碼行號(hào)信息，是整個(gè)程序工程信息的靜態(tài)文本。通過(guò)文本閱讀工具如Ultra Edit或記事本就可以打開(kāi)Map文件。

在 VC 中，打開(kāi)“Project Settings”選項(xiàng)頁(yè)，選擇 C/C++ 選項(xiàng)卡，并在最下面的 Project Options 里面輸入：/Zd ，然后選擇 Link 選項(xiàng)卡，選中“Generate mapfile”復(fù)選框。并在最下面的 Project Options 里面輸入：/mapinfo:lines，表示生成 map 文件時(shí)，加入行信息。

?

最后編譯就可以生成 MAP 文件，可以在工程的Debug或Release目錄下找到剛剛生成的MAP文件，文件名為“工程名.map”。

?

3.4???? 使用map文件找出崩潰函數(shù)

　　?? 　通過(guò)上面的步驟，已經(jīng)得到了 MAP 文件，那么我們?cè)撊绾卫盟?？下面一步步演示使用MAP文件定位程序崩潰行的過(guò)程。

????? 1.我們先在代碼中加入非法內(nèi)存操作（最常見(jiàn)的異常）的代碼：

BOOL CMainFrameDlg::OnInitDialog()

{

???????? ::SetProp(m_hWnd,AfxGetApp()->m_pszExeName, (HANDLE)1);

???????? s32 *p=NULL;

???????? *p= 123;

?

2.執(zhí)行程序，程序在開(kāi)始就異常，在異常打印文件中打印了如下信息：

======================== 崩潰信息 ==========================

崩潰時(shí)間： 2009/06/02 16:58:22

崩潰原因：非法內(nèi)存操作

異常代碼 = c0000005

異常地址 = 0x0045a76f

異常模塊: E:ccrootliuxiaojing_EnterpriseEnterprise_VOB70-nms1pcmt2prj_win32Releasepcmt2.exe

Section name: .text - offset(rva) : 0x0005976f

---------------------- Trips of Stack ----------------------

E:ccrootliuxiaojing_EnterpriseEnterprise_VOB70-nms1pcmt2prj_win32Releasepcmt2.exe

name : pcmtver - location: 2bef

3.確定崩潰地址是：0x0005976f，在Map文件中定位函數(shù)：

0001:00059420 ?OnCreate@CMainFrameDlg@@IAEHPAUtagCREATESTRUCTA@@@Z 0045a420 f?? MainFrameDlg.obj

?0001:00059460?????? ?SetTooltips@CMainFrameDlg@@AAEXXZ 0045a460 f?? MainFrameDlg.obj

?0001:00059700?????? ?OnTranslate@CMainFrameDlg@@IAEJIJ@Z 0045a700 f?? MainFrameDlg.obj

?0001:00059730?????? ?OnInitDialog@CMainFrameDlg@@MAEHXZ 0045a730 f?? MainFrameDlg.obj

?0001:00059a10? ?OnSysCommand@CMainFrameDlg@@IAEXIJ@Z 0045aa10 f?? MainFrameDlg.obj

?0001:00059c20?????? ?OnPaint@CMainFrameDlg@@IAEXXZ 0045ac20 f?? MainFrameDlg.obj

根據(jù)00059730< 0005976f < 00059a10 ，確定是在CMainFrameDlg 的OnInitDialog函數(shù)中的某一行產(chǎn)生了異常。

3.5???? 使用map代碼行定位崩潰行區(qū)間

?

Line numbers for .ReleaseMainFrameDlg.obj(E:ccrootliuxiaojing_EnterpriseEnterprise_VOB70-nms1pcmt2sourceMainFrameDlg.cpp) segment .text

?? 498 0001:00059647?? 499 0001:00059667?? 501 0001:0005966e?? 502 0001:000596af

?? 503 0001:000596ed?? 506 0001:00059700?? 507 0001:00059703?? 508 0001:00059708

?? 510 0001:0005970f?? 511 0001:00059720?? 512 0001:00059723?? 515 0001:00059730

?? 516 0001:0005974e?? 521 0001:0005976d?? 524 0001:0005977e?? 526 0001:0005978b

我們?cè)趍ap文件的代碼行信息里查找不超過(guò)計(jì)算結(jié)果0x0005976f，但可以找最接近的數(shù)。發(fā)現(xiàn)是 MainFrameDlg.cpp 文件中的：521 0001:0005976d，而程序?qū)嶋H崩潰行在519（注釋行和空行也要計(jì)算在內(nèi)），非常接近實(shí)際崩潰行了，考慮到程序?qū)嶋H執(zhí)行的是匯編指令，我們可以在(516 ~524)行區(qū)間內(nèi)尋找到實(shí)際崩潰行。

但是這種輸出文件的方法也不能定位所有崩潰問(wèn)題，俗話說(shuō)得好：沒(méi)有萬(wàn)能的救世主。

例如我們有時(shí)會(huì)碰到下層編解碼器崩潰，崩潰打印如下表：

======================== 崩潰信息 ==========================

崩潰時(shí)間： 2009/05/07 09:48:17

崩潰原因：非法內(nèi)存操作

異常代碼 = c0000005

異常地址 = 0x02163b32

異常模塊: C:WINDOWSsystem32kdg7221.acm

Section name: .text - offset(rva) : 0x00002b32

---------------------- Trips of Stack ----------------------

C:WINDOWSsystem32kdg7221.acm

?? 這時(shí)可以看出是我們的音頻解碼器kdg7221.acm崩潰了，此時(shí)就要考慮我們的音頻編解碼參數(shù)是否設(shè)置錯(cuò)了，如果沒(méi)有設(shè)錯(cuò)，bug可以轉(zhuǎn)到媒體處理層或者軟件一部處理。