1. 程式人生 > >windows 應用程式崩潰時的記憶體轉儲及dump檔案的分析

windows 應用程式崩潰時的記憶體轉儲及dump檔案的分析

1、在現場設定程式崩潰時的自動記憶體轉儲,得到dump檔案

       在windows 登錄檔如下項:

     //HKEY_LOCAL_MACHINE/Software/Microsoft/Windows NT/CurrentVersion/AeDebug

     中提供了偵錯程式的相關設定。

      Debugger  設定具體的偵錯程式和啟動引數

      Auto  是否設定在傳送錯誤前啟動偵錯程式

      以windbg為例

      Debugger = "Path/WinDbg.exe" -p %ld –c ".dump /ma /u C:/CrashDump.dmp"

 -e %ld –g

      設定Auto為1,在程式崩潰的時候,將啟動windbg,並將記憶體轉儲到c:/crashdump.dmp檔案中。

      開發人員拿到dmp檔案後,就可以定位問題了。

2、生成應用程式的 MAP 檔案

     先必須生成程式的 MAP 檔案。什麼是 MAP 檔案?簡單地講, MAP 檔案是程式的全域性符號、原始檔和程式碼行號資訊的唯一的文字表示方法,它可以在任何地方、任何時候使用,不需要有額外的程式進行支援。而且,這是唯一能找出程式崩潰的地方的救星。

     好吧,既然 MAP 檔案如此神奇,那麼我們應該如何生成它呢?在 VC 中,我們可以按下 Alt+F7 ,開啟“Project Settings”選項頁,選擇 C/C++ 選項卡,並在最下面的 Project Options 裡面輸入:/Zd ,然後要選擇 Link 選項卡,在最下面的 Project Options 裡面輸入: /mapinfo:lines 和 /map:PROJECT_NAME.map(或者勾選Generate m

apfile) 。最後按下 F7 來編譯生成 EXE 可執行檔案和 MAP 檔案。
     在此我先解釋一下加入的引數的含義:

     /Zd              表示在編譯的時候生成行資訊
     /map[:filename]  表示生成 MAP 檔案的路徑和檔名
     /mapinfo:lines   表示生成 MAP 檔案時,加入行資訊
     /mapinfo:exports 表示生成 MAP 檔案時,加入 exported functions (如果生成的是 DLL 檔案,這個選項就要加上)

OK,通過上面的步驟,我們已經得到了 MAP 檔案,那麼我們該如何利用它呢?參看步驟4。

3、獲取應用程式的崩潰地址

      通過用windbg分析步驟1得到的dump檔案可以獲取應用程式的崩潰地址,下面是我做的一個測試程式崩潰時的dump檔案,用windbg開啟後的最後兩行資訊:

    Test3+0x135b:
    0040135b f77de8          idiv    eax,dword ptr [ebp-18h] ss:0023:0012f87c=00000000

4、通過崩潰地址找出原始碼的出錯行

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       [email protected]@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       [email protected]   00424138     kernel32:KERNEL32.dll
0004:0000013c       [email protected]        0042413c     kernel32:KERNEL32.dll
0004:00000140       [email protected]       00424140     kernel32:KERNEL32.dll
0004:00000144       [email protected]        00424144     kernel32:KERNEL32.dll
0004:00000148       [email protected]      00424148     kernel32:KERNEL32.dll
0004:0000014c       [email protected]        0042414c     kernel32:KERNEL32.dll
0004:00000150       [email protected] 00424150     kernel32:KERNEL32.dll
0004:00000154       [email protected] 00424154     kernel32:KERNEL32.dll
0004:00000158       [email protected]    00424158     kernel32:KERNEL32.dll
0004:0000015c       [email protected]      0042415c     kernel32:KERNEL32.dll
0004:00000160       [email protected] 00424160     kernel32:KERNEL32.dll
0004:00000164       [email protected] 00424164     kernel32:KERNEL32.dll
0004:00000168       [email protected]  00424168     kernel32:KERNEL32.dll
0004:0000016c       [email protected] 0042416c     kernel32:KERNEL32.dll
0004:00000170       [email protected] 00424170     kernel32:KERNEL32.dll
0004:00000174       [email protected] 00424174     kernel32:KERNEL32.dll
0004:00000178       [email protected] 00424178     kernel32:KERNEL32.dll
0004:0000017c       [email protected] 0042417c     kernel32:KERNEL32.dll
0004:00000180       [email protected] 00424180     kernel32:KERNEL32.dll
0004:00000184       [email protected] 00424184     kernel32:KERNEL32.dll
0004:00000188       [email protected]    00424188     kernel32:KERNEL32.dll
0004:0000018c       [email protected]       0042418c     kernel32:KERNEL32.dll
0004:00000190       [email protected]   00424190     kernel32:KERNEL32.dll
0004:00000194       [email protected]       00424194     kernel32:KERNEL32.dll
0004:00000198       [email protected]       00424198     kernel32:KERNEL32.dll
0004:0000019c       [email protected]         0042419c     kernel32:KERNEL32.dll
0004:000001a0       [email protected]      004241a0     kernel32:KERNEL32.dll
0004:000001a4       [email protected]        004241a4     kernel32:KERNEL32.dll
0004:000001a8       [email protected]      004241a8     kernel32:KERNEL32.dll
0004:000001ac       [email protected] 004241ac     kernel32:KERNEL32.dll
0004:000001b0       [email protected]     004241b0     kernel32:KERNEL32.dll
0004:000001b4       [email protected]      004241b4     kernel32:KERNEL32.dll
0004:000001b8       [email protected]     004241b8     kernel32:KERNEL32.dll
0004:000001bc       [email protected]         004241bc     kernel32:KERNEL32.dll
0004:000001c0       [email protected]            004241c0     kernel32:KERNEL32.dll
0004:000001c4       [email protected]          004241c4     kernel32:KERNEL32.dll
0004:000001c8       [email protected]        004241c8     kernel32:KERNEL32.dll
0004:000001cc       [email protected]     004241cc     kernel32:KERNEL32.dll
0004:000001d0       [email protected]      004241d0     kernel32:KERNEL32.dll
0004:000001d4       [email protected] 004241d4     kernel32:KERNEL32.dll
0004:000001d8       [email protected]     004241d8     kernel32:KERNEL32.dll
0004:000001dc       [email protected]     004241dc     kernel32:KERNEL32.dll
0004:000001e0       [email protected]   004241e0     kernel32:KERNEL32.dll
0004:000001e4       [email protected]   004241e4     kernel32:KERNEL32.dll
0004:000001e8       [email protected]   004241e8     kernel32:KERNEL32.dll
0004:000001ec       [email protected]      004241ec     kernel32:KERNEL32.dll
0004:000001f0       [email protected]  004241f0     kernel32:KERNEL32.dll
0004:000001f4       [email protected]       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       [email protected]@YAXXZ              00401020 f   CrashDemo.obj

因此,發生崩潰的函式就是 [email protected]@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$ 還是有意無意間提供了很多有價值的資訊給我們的,只是我們往往不懂得怎麼利用而已……相信這樣一來,你就可以更為從容地面對“非法操作”提示了。你甚至可以要求使用者提供崩潰的地址,然後就可以坐在家中舒舒服服地找到出錯的那行,並進行修正。

是不是很爽呢? :)