今天研究了一下用 windbg 來 trace aspnet_wp crash 的狀況
沒想到離開 NB ODM 之後還會用到這個 debug tool
因為整個過程真是有點複雜所以也順便紀錄一下
首先要先去下載微軟的windbg tool
他裡面有一個可以dump的小工具ADPlus
C:Program FilesDebugging Tools for Windows (x86)ADPlus.exe
直接打 adplus 就會有操作說明
我是在系統 hang 時 dump 出 aspnet_wp 這個程序的 dump file
adplus -hang -pn aspnet_wp.exe -o D:dump
再來先開啟 Windbg 並載入 dump file
這時候可能會出現跟我一樣的警告 找不到 Symbol file
請在 FileSymbol File Path 裡面輸入路徑如圖示
路徑可以隨便擺 後面MS的路徑是讓你可以直接下載Symbol回來用的
再來下指令0:000>~
這個指令會把你 dump 時所有的 thread 丟出來
以我的 dump file 來看當時有 62個 thread 在執行
可以用~*s 來切換到你要 trace 的 thread *=0,1,2….,62
切過去以後可以下 0:000>kbn 來看這個 thread 在做什麼
根據網路上的資料 由於執行時是以 stack 的方式來作
所以在看的時候要由下往上看 也就是以記憶體大的位址開始看起
不過這在寫什麼鬼是看不懂的 這時候我們可以選擇 call out 求救…..
load 進 sos.dll 的指令下法有好多種 不過我還是直接指定路徑
0:002>.load C:WindowsMicrosoft.NETFrameworkv2.0.50727sos.dll
這時如果有出現 80004005 的錯誤訊息請參考 之前這篇
現在就可以下指令來看到底 .net 在作什麼了
0:002>!clrstack
如此就能看出來 hang 住的時候你的系統到底在做什麼了
如果你跟我一樣不幸的擁有很多的 thread 可以用這個指令
0:002>!~*e!clrstack
這又可以一次把所有的 thread 都丟出來
可惜以前在debug ACPI 的時候忙到快爆了沒有順便寫一篇
可以中斷電腦的執行並 trace ACPI code 真的也是非常有趣的事情
要感謝以前在英業達的前輩 Kuo
要不是他花了很多時間教我這些 debug 的方法
我也不可能在接觸.net 不到兩個月的時間能夠堪稱"會用" windbg 來 trace aspnet_wp hang
希望正在上海出差的他可以顧好他的肝 