專利名稱：對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法
技術領域：
本發(fā)明涉及計算機軟件系統(tǒng)維護領域，尤其涉及一種對計算機軟件系統(tǒng)崩潰原因
進行自動分析的方法。
背景技術：
計算機的軟件系統(tǒng)在運行過程中，會因為各種未知因素而產(chǎn)生異常，最終造成應 用程序崩潰或操作系統(tǒng)藍屏，崩潰分析技術是指，對軟件系統(tǒng)運行出錯后生成的崩潰轉儲 文件(dump)進行分析和統(tǒng)計，并從中找出崩潰發(fā)生時的地址及其相關代碼行，從而為解決 軟件系統(tǒng)故障提供可信的依據(jù)。目前大多數(shù)已知的崩潰分析僅僅實現(xiàn)了崩潰文件的收集和 異常點的統(tǒng)計(利用的是軟件系統(tǒng)崩潰時候的異常指針實現(xiàn))，而且均未提供針對系統(tǒng)藍 屏以后的內(nèi)核態(tài)崩潰轉儲文件的分析功能。

發(fā)明內(nèi)容
本發(fā)明的目的是克服現(xiàn)有技術中的不足，提供一種對計算機軟件系統(tǒng)崩潰原因進 行自動分析的方法，使用該方法可以自動對崩潰轉儲文件進行分析，并且獲取崩潰函數(shù)和 崩潰模塊，進而獲知多項具體的崩潰信息，便于對各種不同崩潰信息的統(tǒng)計。
為了實現(xiàn)上述目的，采用以下技術方案 對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其包括如下步驟
a、打開崩潰轉儲文件； b、分別檢索每個處理器每個線程的堆棧信息，對于用戶態(tài)崩潰轉儲文件尋找用戶 態(tài)的異常錯誤觸發(fā)函數(shù)；對于內(nèi)核態(tài)崩潰轉儲文件尋找內(nèi)核態(tài)的異常錯誤觸發(fā)函數(shù)；
c、根據(jù)搜索到的異常錯誤觸發(fā)函數(shù)，檢查異常發(fā)生時刻的上一個調(diào)用函數(shù)，如果 這個調(diào)用函數(shù)是一個有效的函數(shù)名，則暫定該調(diào)用函數(shù)為崩潰函數(shù)，把該調(diào)用函數(shù)隸屬的 模塊暫定為崩潰模塊； d、根據(jù)獲得的崩潰函數(shù)和崩潰模塊獲取崩潰信息，并將崩潰信息存儲至數(shù)據(jù)庫。 進一步的技術方案是， 在步驟a和步驟b之間還包括步驟al : al 、給崩潰轉儲文件進行唯一命名。 再進一步的技術方案是， 在步驟al和步驟b之間還包括步驟a2 : a2、加載調(diào)試符號文件。 上述方法利用Windows操作系統(tǒng)提供的調(diào)試機制，自動對崩潰轉儲文件中保存的
崩潰發(fā)生時的內(nèi)存數(shù)據(jù)進行分析，并回溯出函數(shù)調(diào)用序列、寄存器數(shù)值、崩潰發(fā)生時加載的
模塊信息、崩潰發(fā)生的地址信息及其相關系統(tǒng)，從中找出導致崩潰發(fā)生的原因，可以為后續(xù)
的軟件故障分析及軟件質量評估提供可信的依據(jù)。本發(fā)明方法的主要優(yōu)點為 1、基于Windows調(diào)試技術技術，把一系列的分析流程自動化，并根據(jù)分析結果進行自動取舍，智能選取分析操作命令，有效的解決了崩潰轉儲分析中對操作人員的技術要 求過高的問題。 2、支持一系列的崩潰分析規(guī)則，根據(jù)不同的崩潰流程，使用不同的規(guī)則進行分析。
3、支持針對系統(tǒng)藍屏以后的內(nèi)核態(tài)崩潰轉儲文件的分析能夠直接定位到具體的 崩潰函數(shù)、代碼行號、崩潰現(xiàn)場的堆棧數(shù)據(jù)等內(nèi)容。
具體實施例方式
本發(fā)明的方法的原理是基于Windows調(diào)試技術及其相應的調(diào)試API。 Windows調(diào)
試技術內(nèi)置在操作系統(tǒng)內(nèi)核里面，對外提供了一系列的Windows API和組件包。本發(fā)明利
用了 Windows調(diào)試技術提供的組件包Debugging Tools for Windows (以下簡稱WinDBG)
里面提供的Windows調(diào)試引擎，對崩潰轉儲文件進行自動的分析。本發(fā)明方法本身針對的
對象是崩潰轉儲文件。崩潰轉儲文件的生成方法主要有以下一些 參Windows錯誤報告機制 MiniD卿WriteD卿Windows API 參讀取崩潰進程的內(nèi)存 參應用程序調(diào)試器 利用上述方法生成崩潰轉儲文件以后，就可以利用下面介紹的方法進行崩潰轉儲 的分析過程了。 對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其包括如下步驟
a、打開崩潰轉儲文件，檢查文件的合法性和有效性；
al、給崩潰轉儲文件進行唯一命名以便后續(xù)文件的管理； a2、加載調(diào)試符號文件；調(diào)試符號文件是將被調(diào)試程序的二進制信息與源程序代 碼聯(lián)系起來的橋梁，調(diào)試符號文件中記錄了變量、類型、函數(shù)定義、源代碼行等信息。
a3、檢查崩潰發(fā)生時刻的軟件運行環(huán)境，對于x64系統(tǒng)，如果運行在WoW64環(huán)境下， 則進行32位-64位運行環(huán)境切換，否則不進行環(huán)境切換。 b、分別檢索每個處理器每個線程的堆棧信息，對于用戶態(tài)崩潰轉儲文件尋找用戶 態(tài)的異常錯誤觸發(fā)函數(shù)；對于內(nèi)核態(tài)崩潰轉儲文件尋找內(nèi)核態(tài)的異常錯誤觸發(fā)函數(shù)；如果 沒有找到異常錯誤觸發(fā)函數(shù)，跳轉到步驟c2。 c、根據(jù)搜索到的異常錯誤觸發(fā)函數(shù)，檢查異常發(fā)生時刻的上一個調(diào)用函數(shù)，如果 這個調(diào)用函數(shù)是一個有效的函數(shù)名，則暫定該調(diào)用函數(shù)為崩潰函數(shù)，把該調(diào)用函數(shù)隸屬的 模塊暫定為崩潰模塊； cl、如果步驟c找到的崩潰模塊或者崩潰函數(shù)屬于信任模塊列表，那么繼續(xù)檢查 步驟b中搜索到的異常錯誤觸發(fā)函數(shù)所在崩潰發(fā)生線程的再上一個調(diào)用函數(shù)，直到所檢查 到的調(diào)用函數(shù)及其所在的模塊為非信任模塊，把這個最后檢查到的函數(shù)定為崩潰函數(shù)，該 崩潰函數(shù)隸屬的模塊記為崩潰模塊。所說的信任模塊列表中包含多個信任模塊，這些信任 模塊是指編程人員認為可以確定為不可能是導致系統(tǒng)崩潰的模塊；如果該過程結束后沒有 找到崩潰函數(shù)，轉到步驟c3 ;如果找到崩潰函數(shù)，進入步驟d。 c2、根據(jù)寄存器的值獲得崩潰地址、異常錯誤代碼，然后根據(jù)崩潰地址，利用 Windows調(diào)試引擎提供的API和命令對崩潰轉儲文件進行原始調(diào)用棧分析，獲取最近的崩潰模塊和最近的一個調(diào)用函數(shù)，并把最近的一個調(diào)用函數(shù)記為崩潰函數(shù)，把這個函數(shù)隸屬 的模塊記為崩潰模塊；如果該過程結束后沒有找到崩潰函數(shù)，轉到步驟c3 ;如果找到崩潰 函數(shù)，進入步驟d。 c3、對崩潰時候的崩潰地址進行反匯編，檢查是否存在可以標識出崩潰函數(shù)的信 息，如果該過程結束后沒有找到崩潰函數(shù)，轉到步驟c4 ;如果找到崩潰函數(shù)，進入步驟d。
c4、那么將崩潰函數(shù)記錄為未找到狀態(tài)，把崩潰模塊記錄為異常發(fā)生時刻線程所 屬的模塊。 d、根據(jù)獲得的崩潰函數(shù)和崩潰模塊獲取崩潰信息，并將崩潰信息存儲至數(shù)據(jù)庫。
目前已知用戶態(tài)的異常錯誤崩潰觸發(fā)函數(shù)如下，并會根據(jù)操作系統(tǒng)的更新而不斷 的改變 kernel32. dll提供的UnhandledExc印tionFilter函數(shù)、kernel32. dll提供 的FatalAppExitW函數(shù)、ke潔132. dll提供的FatalAppExitA函數(shù)、ke潔132. dll提供 的RaiseException函數(shù)、kernelbase. dll提供的RaiseException函數(shù)、ntdll. dll提 供的NtRaiseHardError函數(shù)、ntdll. dll提供的NtRaiseExc印tion函數(shù)、ntdll. dll提 供的KiUserExc印tionDispatcher函數(shù)、CxxThrowExc印tion函數(shù)、ntdll. dll提供的 TppExc印tionFilter函數(shù)、ntdll. dll提供的TppWorkerpI騰rExc印tionFilter函數(shù)、 except—handler函數(shù)、exc印t—handler2函數(shù)、exc印t—handler3函數(shù)、report—failure函 目前已知內(nèi)核態(tài)的異常錯誤崩潰觸發(fā)函數(shù)如下，并會根據(jù)操作系統(tǒng)的更新而不斷 的改變Windows內(nèi)核提供的KeBugCheck、 KeBugCheckEx、 KeBugCheckEx2、 KiTrap、
DbgBreakPoint、 DbgUserBreakPoint、 ExpRaiseHardError、 ExpSystemErro:rHandle:r、
PoShutdownBugcheck、 KeBugCheck、 KiBugCheck函數(shù)。
步驟d中所述崩潰信息包括下列信息中的至少一種； 1)崩潰發(fā)生時間； 2)操作系統(tǒng)； 3)處理器數(shù)目和類型； 4)崩潰上下文進程名字； 5)崩潰模塊名字； 6)異常代碼和異常原因； 7)崩潰的指令地址和模塊偏移地址； 8)崩潰模塊路徑信息； 9)崩潰模塊文件版本信息、產(chǎn)品版本信息等能夠標識文件屬性的信息；
10)崩潰發(fā)生時候的各線程堆棧信息；
11)寄存器信息； 12)以及其他有助于進行崩潰統(tǒng)計的信息。 其中，第l)-3)中崩潰信息可以從崩潰轉儲文件中獲得，而其他崩潰信息則需要 在獲取崩潰函數(shù)和崩潰模塊后才能獲得。 上述步驟c2的具體過程是，利用調(diào)試引擎命令和API，獲取崩潰線程的EBP寄存器指向的棧地址，然后利用調(diào)試引擎命令和API枚舉原始調(diào)用棧信息，得出形如下面的列表
0239ff08 0239ff48
kernel32 ! He即Free+0x14












