對“僅通過崩潰地址找出源代碼的出錯行”一文的補充與改進 /原文

讀了老羅的“僅通過崩潰地址找出源代碼的出錯行”(下稱"羅文")一文後，感覺該文還是可以學到不少東西的。不過文中尚存在有些說法不妥，以及有些操作太繁瑣的地方 。爲此，本人在學習了此文後，在多次實驗實踐基礎上，把該文中的一些內容進行補充與改進，希望對大家調試程序，尤其是release版本的程序有幫助 。歡迎各位朋友批評指正。


一、該方法適用的範圍
　　在windows程序中造成程序崩潰的原因很多，而文中所述的方法僅適用與:由一條語句當即引起的程序崩潰。如原文中舉的除數爲零的崩潰例子。而筆者在實際工作中碰到更多的情況是:指針指向一非法地址 ，然後對指針的內容進行了，讀或寫的操作。例如：

void Crash1()
{
 char * p =(char*)100;
 *p=100;
}

這些原因造成的崩潰，無論是debug版本，還是release版本的程序，使用該方法都可找到造成崩潰的函數或子程序中的語句行，具體方法的下面還會補充說明。 另外，實踐中另一種常見的造成程序崩潰的原因:函數或子程序中局部變量數組越界付值，造成函數或子程序返回地址遭覆蓋，從而造成函數或子程序返回時崩潰。例如:

#include 
void Crash2();
int main(int argc,char* argv[])
{
	Crash2();
	return 0;
}

void Crash2()
{
	char p[1];
	strcpy(p,"0123456789");
}

在vc中編譯運行此程序的release版本，會跳出如下的出錯提示框。 


圖一 上面例子運行結果

　　這裏顯示的崩潰地址爲:0x34333231。這種由前面語句造成的崩潰根源，在後續程序中方纔顯現出來的情況，顯然用該文所述的方法就無能爲力了。不過在此例中多少還有些蛛絲馬跡可尋找到崩潰的原因:函數Crash2中的局部數組p只有一個字節大小 ，顯然拷貝"0123456789"這個字符串會把超出長度的字符串拷貝到數組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''的內存，顯示爲一個4字節的int型數時就是0x34333231。顯然拷貝"0123456789"這個字符串時，"1234"這幾個字符把函數Crash2的返回地址給覆蓋 ，從而造成程序崩潰。對於類似的這種造成程序崩潰的錯誤朋友們還有其他方法排錯的話，歡迎一起交流討論。


二、設置編譯產生map文件的方法
　　該文中產生map文件的方法是手工添加編譯參數來產生map文件。其實在vc6的IDE中有產生map文件的配置選項的。操作如下:先點擊菜單"Project"->"Settings。。。"，彈出的屬性頁中選中"Link"頁 ，確保在"category"中選中"General"，最後選中"Generate mapfile"的可選項。若要在在map文件中顯示Line numbers的信息的話 ，還需在project options 中加入/mapinfo:lines 。Line numbers信息對於"羅文"所用的方法來定位出錯源代碼行很重要 ，但筆者後面會介紹更加好的方法來定位出錯代碼行，那種方法不需要Line numbers信息。 


圖二 設置產生MAP文件 


三、定位崩潰語句位置的方法
　　"羅文"所述的定位方法中，找到產生崩潰的函數位置的方法是正確的，即在map文件列出的每個函數的起始地址中，最近的且不大於崩潰地址的地址即爲包含崩潰語句的函數的地址 。但之後的再進一步的定位出錯語句行的方法不是最妥當，因爲那種方法前提是，假設基地址的值是 0x00400000 ，以及一般的 PE 文件的代碼段都是從 0x1000偏移開始的 。雖然這種情況很普遍，但在vc中還是可以基地址設置爲其他數，比如設置爲0x00500000，這時仍舊套用

 崩潰行偏移 = 崩潰地址 - 0x00400000 - 0x1000 

的公式顯然無法找到崩潰行偏移。 其實上述公式若改爲

崩潰行偏移 = 崩潰地址 - 崩潰函數絕對地址 + 函數相對偏移

即可通用了。仍以"羅文"中的例子爲例:"羅文"中提到的在其崩潰程序的對應map文件中，崩潰函數的編譯結果爲

