作為程序員，我們平時(shí)最擔心見(jiàn)到的事情是什么？是內存泄漏？是界面不好看？……錯啦！我相信我的看法是不會(huì )有人反對的——那就是，程序發(fā)生了崩潰！
“該程序執行了非法操作，即將關(guān)閉。請與你的軟件供應商聯(lián)系。”，呵呵，這句 M$的“名言”，恐怕就是程序員最擔心見(jiàn)到的東西了。有的時(shí)候，自己的程序在自己的機器上運行得好好的，但是到了別人的機器上就崩潰了；有時(shí)自己在編寫(xiě)和測試的過(guò)程中就莫名其妙地遇到了非法操作，但是卻無(wú)法確定到底是源代碼中的哪行引起的……是不是很痛苦呢？不要緊，本文可以幫助你走出這種困境，甚至你從此之后可以自豪地要求用戶(hù)把崩潰地址告訴你，然后你就可以精確地定位到源代碼中出錯的那行了。（很神奇吧？呵呵。）
首先我必須強調的是，本方法可以在目前市面上任意一款編譯器上面使用。但是我只熟悉 M$ 的 VC 和 MASM ，因此后面的部分只介紹如何在這兩個(gè)編譯器中實(shí)現，請讀者自行融會(huì )貫通，掌握在別的編譯器上使用的方法。
Well，廢話(huà)說(shuō)完了，讓我們開(kāi)始！ ：）
首先必須生成程序的 MAP 文件。什么是 MAP 文件？簡(jiǎn)單地講， MAP 文件是程序的全局符號、源文件和代碼行號信息的唯一的文本表示方法，它可以在任何地方、任何時(shí)候使用，不需要有額外的程序進(jìn)行支持。而且，這是唯一能找出程序崩潰的地方的救星。
好吧，既然 MAP 文件如此神奇，那么我們應該如何生成它呢？在 VC 中，我們可以按下 Alt+F7 ，打開(kāi)“ProjectSettings”選項頁(yè)，選擇 C/C++ 選項卡，并在最下面的 Project Options 里面輸入：/Zd ，然后要選擇 Link選項卡，在最下面的 Project Options 里面輸入： /mapinfo:lines 和 /map:PROJECT_NAME.map。最后按下 F7 來(lái)編譯生成 EXE 可執行文件和 MAP 文件。
在 MASM 中，我們要設置編譯和連接參數，我通常是這樣做的：
| rc %1.rc ml /c /coff /Zd %1.asm link /subsystem:windows /mapinfo:exports /mapinfo:lines /map:%1.map %1.obj %1.res |
把它保存成 makem.bat ，就可以在命令行輸入 makem filename 來(lái)編譯生成 EXE 可執行文件和 MAP 文件了。
在此我先解釋一下加入的參數的含義：
| /Zd 表示在編譯的時(shí)候生成行信息 /map[:filename] 表示生成 MAP 文件的路徑和文件名 /mapinfo:lines 表示生成 MAP 文件時(shí)，加入行信息 /mapinfo:exports 表示生成 MAP 文件時(shí)，加入 exported functions （如果生成的是 DLL 文件，這個(gè)選項就要加上） |
OK，通過(guò)上面的步驟，我們已經(jīng)得到了 MAP 文件，那么我們該如何利用它呢？
讓我們從簡(jiǎn)單的實(shí)例入手，請打開(kāi)你的 VC ，新建這樣一個(gè)文件：
| 01 //**************************************************************** 02 //程序名稱(chēng)：演示如何通過(guò)崩潰地址找出源代碼的出錯行 03 //作者：羅聰 04 //日期：2003-2-7 05 //出處：http://www.luocong.com（老羅的繽紛天地） 06 //本程序會(huì )產(chǎn)生“除0錯誤”，以至于會(huì )彈出“非法操作”對話(huà)框。 07 //“除0錯誤”只會(huì )在 Debug 版本下產(chǎn)生，本程序為了演示而盡量簡(jiǎn)化。 08 //注意事項：如欲轉載，請保持本程序的完整，并注明： 09 //轉載自“老羅的繽紛天地”（http://www.luocong.com） 10 //**************************************************************** 11 12 void Crash(void) 13 { 14 int i = 1; 15 int j = 0; 16 i /= j; 17 } 18 19 void main(void) 20 { 21 Crash(); 22 } |
很顯然本程序有“除0錯誤”，在 Debug 方式下編譯的話(huà)，運行時(shí)肯定會(huì )產(chǎn)生“非法操作”。好，讓我們運行它，果然，“非法操作”對話(huà)框出現了，這時(shí)我們點(diǎn)擊“詳細信息”按鈕，記錄下產(chǎn)生崩潰的地址——在我的機器上是 0x0040104a 。
再看看它的 MAP 文件：（由于文件內容太長(cháng)，中間沒(méi)用的部分我進(jìn)行了省略）
| CrashDemo Timestamp is 3e430a76 (Fri Feb 07 09:23:02 2003) Preferred load address is 00400000 Start Length Name Class 0001:00000000 0000de04H .text CODE 0001:0000de04 0001000cH .textbss CODE 0002:00000000 00001346H .rdata DATA 0002:00001346 00000000H .edata DATA 0003:00000000 00000104H .CRT$XCA DATA 0003:00000104 00000104H .CRT$XCZ DATA 0003:00000208 00000104H .CRT$XIA DATA 0003:0000030c 00000109H .CRT$XIC DATA 0003:00000418 00000104H .CRT$XIZ DATA 0003:0000051c 00000104H .CRT$XPA DATA 0003:00000620 00000104H .CRT$XPX DATA 0003:00000724 00000104H .CRT$XPZ DATA 0003:00000828 00000104H .CRT$XTA DATA 0003:0000092c 00000104H .CRT$XTZ DATA 0003:00000a30 00000b93H .data DATA 0003:000015c4 00001974H .bss DATA 0004:00000000 00000014H .idata$2 DATA 0004:00000014 00000014H .idata$3 DATA 0004:00000028 00000110H .idata$4 DATA 0004:00000138 00000110H .idata$5 DATA 0004:00000248 000004afH .idata$6 DATA Address Publics by Value Rva+Base Lib:Object 0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo.obj 0001:00000070 _main 00401070 f CrashDemo.obj 0004:00000000 __IMPORT_DESCRIPTOR_KERNEL32 00424000 kernel32:KERNEL32.dll 0004:00000014 __NULL_IMPORT_DESCRIPTOR 00424014 kernel32:KERNEL32.dll 0004:00000138 __imp__GetCommandLineA@0 00424138 kernel32:KERNEL32.dll 0004:0000013c __imp__GetVersion@0 0042413c kernel32:KERNEL32.dll 0004:00000140 __imp__ExitProcess@4 00424140 kernel32:KERNEL32.dll 0004:00000144 __imp__DebugBreak@0 00424144 kernel32:KERNEL32.dll 0004:00000148 __imp__GetStdHandle@4 00424148 kernel32:KERNEL32.dll 0004:0000014c __imp__WriteFile@20 0042414c kernel32:KERNEL32.dll 0004:00000150 __imp__InterlockedDecrement@4 00424150 kernel32:KERNEL32.dll 0004:00000154 __imp__OutputDebugStringA@4 00424154 kernel32:KERNEL32.dll 0004:00000158 __imp__GetProcAddress@8 00424158 kernel32:KERNEL32.dll 0004:0000015c __imp__LoadLibraryA@4 0042415c kernel32:KERNEL32.dll 0004:00000160 __imp__InterlockedIncrement@4 00424160 kernel32:KERNEL32.dll 0004:00000164 __imp__GetModuleFileNameA@12 00424164 kernel32:KERNEL32.dll 0004:00000168 __imp__TerminateProcess@8 00424168 kernel32:KERNEL32.dll 0004:0000016c __imp__GetCurrentProcess@0 0042416c kernel32:KERNEL32.dll 0004:00000170 __imp__UnhandledExceptionFilter@4 00424170 kernel32:KERNEL32.dll 0004:00000174 __imp__FreeEnvironmentStringsA@4 00424174 kernel32:KERNEL32.dll 0004:00000178 __imp__FreeEnvironmentStringsW@4 00424178 kernel32:KERNEL32.dll 0004:0000017c __imp__WideCharToMultiByte@32 0042417c kernel32:KERNEL32.dll 0004:00000180 __imp__GetEnvironmentStrings@0 00424180 kernel32:KERNEL32.dll 0004:00000184 __imp__GetEnvironmentStringsW@0 00424184 kernel32:KERNEL32.dll 0004:00000188 __imp__SetHandleCount@4 00424188 kernel32:KERNEL32.dll 0004:0000018c __imp__GetFileType@4 0042418c kernel32:KERNEL32.dll 0004:00000190 __imp__GetStartupInfoA@4 00424190 kernel32:KERNEL32.dll 0004:00000194 __imp__HeapDestroy@4 00424194 kernel32:KERNEL32.dll 0004:00000198 __imp__HeapCreate@12 00424198 kernel32:KERNEL32.dll 0004:0000019c __imp__HeapFree@12 0042419c kernel32:KERNEL32.dll 0004:000001a0 __imp__VirtualFree@12 004241a0 kernel32:KERNEL32.dll 0004:000001a4 __imp__RtlUnwind@16 004241a4 kernel32:KERNEL32.dll 0004:000001a8 __imp__GetLastError@0 004241a8 kernel32:KERNEL32.dll 0004:000001ac __imp__SetConsoleCtrlHandler@8 004241ac kernel32:KERNEL32.dll 0004:000001b0 __imp__IsBadWritePtr@8 004241b0 kernel32:KERNEL32.dll 0004:000001b4 __imp__IsBadReadPtr@8 004241b4 kernel32:KERNEL32.dll 0004:000001b8 __imp__HeapValidate@12 004241b8 kernel32:KERNEL32.dll 0004:000001bc __imp__GetCPInfo@8 004241bc kernel32:KERNEL32.dll 0004:000001c0 __imp__GetACP@0 004241c0 kernel32:KERNEL32.dll 0004:000001c4 __imp__GetOEMCP@0 004241c4 kernel32:KERNEL32.dll 0004:000001c8 __imp__HeapAlloc@12 004241c8 kernel32:KERNEL32.dll 0004:000001cc __imp__VirtualAlloc@16 004241cc kernel32:KERNEL32.dll 0004:000001d0 __imp__HeapReAlloc@16 004241d0 kernel32:KERNEL32.dll 0004:000001d4 __imp__MultiByteToWideChar@24 004241d4 kernel32:KERNEL32.dll 0004:000001d8 __imp__LCMapStringA@24 004241d8 kernel32:KERNEL32.dll 0004:000001dc __imp__LCMapStringW@24 004241dc kernel32:KERNEL32.dll 0004:000001e0 __imp__GetStringTypeA@20 004241e0 kernel32:KERNEL32.dll 0004:000001e4 __imp__GetStringTypeW@16 004241e4 kernel32:KERNEL32.dll 0004:000001e8 __imp__SetFilePointer@16 004241e8 kernel32:KERNEL32.dll 0004:000001ec __imp__SetStdHandle@8 004241ec kernel32:KERNEL32.dll 0004:000001f0 __imp__FlushFileBuffers@4 004241f0 kernel32:KERNEL32.dll 0004:000001f4 __imp__CloseHandle@4 004241f4 kernel32:KERNEL32.dll 0004:000001f8 \177KERNEL32_NULL_THUNK_DATA 004241f8 kernel32:KERNEL32.dll entry point at 0001:000000f0 Line numbers for .\Debug\CrashDemo.obj(d:\msdev\myprojects\crashdemo\crashdemo.cpp) segment .text 13 0001:00000020 14 0001:00000038 15 0001:0000003f 16 0001:00000046 17 0001:00000050 20 0001:00000070 21 0001:00000088 22 0001:0000008d |
如果仔細瀏覽 Rva+Base 這欄，你會(huì )發(fā)現第一個(gè)比崩潰地址 0x0040104a 大的函數地址是 0x00401070 ，所以在 0x00401070 這個(gè)地址之前的那個(gè)入口就是產(chǎn)生崩潰的函數，也就是這行：
| 0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo.obj |
因此，發(fā)生崩潰的函數就是 Crash@@YAXXZ ，所有以問(wèn)號開(kāi)頭的函數名稱(chēng)都是 C++ 修飾的名稱(chēng)。在我們的源程序中，也就是 Crash() 這個(gè)子函數。
OK，現在我們輕而易舉地便知道了發(fā)生崩潰的函數名稱(chēng)，你是不是很興奮呢？呵呵，先別忙，接下來(lái)，更厲害的招數要出場(chǎng)了。
請注意 MAP 文件的最后部分——代碼行信息（Line numbers information），它是以這樣的形式顯示的：
| 13 0001:00000020 |
第一個(gè)數字代表在源代碼中的代碼行號，第二個(gè)數是該代碼行在所屬的代碼段中的偏移量。
如果要查找代碼行號，需要使用下面的公式做一些十六進(jìn)制的減法運算：
| 崩潰行偏移 = 崩潰地址（Crash Address） - 基地址（ImageBase Address） - 0x1000 |
為什么要這樣做呢？細心的朋友可能會(huì )留意到 Rva+Base 這欄了，我們得到的崩潰地址都是由 偏移地址（Rva）+ 基地址（Base）得來(lái)的，所以在計算行號的時(shí)候要把基地址減去，一般情況下，基地址的值是 0x00400000 。另外，由于一般的 PE 文件的代碼段都是從0x1000 偏移開(kāi)始的，所以也必須減去 0x1000 。
好了，明白了這點(diǎn)，我們就可以來(lái)進(jìn)行小學(xué)減法計算了：
| 崩潰行偏移 = 0x0040104a - 0x00400000 - 0x1000 = 0x4a |
如果瀏覽 MAP 文件的代碼行信息，會(huì )看到不超過(guò)計算結果，但卻最接近的數是 CrashDemo.cpp 文件中的：
| 16 0001:00000046 |
也就是在源代碼中的第 16 行，讓我們來(lái)看看源代碼:
| 16 i /= j; |
哈?。?！果然就是第 16 行??！
興奮嗎？我也一樣！ ：）
方法已經(jīng)介紹完了，從今以后，我們就可以精確地定位到源代碼中的崩潰行，而且只要編譯器可以生成 MAP 文件（包括VC、MASM、VB、BCB、Delphi……），本方法都是適用的。我們時(shí)常抱怨 M$ 的產(chǎn)品如何如何差，但其實(shí) M$還是有意無(wú)意間提供了很多有價(jià)值的信息給我們的，只是我們往往不懂得怎么利用而已……相信這樣一來(lái)，你就可以更為從容地面對“非法操作”提示了。你甚至可以要求用戶(hù)提供崩潰的地址，然后就可以坐在家中舒舒服服地找到出錯的那行，并進(jìn)行修正。
是不是很爽呢？ ：）
讀了老羅的“僅通過(guò)崩潰地址找出源代碼的出錯行”(下稱(chēng)"羅文")一文后，感覺(jué)該文還是可以學(xué)到不少東西的。不過(guò)文中尚存在有些說(shuō)法不妥，以及有些操作太繁瑣的地方。為此，本人在學(xué)習了此文后，在多次實(shí)驗實(shí)踐基礎上，把該文中的一些內容進(jìn)行補充與改進(jìn)，希望對大家調試程序，尤其是release版本的程序有幫助。歡迎各位朋友批評指正。
一、該方法適用的范圍
在windows程序中造成程序崩潰的原因很多，而文中所述的方法僅適用與:由一條語(yǔ)句當即引起的程序崩潰。如原文中舉的除數為零的崩潰例子。而筆者在實(shí)際工作中碰到更多的情況是:指針指向一非法地址 ，然后對指針的內容進(jìn)行了，讀或寫(xiě)的操作。例如：
void Crash1(){char * p =(char*)100;*p=100;}
這些原因造成的崩潰，無(wú)論是debug版本，還是release版本的程序，使用該方法都可找到造成崩潰的函數或子程序中的語(yǔ)句行，具體方法的下面還會(huì )補充說(shuō)明。另外，實(shí)踐中另一種常見(jiàn)的造成程序崩潰的原因:函數或子程序中局部變量數組越界付值，造成函數或子程序返回地址遭覆蓋，從而造成函數或子程序返回時(shí)崩潰。例如:
#includevoid Crash2();int main(int argc,char* argv[]){Crash2();return 0;}void Crash2(){char p[1];strcpy(p,"0123456789");}
在vc中編譯運行此程序的release版本，會(huì )跳出如下的出錯提示框。
圖一 上面例子運行結果
這里顯示的崩潰地址為:0x34333231。這種由前面語(yǔ)句造成的崩潰根源，在后續程序中方才顯現出來(lái)的情況，顯然用該文所述的方法就無(wú)能為力了。不過(guò)在此例中多少還有些蛛絲馬跡可尋找到崩潰的原因:函數Crash2中的局部數組p只有一個(gè)字節大小，顯然拷貝"0123456789"這個(gè)字符串會(huì )把超出長(cháng)度的字符串拷貝到數組p的后面，即*(p+1)=‘‘‘‘‘‘‘‘1‘‘‘‘‘‘‘‘，*(p+2)=‘‘‘‘‘‘‘‘2‘‘‘‘‘‘‘‘，*(p+3)=‘‘‘‘‘‘‘‘3‘‘‘‘‘‘‘‘，*(p+4)=4。。。。。。而字符‘‘‘‘‘‘‘‘1‘‘‘‘‘‘‘‘的ASC碼的值為0x31，‘‘‘‘‘‘‘‘2‘‘‘‘‘‘‘‘為0x32，‘‘‘‘‘‘‘‘3‘‘‘‘‘‘‘‘為0x33，‘‘‘‘‘‘‘‘4‘‘‘‘‘‘‘‘為0x34。。。。。，由于intel的cpu中int型數據是低字節保存在低地址中，所以保存字符串‘‘‘‘‘‘‘‘1234‘‘‘‘‘‘‘‘的內存，顯示為一個(gè)4字節的int型數時(shí)就是0x34333231。顯然拷貝"0123456789"這個(gè)字符串時(shí)，"1234"這幾個(gè)字符把函數Crash2的返回地址給覆蓋，從而造成程序崩潰。對于類(lèi)似的這種造成程序崩潰的錯誤朋友們還有其他方法排錯的話(huà)，歡迎一起交流討論。
二、設置編譯產(chǎn)生map文件的方法
該文中產(chǎn)生map文件的方法是手工添加編譯參數來(lái)產(chǎn)生map文件。其實(shí)在vc6的IDE中有產(chǎn)生map文件的配置選項的。操作如下:先點(diǎn)擊菜單"Project"->"Settings。。。"，彈出的屬性頁(yè)中選中"Link"頁(yè)，確保在"category"中選中"General"，最后選中"Generate mapfile"的可選項。若要在在map文件中顯示Linenumbers的信息的話(huà) ，還需在project options 中加入/mapinfo:lines 。Linenumbers信息對于"羅文"所用的方法來(lái)定位出錯源代碼行很重要 ，但筆者后面會(huì )介紹更加好的方法來(lái)定位出錯代碼行，那種方法不需要Linenumbers信息。
圖二 設置產(chǎn)生MAP文件
三、定位崩潰語(yǔ)句位置的方法
"羅文"所述的定位方法中，-y4管MeIU#W]O育gT中Se網(wǎng)找到產(chǎn)生崩潰的函數位置的方法是正確的，即在map文件列出的每個(gè)函數的起始地址中，最近的且不大于崩潰地址的地址即為包含崩潰語(yǔ)句的函數的地址。但之后的再進(jìn)一步的定位出錯語(yǔ)句行的方法不是最妥當，因為那種方法前提是，假設基地址的值是 0x00400000 ，以及一般的 PE文件的代碼段都是從 0x1000偏移開(kāi)始的。雖然這種情況很普遍，但在vc中還是可以基地址設置為其他數，比如設置為0x00500000，這時(shí)仍舊套用
崩潰行偏移 = 崩潰地址 - 0x00400000 - 0x1000
的公式顯然無(wú)法找到崩潰行偏移。 其實(shí)上述公式若改為
崩潰行偏移 = 崩潰地址 - 崩潰函數絕對地址 + 函數相對偏移
即可通用了。仍以"羅文"中的例子為例:"羅文"中提到的在其崩潰程序的對應map文件中，崩潰函數的編譯結果為
0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo。obj
對與上述結果，在使用我的公式時(shí) ，"崩潰函數絕對地址"指00401020， 函數相對偏移指 00000020， 當崩潰地址=0x0040104a時(shí)， 則 崩潰行偏移 = 崩潰地址 - 崩潰函數起始地址+ 函數相對偏移 = 0x0040104a -0x00401020 + 0x00000020= 0x4a，結果與"羅文"計算結果相同 。但這個(gè)公式更通用。
四、更好的定位崩潰語(yǔ)句位置的方法。
其實(shí)除了依靠map文件中的Linenumbers信息最終定位出錯語(yǔ)句行外，在vc6中我們還可以通過(guò)編譯程序產(chǎn)生的對應的匯編語(yǔ)句，二進(jìn)制碼，以及對應c/c++語(yǔ)句為一體的"cod"文件來(lái)定位出錯語(yǔ)句行。先介紹一下產(chǎn)生這種包含了三種信息的"cod"文件的設置方法:先點(diǎn)擊菜單"Project"->"Settings。。。"，彈出的屬性頁(yè)中選中"C/C++"頁(yè) ，然后在"Category"中選則"Listing Files"，再在"Listing filetype"的組合框中選擇"Assembly，Machine code， andsource"。接下去再通過(guò)一個(gè)具體的例子來(lái)說(shuō)明這種方法的具體操作。
圖三 設置產(chǎn)生"cod"文件
準備步驟1)產(chǎn)生崩潰的程序如下:
01 //****************************************************************02 //文件名稱(chēng)：crash。cpp03 //作用: 演示通過(guò)崩潰地址找出源代碼的出錯行新方法04 //作者： 偉功通信 roc05 //日期： 2005-5-1606//****************************************************************07 void Crash1();08 int main(int argc,char* argv[])09 {10 Crash1();11 return 0;12 }1314 void Crash1()15 {16 char * p =(char*)100;17 *p=100;18 }準備步驟2)按本文所述設置產(chǎn)生map文件(不需要產(chǎn)生Line numbers信息)。
準備步驟3)按本文所述設置產(chǎn)生cod文件。
準備步驟4)編譯。這里以debug版本為例(若是release版本需要將編譯選項改為不進(jìn)行任何優(yōu)化的選項，否則上述代碼會(huì )因為優(yōu)化時(shí)看作廢代碼而不被編譯，從而看不到崩潰的結果)，編譯后產(chǎn)生一個(gè)"exe"文件 ，一個(gè)"map"文件，一個(gè)"cod"文件。
運行此程序，產(chǎn)生如下如下崩潰提示:
圖四 上面例子運行結果
排錯步驟1)定位崩潰函數?？梢圆樵?xún)map文件獲得。我的機器編譯產(chǎn)生的map文件的部分如下:
CrashTimestamp is 42881a01 (Mon May 16 11:56:49 2005)Preferred load address is 00400000Start Length Name Class0001:00000000 0000ddf1H .text CODE0001:0000ddf1 0001000fH .textbss CODE0002:00000000 00001346H .rdata DATA0002:00001346 00000000H .edata DATA0003:00000000 00000104H .CRT$XCA DATA0003:00000104 00000104H .CRT$XCZ DATA0003:00000208 00000104H .CRT$XIA DATA0003:0000030c 00000109H .CRT$XIC DATA0003:00000418 00000104H .CRT$XIZ DATA0003:0000051c 00000104H .CRT$XPA DATA0003:00000620 00000104H .CRT$XPX DATA0003:00000724 00000104H .CRT$XPZ DATA0003:00000828 00000104H .CRT$XTA DATA0003:0000092c 00000104H .CRT$XTZ DATA0003:00000a30 00000b93H .data DATA0003:000015c4 00001974H .bss DATA0004:00000000 00000014H .idata$2 DATA0004:00000014 00000014H .idata$3 DATA0004:00000028 00000110H .idata$4 DATA0004:00000138 00000110H .idata$5 DATA0004:00000248 000004afH .idata$6 DATAAddress Publics by Value Rva+Base Lib:Object0001:00000020 _main 00401020 f Crash.obj0001:00000060 ?Crash1@@YAXXZ 00401060 f Crash.obj0001:000000a0 __chkesp 004010a0 f LIBCD:chkesp.obj0001:000000e0 _mainCRTStartup 004010e0 f LIBCD:crt0.obj0001:00000210 __amsg_exit 00401210 f LIBCD:crt0.obj0001:00000270 __CrtDbgBreak 00401270 f LIBCD:dbgrpt.obj...
對于崩潰地址0x00401082而言，小于此地址中最接近的地址(Rva+Base中的地址)為00401060，其對應的函數名為?Crash1@@YAXXZ，由于所有以問(wèn)號開(kāi)頭的函數名稱(chēng)都是 C++ 修飾的名稱(chēng)，"@@YAXXZ"則為區別重載函數而加的后綴，所以?Crash1@@YAXXZ就是我們的源程序中，Crash1() 這個(gè)函數。
排錯步驟2)定位出錯行。打開(kāi)編譯生成的"cod"文件，我機器上生成的文件內容如下:
TITLE E:\Crash\Crash。cpp.386Pinclude listing.incif @Version gt 510.model FLATelse_TEXT SEGMENT PARA USE32 PUBLIC ‘‘‘‘‘‘‘‘CODE‘‘‘‘‘‘‘‘_TEXT ENDS_DATA SEGMENT DWORD USE32 PUBLIC ‘‘‘‘‘‘‘‘DATA‘‘‘‘‘‘‘‘_DATA ENDSCONST SEGMENT DWORD USE32 PUBLIC ‘‘‘‘‘‘‘‘CONST‘‘‘‘‘‘‘‘CONST ENDS_BSS SEGMENT DWORD USE32 PUBLIC ‘‘‘‘‘‘‘‘BSS‘‘‘‘‘‘‘‘_BSS ENDS$$SYMBOLS SEGMENT BYTE USE32 ‘‘‘‘‘‘‘‘DEBSYM‘‘‘‘‘‘‘‘$$SYMBOLS ENDS$$TYPES SEGMENT BYTE USE32 ‘‘‘‘‘‘‘‘DEBTYP‘‘‘‘‘‘‘‘$$TYPES ENDS_TLS SEGMENT DWORD USE32 PUBLIC ‘‘‘‘‘‘‘‘TLS‘‘‘‘‘‘‘‘_TLS ENDS; COMDAT _main_TEXT SEGMENT PARA USE32 PUBLIC ‘‘‘‘‘‘‘‘CODE‘‘‘‘‘‘‘‘_TEXT ENDS; COMDAT ?Crash1@@YAXXZ_TEXT SEGMENT PARA USE32 PUBLIC ‘‘‘‘‘‘‘‘CODE‘‘‘‘‘‘‘‘_TEXT ENDSFLAT GROUP _DATA， CONST, _BSSASSUME CS: FLAT, DS: FLAT, SS: FLATendifPUBLIC ?Crash1@@YAXXZ ; Crash1PUBLIC _mainEXTRN __chkesp:NEAR; COMDAT _main_TEXT SEGMENT_main PROC NEAR ; COMDAT; 9 : {00000 55 push ebp00001 8b ec mov ebp， esp00003 83 ec 40 sub esp, 64 ; 00000040H00006 53 push ebx00007 56 push esi00008 57 push edi00009 8d 7d c0 lea edi, DWORD PTR [ebp-64]0000c b9 10 00 00 00 mov ecx， 16 ; 00000010H00011 b8 cc cc cc cc mov eax， -858993460 ; ccccccccH00016 f3 ab rep stosd; 10 : Crash1();00018 e8 00 00 00 00 call ?Crash1@@YAXXZ ; Crash1; 11 : return 0;0001d 33 c0 xor eax， eax; 12 : }0001f 5f pop edi00020 5e pop esi00021 5b pop ebx00022 83 c4 40 add esp, 64 ; 00000040H00025 3b ec cmp ebp, esp00027 e8 00 00 00 00 call __chkesp0002c 8b e5 mov esp, ebp0002e 5d pop ebp0002f c3 ret 0_main ENDP_TEXT ENDS; COMDAT ?Crash1@@YAXXZ_TEXT SEGMENT_p$ = -4?Crash1@@YAXXZ PROC NEAR ; Crash1, COMDAT; 15 : {00000 55 push ebp00001 8b ec mov ebp, esp00003 83 ec 44 sub esp, 68 ; 00000044H00006 53 push ebx00007 56 push esi00008 57 push edi00009 8d 7d bc lea edi, DWORD PTR [ebp-68]0000c b9 11 00 00 00 mov ecx, 17 ; 00000011H00011 b8 cc cc cc cc mov eax, -858993460 ; ccccccccH00016 f3 ab rep stosd; 16 : char * p =(char*)100;00018 c7 45 fc 64 0000 00 mov DWORD PTR _p$[ebp], 100 ; 00000064H; 17 : *p=100;0001f 8b 45 fc mov eax, DWORD PTR _p$[ebp]00022 c6 00 64 mov BYTE PTR [eax], 100 ; 00000064H; 18 : }00025 5f pop edi00026 5e pop esi00027 5b pop ebx00028 8b e5 mov esp, ebp0002a 5d pop ebp0002b c3 ret 0?Crash1@@YAXXZ ENDP ; Crash1_TEXT ENDSEND其中
Crash1@@YAXXZ PROC NEAR ; Crash1, COMDAT
為Crash1匯編代碼的起始行。產(chǎn)生崩潰的代碼便在其后的某個(gè)位置。接下去的一行為:
; 15 : {冒號后的"{"表示源文件中的語(yǔ)句，冒號前的"15"表示該語(yǔ)句在源文件中的行數。 這之后顯示該語(yǔ)句匯編后的偏移地址，二進(jìn)制碼，匯編代碼。如
00000 55 push ebp
其中"0000"表示相對于函數開(kāi)始地址后的偏移，"55"為編譯后的機器代碼，" push ebp"為匯編代碼。從"cod"文件中我們可以看出，一條(c/c++)語(yǔ)句通常需要編譯成數條匯編語(yǔ)句 。此外有些匯編語(yǔ)句太長(cháng)則會(huì )分兩行顯示如:
00018 c7 45 fc 64 0000 00 mov DWORD PTR _p$[ebp], 100 ; 00000064H
其中"0018"表示相對偏移，在debug版本中，這個(gè)數據為相對于函數起始地址的偏移(此時(shí)每個(gè)函數第一條語(yǔ)句相對偏移為0000)；release版本中為相對于代碼段第一條語(yǔ)句的偏移(即代碼段第一條語(yǔ)句相對偏移為0000，而以后的每個(gè)函數第一條語(yǔ)句相對偏移就不為0000了)。"c7 45fc 64 00 00 00 "為編譯后的機器代碼 ，"mov DWORD PTR _p$[ebp]， 100"為匯編代碼，匯編語(yǔ)言中";"后的內容為注釋?zhuān)?;00000064H"，是個(gè)注釋這里用來(lái)說(shuō)明100轉換成16進(jìn)制時(shí)為"00000064H"。
接下去，我們開(kāi)始來(lái)定位產(chǎn)生崩潰的語(yǔ)句。
第一步，計算崩潰地址相對于崩潰函數的偏移，在本例中已經(jīng)知道了崩潰語(yǔ)句的地址(0x00401082)，和對應函數的起始地址(0x00401060)，所以崩潰地址相對函數起始地址的偏移就很容易計算了:
崩潰偏移地址 = 崩潰語(yǔ)句地址 - 崩潰函數的起始地址 = 0x00401082 - 0x00401060 = 0x22。
第二步，計算出錯的匯編語(yǔ)句在cod文件中的相對偏移。我們可以看到函數Crash1()在cod文件中的相對偏移地址為0000，則
崩潰語(yǔ)句在cod文件中的相對偏移 = 崩潰函數在cod文件中相對偏移 + 崩潰偏移地址 = 0x0000 + 0x22 = 0x22
第三步，我們看Crash1函數偏移0x22除的代碼是什么?結果如下
00022 c6 00 64 mov BYTE PTR [eax], 100 ; 00000064H
這句匯編語(yǔ)句表示將100這個(gè)數保存到寄存器eax所指的內存單元中去，保存空間大小為1個(gè)字節(byte)。程序正是執行這條命令時(shí)產(chǎn)生了崩潰，顯然這里eax中的為一個(gè)非法地址 ，所以程序崩潰了!
第四步，再查看該匯編語(yǔ)句在其前面幾行的其對應的源代碼，結果如下:
; 17 : *p=100;
其中17表示該語(yǔ)句位于源文件中第17行，而“*p=100;”這正是源文件中產(chǎn)生崩潰的語(yǔ)句。
至此我們僅從崩潰地址就查找出了造成崩潰的源代碼語(yǔ)句和該語(yǔ)句所在源文件中的確切位置，甚至查找到了造成崩潰的編譯后的確切匯編代碼!
怎么樣，是不是感覺(jué)更爽啊?
五、小節
1、新方法同樣要注意可以適用的范圍，即程序由一條語(yǔ)句當即引起的崩潰。另外我不知道除了VC6外，是否還有其他的編譯器能夠產(chǎn)生類(lèi)似的"cod"文件。
2、我們可以通過(guò)比較新方法產(chǎn)生的debug和releae版本的"cod"文件，查找那些僅release版本(或debug版本)有另一個(gè)版本沒(méi)有的bug(或其他性狀)。例如"羅文"中所舉的那個(gè)用例，只要打開(kāi)release版本的"cod"文件，就明白了為啥debug版本會(huì )產(chǎn)生崩潰而release版本卻沒(méi)有:原來(lái)release版本中產(chǎn)生崩潰的語(yǔ)句其實(shí)根本都沒(méi)有編譯 。同樣本例中的release版本要看到崩潰的效果，需要將編譯選項改為為不優(yōu)化的配置。
