windows CE應用程式異常的調試方法——轉載

無論你是一個單純的電腦使用者還是一名進階軟體工程師，都一定對程式崩潰不陌生。做為一名Windows CE應用程式開發人員，你也一定遇到過這種情境：

這個對話方塊告訴你，有一個叫installer.exe的程式在地址00019320處崩潰了。如果這個程式歸你負責，那麼你的問題就來了：怎麼找出這個BUG？這篇文章我想談談我在這方面的一些經驗。
Windows CE的崩潰介面給出的資訊十分的少，其中最有用的無疑是崩潰地址，如果你能從崩潰地址定位到原始碼去，這個問題可以說就解決了一半。
從地址定位到原始碼的方法有幾種。一種是利用MAP檔案：你可以在BUILD程式時產生MAP檔案。MAP檔案是一個文字檔，其中主要記錄了各個函數入口對應的地址資訊。比如這個例子中，崩潰地址對應的入口是：view plaincopy to clipboardprint?

1. 0001:000082f4 ??1?$CComPtr@UIImage@@@ATL@@QAA@XZ 000192f4 f i ImageViewer.obj  

0001:000082f4 ??1?$CComPtr@UIImage@@@ATL@@QAA@XZ 000192f4 f i ImageViewer.obj

MAP檔案的好處是它是文字檔，可以人工閱讀，缺點是資訊不夠多，只能定位到函數層級，而且要看懂MAP檔案你需要有足夠的經驗，比如其中那串長長的貌似亂碼的字串是C++函數經過name mangling處理後的結果，沒有一定的經驗你根本沒法還原出實際的函數。
另一種方法是利用PDB檔案，PDB檔案收集了應用程式的偵錯符號。PDB檔案提供的資訊很全，不過你得需要一定的工具才能解讀它。如果你是一個經驗豐富的Windows案頭平台的應用程式開發人員，你可能聽說過MSJ（Microsoft System Journal）這本雜誌。如果你曾經看過這本雜誌，應該對Bugslayer不陌生。在這篇文章中，Bugslayer介紹了他做的一個工具：CrashFinder。CrashFinder可以從崩潰地址通過查詢相應的PDB檔案直接定位到導致崩潰的原始碼行。幸運的是，由於Windows CE可執行程式及其PDB檔案的格式和Windows案頭系統上的是一樣的，因此CrashFinder也可以用來定位Windows CE程式的崩潰地址。下面是CrashFinder顯示的結果：

CrashFinder提供的資訊十分有用，但是不夠直觀。為此我在Remote Process Explorer提供了一個更方便的介面，它可以直接顯示原始碼，並把導致崩潰的那一行highlight出來：

PDB檔案裡包含著大量的調試資訊可以協助你診斷應用程式錯誤，因此一般來說即使是正式release的版本，你也應該產生並維護好這些PDB檔案。使用PDB檔案的關鍵是崩潰的應用程式和PDB檔案一定要匹配，否則它不但不能幫到你，反而會誤導你。是VS2005中設定產生PDB檔案和MAP檔案的地方：

前面說過，Windows CE的崩潰介面給出的資訊十分少，很多時候我們還需要更多的資訊才能定位問題，另外有些Windows CE裝置可能根本沒有顯示器。為解決這一問題，Windows CE在應用程式崩潰時還同時往外（一般是串口）輸出相關的崩潰資訊。比如這個例子中，如果你正好接著調試串口，開著HyperTerminal，那麼在程式崩潰的時候你會看到這樣的資訊：view plaincopy to clipboardprint?

1. Data Abort: Thread=8d661000 Proc=81a477c0 'installer.exe'   
2. AKY=00000401 PC=00019320(installer.exe+0x00009320) RA=00019094(installer.exe+0x0   
3. 0009094) BVA=16080100 FSR=00000007  

Data Abort: Thread=8d661000 Proc=81a477c0 'installer.exe'AKY=00000401 PC=00019320(installer.exe+0x00009320) RA=00019094(installer.exe+0x00009094) BVA=16080100 FSR=00000007

我相信Windows CE開發人員一定也對這幾行資訊很熟悉。怎麼利用這些資訊診斷程式的問題？這裡面最關鍵的資訊是PC和RA給出的地址資訊。PC就是上面提到的崩潰地址，根據這個地址用CrashFinder或者我的Remote Process Explorer裡的Crack Address介面可以定位到導致崩潰的原始碼行；RA是PC的返回地址(Return Address），根據這個地址可以找到導致崩潰的上一級函數，這個資訊也很重要，因為很多時候崩潰的原因往往是上層函數往底層函數傳遞了非法參數導致的，比如你的應用程式用一個非法的視窗類別調用MFC函數，崩潰地址在MFC函數裡面，但是出問題的地方在你的調用代碼裡。是RA地址對應的原始碼：

除了PC和RA，其他資訊也可以提供一些參考作用：BVA是ARM中的Fault Address Register（FAR），是引起Data Abort的虛擬位址，比如說你的程式試圖訪問一個非法地址裡的內容，那麼Data Abort時BVA就是這個非法地址；FSR是Fault Status Register，指明導致異常的原因，FSR的解釋可以看這裡。要注意的是Thread和Proc給出的不是Thread Id/Thread Handle或者Process Id/Process Handle，它們給出的是該Thread或Proc對應的核心對象的指標，類似於Window NT平台的TEB和PEB的概念。由於你看到崩潰資訊時線程已經退出了，因此根據這個資訊在事後你無法知道是哪個線程出的錯。以後我將介紹一種系統級的logging機制，這種機制可以把每條log的Thread Id、TEB等資訊同時記錄下來，這樣在崩潰時就可以根據Data Abort的TEB資訊和先前log中出現的TEB，找到出錯的線程。這樣，你不但可以定位到錯誤的原始碼，還能找到運行錯誤碼的線程，將大大提高解決問題的效率。

原文地址http://blog.csdn.net/singlerace/archive/2008/07/15/2655154.aspx