0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo。obj 

對與上述結果，在使用我的公式時 ，"崩潰函數絕對地址"指00401020， 函數相對偏移指 00000020， 當崩潰地址= 0x0040104a時， 則 崩潰行偏移 = 崩潰地址 - 崩潰函數起始地址+ 函數相對偏移 = 0x0040104a - 0x00401020 + 0x00000020= 0x4a，結果與"羅文"計算結果相同 。但這個公式更通用。


四、更好的定位崩潰語句位置的方法。
　　其實除了依靠map文件中的Line numbers信息最終定位出錯語句行外，在vc6中我們還可以通過編譯程序產生的對應的彙編語句，二進制碼，以及對應c/c++語句爲一體的"cod"文件來定位出錯語句行 。先介紹一下產生這種包含了三種信息的"cod"文件的設置方法:先點擊菜單"Project"->"Settings。。。"，彈出的屬性頁中選中"C/C++"頁 ，然後在"Category"中選則"Listing Files"，再在"Listing file type"的組合框中選擇"Assembly，Machine code， and source"。接下去再通過一個具體的例子來說明這種方法的具體操作。 


圖三 設置產生"cod"文件 

準備步驟1)產生崩潰的程序如下:

01 //****************************************************************
02 //文件名稱：crash。cpp
03 //作用:    演示通過崩潰地址找出源代碼的出錯行新方法
04 //作者：   偉功通信 roc
05 //日期：   2005-5-16
06//****************************************************************
07 void Crash1();
08 int main(int argc,char* argv[])
09 {
10	Crash1();
11	return 0;
12 }
13
14 void Crash1()
15 {
16  char * p =(char*)100;
17  *p=100;
18 }

準備步驟2)按本文所述設置產生map文件(不需要產生Line numbers信息)。
準備步驟3)按本文所述設置產生cod文件。
準備步驟4)編譯。這裏以debug版本爲例(若是release版本需要將編譯選項改爲不進行任何優化的選項，否則上述代碼會因爲優化時看作廢代碼而不被編譯，從而看不到崩潰的結果)，編譯後產生一個"exe"文件 ，一個"map"文件，一個"cod"文件。 
運行此程序，產生如下如下崩潰提示: 


圖四 上面例子運行結果 

排錯步驟1)定位崩潰函數。可以查詢map文件獲得。我的機器編譯產生的map文件的部分如下:

 Crash

 Timestamp is 42881a01 (Mon May 16 11:56:49 2005)

 Preferred load address is 00400000

 Start Length Name Class
0001:00000000 0000ddf1H .text CODE
0001:0000ddf1 0001000fH .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 _main 00401020 f Crash.obj
0001:00000060 ?Crash1@@YAXXZ 00401060 f Crash.obj
0001:000000a0 __chkesp 004010a0 f LIBCD:chkesp.obj
0001:000000e0 _mainCRTStartup 004010e0 f LIBCD:crt0.obj
0001:00000210 __amsg_exit 00401210 f LIBCD:crt0.obj
0001:00000270 __CrtDbgBreak 00401270 f LIBCD:dbgrpt.obj
...

對於崩潰地址0x00401082而言，小於此地址中最接近的地址(Rva+Base中的地址)爲00401060，其對應的函數名爲?Crash1@@YAXXZ，由於所有以問號開頭的函數名稱都是 C++ 修飾的名稱 ，"@@YAXXZ"則爲區別重載函數而加的後綴，所以?Crash1@@YAXXZ就是我們的源程序中，Crash1() 這個函數。
排錯步驟2)定位出錯行。打開編譯生成的"cod"文件，我機器上生成的文件內容如下:

	TITLE	E:/Crash/Crash。cpp
	.386P
include listing.inc
if @Version gt 510
.model FLAT
else
_TEXT	SEGMENT PARA USE32 PUBLIC ''CODE''
_TEXT	ENDS
_DATA	SEGMENT DWORD USE32 PUBLIC ''DATA''
_DATA	ENDS
CONST	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	ENDS
FLAT	GROUP _DATA， CONST, _BSS
	ASSUME	CS: FLAT, DS: FLAT, SS: FLAT
