[ASP.NET Debugging BuggyBits讀書筆記] Lab05 Crash

1. 在WinDbg目錄執行 adplus –crash –pn w3wp.exe –quiet

2. 在 IIS manager裏面瀏覽 CompanyInformation.aspx 頁面，在文本框內輸入字符串，點擊send。此時瀏覽器將嘗試將得不到響應，最後出現空白頁面，代表IIS進程crash了。

3. 觀察生成的dump，發現只有一個first change的mini dump，沒有full dump，沒有second-chance的dump。這代表程序在第一次出現exception的時候就crash掉了，多是一些比較嚴重的問題，好比heap corruption或者stack overflow。

4. 爲了使用adplus可以抓到first chance的full dump，咱們須要引入adplus的config文件。在從新瀏覽CompanyInformation頁面之後，在WinDbg目錄執行如下命令 adplus –pn w3wp.exe –c c:\crash.cfg

crash.cfg的內容爲：

<ADPlus> 
    <Breakpoints> 
      <NewBP> 
          <Address> Kernel32!ExitProcess </Address> 
          <Type> BP </Type> 
       </NewBP>  
       <NewBP> 
          <Address> Kernel32!TerminateProcess </Address> 
          <Type> BP </Type> 
       </NewBP> 
       <Config> 
          <Address> AllBreakpoints </Address> 
          <Actions> FullDump  </Actions> 
          <ReturnAction> QD </ReturnAction> 
       </Config>  
    </Breakpoints> 
    <Exceptions>

         <Config> 
           <Code> AllExceptions </Code> 
           <Actions1>  void </Actions1> 
           <Actions2> Log;Stack </Actions2>       
         </Config> 
         <Config> 
           <Code> AV </Code> 
           <Actions1>  Minidump </Actions1> 
         </Config> 
  </Exceptions> 
</ADPlus>   

5. 再次reproduce問題之後，抓到的first chance的crash dump的以下：

6. 使用WinDbg打開dump文件，載入SOS，執行 !clrstack

可見程序是反覆執行了Utility.WriteToLog方法和ExceptionHandler方法，最終致使棧溢出。

7. 查找程序源代碼，在ExceptionHandler.cs這個文件裏面找到以下代碼：

在Utility.cs裏面找到以下代碼：

可見程序出現問題的緣由是，兩個靜態方法，循環引用，最終致使棧溢出。

 20110222補充：

Tess原文中提到了Process被shut down的三種狀況：一是出現了2nd chance的 unhandled exception；二是進程被外部程序關閉；三是出現了嚴重的1st chance的exception致使程序被shutdown，這些exception包括heap corruption，stack overflow，fatal execution engine error和out of memory。其中進程被外部程序關閉或者出現嚴重的1st chance的錯誤致使進程退出的狀況，都屬於1st chance的狀況。咱們再進行debugging的時候，首先就是要斷定是crash屬於什麼狀況。對於這篇blog提到的狀況，斷定的邏輯以下：

1. 執行adplus -crash w3wp.exe -quiet以後，抓到的只有1st chance的dump而沒有2nd chance的dump，排除第一種狀況：unhandled exception致使進程crash。

2. 對於抓到的dump，使用WinDBG打開之後，當前活躍線程是0，執行kL獲得以下結果：

　　

　　可見這裏是ThreadStart，這個線程只是一個普通的線程，而並不是主線程。Tess的文章中提到，若是是crash的第二種緣由，外部程序將進程結束，那麼抓到的dump的活躍進程應該是主線程。而對於主線程，咱們會看到WinMain函數入口點。

0:000> kL
ChildEBP RetAddr  
0014fbfc 7d503faf ntdll!ZwTerminateProcess+0x12
0014fc38 7d503f5a kernel32!_ExitProcess+0x4b
0014fc4c 79fd9e8f kernel32!ExitProcess+0x14
0014fe74 79f7479c mscorwks!SafeExitProcess+0x157
0014ff10 79004fab mscorwks!HandleExitProcessHelper+0x27
0014ff10 79004fab mscoree!CorExitProcess+0x46
0014ff20 77bcaddb mscoree!CorExitProcess+0x46
0014ff2c 77bcaefb msvcrt!__crtExitProcess+0x29
0014ff5c 77bcaf52 msvcrt!doexit+0x81
0014ff70 01001a3c msvcrt!exit+0x11 0014ffc0 7d4e7d2a w3wp!wmainCRTStartup+0x144 0014fff0 00000000 kernel32!BaseProcessStart+0x28

　　所以，咱們能夠判斷出致使進程crash的緣由是第三種：fatal 1st chance error。對於這種狀況，咱們要對1st chance的error抓一個full user dump。

本文提到了使用adplus抓取first chance致使程序被shut down的狀況，若是要使用DebugDiag，能夠在設置rule的時候添加Kernel32!ExitProcess和Kernel32!TerminateProcess兩個斷點抓取full user dump