藉助 windbg 調試 控制代碼泄漏

 在做一個大工程的時候, 什麼問題都有可能碰得上. 鬱悶的是, 項目是多人合作的, 你無法確定問題出在誰的身上.
最近就遇上一例.

描述:
引擎exe,運行10多分鐘後, 自動結束. 我靠, 退的悄聲無息的. 甚至連個windows抱歉的介面都不彈出來.

分析:
1: 關於程式悄聲無息退出的問題
    一個程式出錯, 一般都是windows很抱歉, 進程要關閉啥的, 問你要不要調試. 這次進程居然屁都不放一個就say88了.中間肯定有問題.
   進程出錯, 一般windows都會產生響應的dump檔案(記憶體轉儲),以供調試分析用. 而且如果指定了調試工具, 會提示調用相應的工具調試, 比如vs2005. 不同的電腦有不同的設定. 當時xEye是運行在小主機上的, 沒有安裝vs2005, 自然也沒有提示調試.
  但是, 我想, 一定有dump悄悄的產生了. 一般情況下, 這個在程式崩潰的時候, 產生dump的任務是drwtsn32.exe這個工具負責的. 為什麼這個工具知道進程出問題了都不提示一下呢? 改改設定看看.
  運行=>drwtsn32=>選中視覺通知, 選中聲音通知,選中損毀傾印檔案.
  ok, 下次程式再崩掉的時候, drwtsn就會提示你了.

（2009-06-29日補充：多線程導致的問題，會讓程式悄然退出！vs2005都拿其沒則！崩潰線程任何有價值的資訊都沒有！後來發現，是線程間通訊的資料結構不一致導致的！）

2:為什麼程式會跑一段時間就退出?
  老聶同志發現xEye存在嚴重的控制代碼泄漏問題. 難道是此問題?
  通過工作管理員=>選擇列=>可以顯示進程的開啟的控制代碼書, xEye的控制代碼以每秒100個的速度狂長.
  通過process explorer(微軟的)工具, 查看xEye開啟的控制代碼, 發現不斷增加的是Event handle.
  但是代碼裡面沒有CreateEvent()函數.
  問題處在哪裡呢?

  請出windbg幫忙.
  固然不負重望. 通過一個視頻教程裡面示範用windbg檢測控制代碼泄漏, 很快定位出是easyusb.dll的問題. 我靠. 這個原來是外來的動態庫的問題.(此問題彤哥通過本方法,一個工程一個工程的替換, 也發現了是easyusb.dll的問題, 但是效率甚低)

2、windbg調試
1）找到windbgs安裝目錄下的gflags.exe工具，該工具可用來開啟windows內建的一些調試選項，具體gflags.exe的詳細使用可以查看windbg協助； 這裡我們設定勾上application verifiwer，該工具主要可用來對程式做一些穩定性的檢測，本次調試主要用於儲存棧的相關資訊。同時設定stack backtrace即棧的大小為10.
2）運行windbg，開啟第一步編譯的程式，並使其跑起來；此時你查看工作管理員中的控制代碼資訊，會發行相應進程控制代碼一直在增加。
3）windbg用ctrl+break命令中斷進程運行，用！htrace -enable命令開啟控制代碼檢測；htrace提供了進行控制代碼相關檢測的命令，可查看windbg協助。 同時用g命令讓程式運行。
4）再次中斷進程，使用！htrace -snapshot命令，獲得此時進程控制代碼的鏡像。並再次讓程式運行。
5）第三次中斷進程運行，我們再使用！htrace -diff命令獲得當前控制代碼狀態與第4步 snapshot鏡像控制代碼的差異； 我們可以發現：新增很多開啟的控制代碼，平常情況下這些開啟的控制代碼有可能不是泄露，需要具體分析，但是本次樣本程式太簡單，所以剛好所有開啟的控制代碼都屬於泄露的。
6）我們使用lsa 傳遞指定位置對應的代碼，lsa handlew2!fun4+0x0000002e 到這裡，我們就找到了泄露控制代碼的函數。
參考：
http://hi.baidu.com/firefly_only/blog/item/76f50e22945b9b5b9922ed6c.html

   ok. 修複之.

   現在控制代碼泄漏的問題搞定了, 但是進程還是跑一會就退出了!!!

   後來發現進程存在 棧溢出. 通過cdb(windbg的兄弟)很快也搞定了, 仍然是easyusb.dll問題. 如果僅查看異常時的呼叫堆疊, 會以為是classifying.dll的問題呢. 關於解決堆疊溢位的問題, 另有一片日誌有記錄.
　最後發現是底層驅動的問題．　ok, 這個話題扯遠了, 非我輩能玩的起的了, 交給他們處理了.