問題背景說明：客戶的生產環境不定時發生崩潰，需要定位崩潰的原因。在開發環境不能重現該問題，准備抓取IIS的dump文件分析
第一步：在客戶的生產環境抓取dump文件
等IIS崩潰時，會自動轉存dump文件
第二步：分析dump文件
2.1 選擇在那個環境分析dump文件
一般可以選擇在生產環境分析dump文件，（如果開發環境有符號表文件，也可以把dump文件拷貝到開發環境分析）
2.2 安裝windbg
參考：wndbg下載與安裝
2.2 選擇dump文件
2.3 設置符號服務器與符號緩存
.symfix d:\symbols
符號服務器：在調試過程中，需要涉及成千上萬個符號文件，以及同一個符號文件存在不同平台下的不同符號文件版本的時候。一一手動設置符號路徑肯定是不現實的，於是引入了符號服務器的概念。符號服務器有一套命名規則，使得調試軟件能夠正確找到需要的符號文件。一般來說，符號服務器比較大，都是共用的，放在遠程主機上。為了降低網絡訪問的成本，又引入了符號緩存的概念，即將從服務器上下載到的符號文件，保存在本地緩存中，以后調試器需要符號文件的時候，先從緩存中尋找，找不到的時候再到服務器上下載。
這是一台微軟對外公開的服務器，使用http地址訪問，不是所有人都能牢記這個網址，所以最好的辦法就是使用.symfix命令(自動記憶了上面那個微軟符號服務器地址)，語法如下：
.symfix [+] [符號緩存地址]
2.4 加載sos
.loadby sos clr
2.5 分析異常
!pe
能看出來是堆棧溢出異常，接下來我們看看堆棧
!dumpstack
能看出來死循環
接下來要看一下堆棧頭部，看看是什么對象什么參數下會發生死循環
如果要查看更詳細的對象，可以用下面的命令
!dso 列出所有對象【DumpStackObjects】
!do 查看對象【DumpObj】
如果手上沒有源碼，需要分析組件的代碼
!dumpheap -mt methodTable 查看方法表
!savemodule module d:\xxx.dll
保存一個dll組件，用ilspy反編譯看一下源代碼
sos命令參考：http://blog.csdn.net/puncha/article/details/11953723