無論你是乙個單純的電腦使用者還是一名高階軟體工程師，都一定對程式崩潰不陌生。做為一名windows ce應用程式開發者，你也一定遇到過下圖這種場景：
這個對話方塊告訴你，有乙個叫installer.exe的程式在位址00019320處崩潰了。如果這個程式歸你負責，那麼你的問題就來了：怎麼找出這個bug？這篇文章我想談談我在這方面的一些經驗。
windows ce的崩潰介面給出的資訊十分的少，其中最有用的無疑是崩潰位址，如果你能從崩潰位址定位到源**去，這個問題可以說就解決了一半。
從位址定位到源**的方法有幾種。一種是利用map檔案：你可以在build程式時生成map檔案。map檔案是乙個文字檔案，其中主要記錄了各個函式入口對應的位址資訊。比如這個例子中，崩潰位址對應的入口是：
0001:000082f4 ??1?$ccomptr@uiimage@@@atl@@qaa@xz 000192f4 f i imageviewer.objmap檔案的好處是它是文字檔案，可以人工閱讀，缺點是資訊不夠多，只能定位到函式級別，而且要看懂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，那麼在程式崩潰的時候你會看到這樣的資訊：
data abort: thread=8d661000 proc=81a477c0 'installer.exe'
aky=00000401 pc=00019320(installer.exe+0x00009320) ra=00019094(installer.exe+0x0
0009094) 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，找到出錯的執行緒。這樣，你不但可以定位到錯誤的源**，還能找到執行錯誤**的執行緒，將大大提高解決問題的效率。
SYN Flood應如何應對
1 什麼是syn flood攻擊 在tcp三次握手時，伺服器接收客戶端的syn請求，作業系統將為該請求分配乙個tcp transmission control block 伺服器返回乙個syn ack請求，並將處於syn rcvd狀態 半開連線狀態 從以上過程可以看到，如果惡意的向某個伺服器端口傳送...
專案應如何啟動
描述 某經營鋼材產品的公司，近幾年業務得到了成倍的發展，原來採用手工處理業務的方式此時顯得力不從心。因此，經過公司董事會的決定，在公司推行一套管理軟體來替代原有的手工作業的方式，同時，請公司的副總負責此專案的啟動工作。副總接到任務後，隨即開始了專案的啟動工作。專案經過前期的一些工作後，副總任命小胡為...
如何應対syn flood
syn flood的原理就不介紹了 主要總結一下解決方法 防火牆禁ip 核心引數的調優 linux核心引數調優主要有下面三個 減小tcp synack retries 這個是三次握手中，伺服器回應ack給客戶端裡，重試的次數。預設是5。顯然攻擊者是不會完成整個三次握手的，因此伺服器在發出的ack包在...