0239fef8 0239ffl0 0239ffl4 0239ffl8 0239fflc 0239ff20 0239ff24 0239ff28 0239ff2c 0239ff30 0239ff34 0239ff38 0239ff3c
75e79a26 01f4000Q
01ae4c08 582b040a 01af2868 01f425a8 0239ff80
kavevent+0x4c08
kavevent+0x12868
01ae5a53 0239ff70
kavevent+0x5353
然后從上到下，逐行檢測是否有模塊名稱(模塊名稱形如kernel32 ! HeapFree+0x14)，如果有，則檢查這個模塊是否是信任模塊，如果是，則繼續(xù)檢查下一行。如 果不是信任模塊，那么最先找到的一個模塊就是崩潰模塊，這個模塊的偏移地址就是崩潰 地址。 下面分別針對內(nèi)核態(tài)轉出文件和用戶態(tài)轉儲文件進行示例講解。
內(nèi)核態(tài) 我們會檢查callstack里面類似nt ! KeBugCheck(內(nèi)核態(tài)的異常錯誤觸發(fā)函數(shù)) 的函數(shù)，例如下面的nt ! KeBugCheckEx，如果發(fā)現(xiàn)有這個函數(shù)，那么我們會往下檢查堆棧 調(diào)用， 00 ae9c01d8 8054c583 000000c2 00000007 00000cd4nt ! KeBugCheckEx+Oxlb 01 ae9c0228 ba623392 e39c8428 ExFreePoolWithTag+0x2a3 02 ae9c0244 ba6230f8 e3a89008 c0000001 DeleteProcessObject+0x52[e:\build\src\kavprocessm. c@1416]
03 ae9c0254 ba623肌0 e3a89008 e3a89008 KxEReleaseProcessObject+0x58
[e:\build\src\kavprocessm. c@1308]
04 ae9c0268 ba623d96 00000d90 KxERemoveProcessObject+Oxb0
[e:\build\src\kavprocessm. c@1791]
05 ae9c02b0 ba7481bl rocessNotifyRoutine+0x276
[e:\build\src\kavprocessm. c@1953]
00000000 OOOOOOOOnt !
ae9c0268kavpm !
01000064kavpm !
ba752e00kavpm ! KxECreateP
06 ae9c02c8 805d2b60 00000d90 OOOOOdbO OOOOOOOOkavuty ! StubCreat
eProcessNotifyRoutine+0x61 [e:\build\build\src\kavutynr. c船O] 07 ae9c02ec 805d3672 00000001 00000008 87ff7cd0nt ! PspExitProcess+0x5e 例如上面的第OO行，觸發(fā)了一個異常函數(shù)nt ! KeBugCheckEx，那么我們會檢索 后面的堆棧調(diào)用，由于nt模塊屬于信任模塊，所以01行被忽略，檢查02行的時候，kavpm 屬于非信任模塊，因此kavpm被記做崩潰模塊，kavpm里面的DeleteProcessOb ject函數(shù)被 記做崩潰函數(shù)。崩潰地址為kavpm! DeleteProcessOb ject+0x52。對應的具體代碼行是 e:\build\src\kavprocessm. c文件的第1416行代碼。nt是nt內(nèi)核的縮寫，在不同的環(huán)境 下面可會g是ntosktrnl. exe、 ntkrnlmp. exe等不同的文件名。在內(nèi)核態(tài)里面，除了常見的KeBugCheck、 KeBugCheckEx、 KeBugCheckEx2、 KiTr即 等常見的異常錯誤觸發(fā)函數(shù)，還有類似的一些變形，例如KiTr即OO等。
用戶態(tài) 崩潰轉儲里面的callstack形如下面的樣子，kernel32 ! RaiseExc印tion是一 個異常錯誤觸發(fā)函數(shù)，而調(diào)用RaiseExc印tion的也是一個在列表里面的異常錯誤觸發(fā)函 數(shù)—CxxThrowExc印tion。我們枚舉的時候，會把00行和01行過濾掉，然后發(fā)現(xiàn)02行是 kastraydll不是信任模塊，因此記做崩潰模塊，由于崩潰模塊缺乏符號文件，因此無法定位 函數(shù)名和代碼行，只能給出崩潰的偏移地址kastraydll+0x2acd7 00 016c56e8 01548e69 e06d7363 00000001 00000003kernel32 ! RaiseExc印tion+0x53 01 016c5720 0144acd7 016c5734 0145bad4 01435c2amsvcr80—1520000 ! —CxxThrowExc印tion+0x46 [f:\sp\vctools\crt_bld\self_x86\crt\prebuild\eh\throw. cpp@161] 02 016c572c 01435c2a 8007000e 01435c64
OOOOOOOOkastraydll+0x2acd7 03 016c5730 8007000e 01435c64 00000000 016c577ckastraydll+0xl5c2a04 016c5734 01435c64 00000000 016c577c 016cfddc 0x8007000e05 016c5738 00000000 016c577c 016cfddc
01466758kastraydll+0xl5c64 以上實施例僅用以說明而非限制本發(fā)明的技術方案。不脫離本發(fā)明精神和范圍的 任何修改或局部替換，應涵蓋在本發(fā)明的權利要求范圍當中。
權利要求
對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，包括如下步驟a、打開崩潰轉儲文件；b、分別檢索每個處理器每個線程的堆棧信息，對于用戶態(tài)崩潰轉儲文件尋找用戶態(tài)的異常錯誤觸發(fā)函數(shù)；對于內(nèi)核態(tài)崩潰轉儲文件尋找內(nèi)核態(tài)的異常錯誤觸發(fā)函數(shù)；c、根據(jù)搜索到的異常錯誤觸發(fā)函數(shù)，檢查異常發(fā)生時刻的上一個調(diào)用函數(shù)，如果這個調(diào)用函數(shù)是一個有效的函數(shù)名，則暫定該調(diào)用函數(shù)為崩潰函數(shù)，把該調(diào)用函數(shù)隸屬的模塊暫定為崩潰模塊；d、根據(jù)獲得的崩潰函數(shù)和崩潰模塊獲取崩潰信息，并將崩潰信息存儲至數(shù)據(jù)庫。
2. 根據(jù)權利要求1所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，所述用戶態(tài)異常錯誤觸發(fā)函數(shù)包括kernel32. dll提供的UnhandledExc印tionFilter函數(shù)、kernel32. dll提供的FatalAppExitW函數(shù)、kernel32. dll提供的FatalAppExitA函數(shù)、kerne132. dll提供的RaiseExc印tion函數(shù)、kernelbase. dll提供的RaiseExc印tion函數(shù)、ntdl1. dll提供的NtRaiseHardError函數(shù)、ntdl1. dll提供的NtRaiseExc印t ion函數(shù)、ntdll. dll提供的KiUserExc印tionDispatcher函數(shù)、CxxThrowExc印tion函數(shù)、ntdl1. dll提供的TppExc印tionFilter函數(shù)、ntdl1. dll提供的TppWorkerpI騰rExc印tionFilter函數(shù)、exc印t—handler函數(shù)、exc印t—handler2函數(shù)、exc印t—handler3函數(shù)、r印ort—failure函數(shù)。
3. 根據(jù)權利要求1所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，所述內(nèi)核態(tài)異常錯誤觸發(fā)函數(shù)包括Windows內(nèi)核提供的KeBugCheck、 KeBugCheckEx、KeBugCheckEx2、 KiTr鄰、DbgBreakPoint、 DbgUserBreakPoint、 ExpRaiseHardError、ExpSystemErrorHandler、 PoShutdownBugcheck、 KeBugCheck、 KiBugCheck函數(shù)。
4. 根據(jù)權利要求1至3中任意一項所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟a和步驟b之間還包括步驟al :al、給崩潰轉儲文件進行唯一命名。
5. 根據(jù)權利要求4所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟al和步驟b之間還包括步驟a2 :a2、加載調(diào)試符號文件。
6. 根據(jù)權利要求5所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟a2和步驟b之間還包括步驟a3 :a3、檢查崩潰發(fā)生時刻的軟件運行環(huán)境，對于x64系統(tǒng)，如果運行在WoW64環(huán)境下，則進行32位-64位運行環(huán)境切換，否則不進行環(huán)境切換。
7. 根據(jù)權利要求6所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟c和步驟d之間還包括步驟cl :cl、如果步驟c找到的崩潰模塊或者崩潰函數(shù)屬于信任模塊列表，那么繼續(xù)檢查步驟b中搜索到的異常錯誤觸發(fā)函數(shù)所在崩潰發(fā)生線程的再上一個調(diào)用函數(shù)，直到所檢查到的調(diào)用函數(shù)及其所在的模塊為非信任模塊，把這個最后檢查到的函數(shù)定為崩潰函數(shù)，該崩潰函數(shù)隸屬的模塊記為崩潰模塊。
8. 根據(jù)權利要求1至3中任意一項所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟c和步驟d之間還包括步驟c2 :c2、如果沒有找到異常錯誤觸發(fā)函數(shù)，則根據(jù)寄存器的值獲得崩潰地址、異常錯誤代碼，然后根據(jù)崩潰地址，利用Windows調(diào)試引擎提供的API和命令對崩潰轉儲文件進行原始調(diào)用棧分析，獲取最近的崩潰模塊和最近的一個調(diào)用函數(shù)，并把最近的一個調(diào)用函數(shù)記為崩潰函數(shù)，把這個函數(shù)隸屬的模塊記為崩潰模塊。
9. 根據(jù)權利要求8所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟c2和步驟d之間還包括步驟c3 :c3、如果步驟c2中未找到崩潰函數(shù)，則對崩潰時候的崩潰地址進行反匯編，檢查是否存在可以標識出崩潰函數(shù)的信息。
10. 根據(jù)權利要求9所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟c3和步驟d之間還包括步驟c4 :c4、如果步驟c3還未找到崩潰函數(shù)，那么將崩潰函數(shù)記錄為未找到狀態(tài)，把崩潰模塊記錄為異常發(fā)生時刻線程所屬的模塊。
11. 根據(jù)權利要求7所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，在步驟cl和步驟d之間還包括步驟c5 :C5、如果步驟cl中未找到崩潰函數(shù)，則對崩潰時候的崩潰地址進行反匯編，檢查是否存在可以標識出崩潰函數(shù)的信息。
12. 根據(jù)權利要求1或2或3所述的對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其特征在于，步驟d中所述崩潰信息包括下列信息中的至少一種；1) 崩潰發(fā)生時間；2) 崩潰上下文進程名字；3) 崩潰模塊名字；4) 操作系統(tǒng)；5) 處理器數(shù)目和類型；6) 異常代碼和異常原因；7) 崩潰的指令地址和模塊偏移地址；8) 崩潰模塊路徑信息；9) 崩潰模塊文件版本信息、產(chǎn)品版本信息等能夠標識文件屬性的信息；10) 崩潰發(fā)生時候的各線程堆棧信息；11) 寄存器信息。
全文摘要
本發(fā)明涉及一種對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法。對計算機軟件系統(tǒng)崩潰原因進行自動分析的方法，其包括如下步驟a、打開崩潰轉儲文件；b、分別檢索每個處理器每個線程的堆棧信息，對于用戶態(tài)崩潰轉儲文件尋找用戶態(tài)的異常錯誤觸發(fā)函數(shù)；對于內(nèi)核態(tài)崩潰轉儲文件尋找內(nèi)核態(tài)的異常錯誤觸發(fā)函數(shù)；c、根據(jù)搜索到的異常錯誤觸發(fā)函數(shù)，檢查異常發(fā)生時刻的上一個調(diào)用函數(shù)，如果這個調(diào)用函數(shù)是一個有效的函數(shù)名，則暫定該調(diào)用函數(shù)為崩潰函數(shù)，把該調(diào)用函數(shù)隸屬的模塊暫定為崩潰模塊；d、根據(jù)獲得的崩潰函數(shù)和崩潰模塊獲取崩潰信息，并將崩潰信息存儲至數(shù)據(jù)庫。上述的優(yōu)點是可實現(xiàn)對軟件系統(tǒng)崩潰原因的自動分析。
文檔編號G06F11/36GK101719090SQ20091021434
公開日2010年6月2日 申請日期2009年12月25日 優(yōu)先權日2009年12月25日
發(fā)明者張康宗, 張強, 羅勇, 鄭有勝 申請人:珠海市君天電子科技有限公司