endif
PUBLIC	?Crash1@@YAXXZ					; Crash1
PUBLIC	_main
EXTRN	__chkesp:NEAR
;	COMDAT _main
_TEXT	SEGMENT
_main	PROC NEAR					; COMDAT

; 9    : {

  00000	55		 push	 ebp
  00001	8b ec		 mov	 ebp， esp
  00003	83 ec 40	 sub	 esp, 64			; 00000040H
  00006	53		 push	 ebx
  00007	56		 push	 esi
  00008	57		 push	 edi
  00009	8d 7d c0	 lea	 edi, DWORD PTR [ebp-64]
  0000c	b9 10 00 00 00	 mov	 ecx， 16			; 00000010H
  00011	b8 cc cc cc cc	 mov	 eax， -858993460		; ccccccccH
  00016	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	 edi
  00020	5e		 pop	 esi
  00021	5b		 pop	 ebx
  00022	83 c4 40	 add	 esp, 64			; 00000040H
  00025	3b ec		 cmp	 ebp, esp
  00027	e8 00 00 00 00	 call	 __chkesp
  0002c	8b e5		 mov	 esp, ebp
  0002e	5d		 pop	 ebp
  0002f	c3		 ret	 0
_main	ENDP
_TEXT	ENDS
;	COMDAT ?Crash1@@YAXXZ
_TEXT	SEGMENT
_p$ = -4
?Crash1@@YAXXZ PROC NEAR				; Crash1, COMDAT

; 15   : {

  00000	55		 push	 ebp
  00001	8b ec		 mov	 ebp, esp
  00003	83 ec 44	 sub	 esp, 68			; 00000044H
  00006	53		 push	 ebx
  00007	56		 push	 esi
  00008	57		 push	 edi
  00009	8d 7d bc	 lea	 edi, DWORD PTR [ebp-68]
  0000c	b9 11 00 00 00	 mov	 ecx, 17			; 00000011H
  00011	b8 cc cc cc cc	 mov	 eax, -858993460		; ccccccccH
  00016	f3 ab		 rep stosd

; 16   :  char * p =(char*)100;

  00018	c7 45 fc 64 00
	00 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	 edi
  00026	5e		 pop	 esi
  00027	5b		 pop	 ebx
  00028	8b e5		 mov	 esp, ebp
  0002a	5d		 pop	 ebp
  0002b	c3		 ret	 0
?Crash1@@YAXXZ ENDP					; Crash1
_TEXT	ENDS
END

其中

?Crash1@@YAXXZ PROC NEAR				; Crash1, COMDAT

爲Crash1彙編代碼的起始行。產生崩潰的代碼便在其後的某個位置。接下去的一行爲: 

; 15   : {

冒號後的"{"表示源文件中的語句，冒號前的"15"表示該語句在源文件中的行數。 這之後顯示該語句彙編後的偏移地址，二進制碼，彙編代碼。如 

00000	55		 push	 ebp

其中"0000"表示相對於函數開始地址後的偏移，"55"爲編譯後的機器代碼，" push ebp"爲彙編代碼。從"cod"文件中我們可以看出，一條(c/c++)語句通常需要編譯成數條彙編語句 。此外有些彙編語句太長則會分兩行顯示如: 

00018	c7 45 fc 64 00
	00 00		 mov	 DWORD PTR _p$[ebp], 100	; 00000064H

其中"0018"表示相對偏移，在debug版本中，這個數據爲相對於函數起始地址的偏移(此時每個函數第一條語句相對偏移爲0000)；release版本中爲相對於代碼段第一條語句的偏移(即代碼段第一條語句相對偏移爲0000，而以後的每個函數第一條語句相對偏移就不爲0000了)。"c7 45 fc 64 00 00 00 "爲編譯後的機器代碼 ，"mov DWORD PTR _p$[ebp]， 100"爲彙編代碼， 彙編語言中";"後的內容爲註釋，所以";00000064H"，是個註釋這裏用來說明100轉換成16進制時爲"00000064H"。
接下去，我們開始來定位產生崩潰的語句。
第一步，計算崩潰地址相對於崩潰函數的偏移，在本例中已經知道了崩潰語句的地址(0x00401082)，和對應函數的起始地址(0x00401060)，所以崩潰地址相對函數起始地址的偏移就很容易計算了: 

  崩潰偏移地址 = 崩潰語句地址 - 崩潰函數的起始地址 = 0x00401082 - 0x00401060 = 0x22。

第二步，計算出錯的彙編語句在cod文件中的相對偏移。我們可以看到函數Crash1()在cod文件中的相對偏移地址爲0000，則 

崩潰語句在cod文件中的相對偏移 =  崩潰函數在cod文件中相對偏移 + 崩潰偏移地址 = 0x0000 + 0x22 = 0x22

第三步，我們看Crash1函數偏移0x22除的代碼是什麼?結果如下 

 00022	c6 00 64	 mov	 BYTE PTR [eax], 100	; 00000064H

這句彙編語句表示將100這個數保存到寄存器eax所指的內存單元中去，保存空間大小爲1個字節(byte)。程序正是執行這條命令時產生了崩潰，顯然這裏eax中的爲一個非法地址 ，所以程序崩潰了!
第四步，再查看該彙編語句在其前面幾行的其對應的源代碼，結果如下: 

; 17   :  *p=100;

其中17表示該語句位於源文件中第17行，而“*p=100;”這正是源文件中產生崩潰的語句。
至此我們僅從崩潰地址就查找出了造成崩潰的源代碼語句和該語句所在源文件中的確切位置，甚至查找到了造成崩潰的編譯後的確切彙編代碼!
怎麼樣，是不是感覺更爽啊?


五、小節

1、新方法同樣要注意可以適用的範圍，即程序由一條語句當即引起的崩潰。另外我不知道除了VC6外，是否還有其他的編譯器能夠產生類似的"cod"文件。
2、我們可以通過比較 新方法產生的debug和releae版本的"cod"文件，查找那些僅release版本(或debug版本)有另一個版本沒有的bug(或其他性狀)。例如"羅文"中所舉的那個用例 ，只要打開release版本的"cod"文件，就明白了爲啥debug版本會產生崩潰而release版本卻沒有:原來release版本中產生崩潰的語句其實根本都沒有編譯 。同樣本例中的release版本要看到崩潰的效果，需要將編譯選項改爲爲不優化的配置。

 

 

 

-------------------------------------

僅通過崩潰地址找出源代碼的出錯行

作爲程序員，我們平時最擔心見到的事情是什麼？是內存泄漏？是界面不好看？……錯啦！我相信我的看法是不會有人反對的——那就是，程序發生了崩潰！

“該程序執行了非法操作，即將關閉。請與你的軟件供應商聯繫。”，呵呵，這句 M$ 的“名言”，恐怕就是程序員最擔心見到的東西了。有的時候，自己的程序在自己的機器上運行得好好的，但是到了別人的機器上就崩潰了；有時自己在編寫和測試的過程中就莫名其妙地遇到了非法操作，但是卻無法確定到底是源代碼中的哪行引起的……是不是很痛苦呢？不要緊，本文可以幫助你走出這種困境，甚至你從此之後可以自豪地要求用戶把崩潰地址告訴你，然後你就可以精確地定位到源代碼中出錯的那行了。（很神奇吧？呵呵。）

首先我必須強調的是，本方法可以在目前市面上任意一款編譯器上面使用。但是我只熟悉 M$ 的 VC 和 MASM ，因此後面的部分只介紹如何在這兩個編譯器中實現，請讀者自行融會貫通，掌握在別的編譯器上使用的方法。

Well，廢話說完了，讓我們開始！ ：）

首先必須生成程序的 MAP 文件。什麼是 MAP 文件？簡單地講， MAP 文件是程序的全局符號、源文件和代碼行號信息的唯一的文本表示方法，它可以在任何地方、任何時候使用，不需要有額外的程序進行支持。而且，這是唯一能找出程序崩潰的地方的救星。

好吧，既然 MAP 文件如此神奇，那麼我們應該如何生成它呢？在 VC 中，我們可以按下 Alt+F7 ，打開“Project Settings”選項頁，選擇 C/C++ 選項卡，並在最下面的 Project Options 裏面輸入：/Zd ，然後要選擇 Link 選項卡，在最下面的 Project Options 裏面輸入： /mapinfo:lines 和 /map:PROJECT_NAME.map 。最後按下 F7 來編譯生成 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 來編譯生成 EXE 可執行文件和 MAP 文件了。

在此我先解釋一下加入的參數的含義：

/Zd 表示在編譯的時候生成行信息
/map[:filename] 表示生成 MAP 文件的路徑和文件名
/mapinfo:lines 表示生成 MAP 文件時，加入行信息
/mapinfo:exports 表示生成 MAP 文件時，加入 exported functions （如果生成的是 DLL 文件，這個選項就要加上）

OK，通過上面的步驟，我們已經得到了 MAP 文件，那麼我們該如何利用它呢？

讓我們從簡單的實例入手，請打開你的 VC ，新建這樣一個文件：

01 //****************************************************************
02 //程序名稱：演示如何通過崩潰地址找出源代碼的出錯行
03 //作者：羅聰
04 //日期：2003-2-7
05 //出處：http://www.luocong.com（老羅的繽紛天地）
06 //本程序會產生“除0錯誤”，以至於會彈出“非法操作”對話框。
07 //“除0錯誤”只會在 Debug 版本下產生，本程序爲了演示而儘量簡化。
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 方式下編譯的話，運行時肯定會產生“非法操作”。好，讓我們運行它，果然，“非法操作”對話框出現了，這時我們點擊“詳細信息”按鈕，記錄下產生崩潰的地址——在我的機器上是 0x0040104a 。

再看看它的 MAP 文件：（由於文件內容太長，中間沒用的部分我進行了省略）

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 這欄，你會發現第一個比崩潰地址 0x0040104a 大的函數地址是 0x00401070 ，所以在 0x00401070 這個地址之前的那個入口就是產生崩潰的函數，也就是這行：

0001:00000020 ?Crash@@YAXXZ 00401020 f CrashDemo.obj

因此，發生崩潰的函數就是 ?Crash@@YAXXZ ，所有以問號開頭的函數名稱都是 C++ 修飾的名稱。在我們的源程序中，也就是 Crash() 這個子函數。

OK，現在我們輕而易舉地便知道了發生崩潰的函數名稱，你是不是很興奮呢？呵呵，先別忙，接下來，更厲害的招數要出場了。

請注意 MAP 文件的最後部分——代碼行信息（Line numbers information），它是以這樣的形式顯示的：

13 0001:00000020

第一個數字代表在源代碼中的代碼行號，第二個數是該代碼行在所屬的代碼段中的偏移量。

如果要查找代碼行號，需要使用下面的公式做一些十六進制的減法運算：

崩潰行偏移 = 崩潰地址（Crash Address） - 基地址（ImageBase Address） - 0x1000

爲什麼要這樣做呢？細心的朋友可能會留意到 Rva+Base 這欄了，我們得到的崩潰地址都是由 偏移地址（Rva）+ 基地址（Base） 得來的，所以在計算行號的時候要把基地址減去，一般情況下，基地址的值是 0x00400000 。另外，由於一般的 PE 文件的代碼段都是從 0x1000 偏移開始的，所以也必須減去 0x1000 。

好了，明白了這點，我們就可以來進行小學減法計算了：

崩潰行偏移 = 0x0040104a - 0x00400000 - 0x1000 = 0x4a

如果瀏覽 MAP 文件的代碼行信息，會看到不超過計算結果，但卻最接近的數是 CrashDemo.cpp 文件中的：

16 0001:00000046

也就是在源代碼中的第 16 行，讓我們來看看源代碼:

16 i /= j;

哈！！！果然就是第 16 行啊！

興奮嗎？我也一樣！ ：）

方法已經介紹完了，從今以後，我們就可以精確地定位到源代碼中的崩潰行，而且只要編譯器可以生成 MAP 文件（包括 VC、MASM、VB、BCB、Delphi……），本方法都是適用的。我們時常抱怨 M$ 的產品如何如何差，但其實 M$ 還是有意無意間提供了很多有價值的信息給我們的，只是我們往往不懂得怎麼利用而已……相信這樣一來，你就可以更爲從容地面對“非法操作”提示了。你甚至可以要求用戶提供崩潰的地址，然後就可以坐在家中舒舒服服地找到出錯的那行，並進行修正。