ASP.NET Debug系列之二 Hang調試

前幾天我翻譯了Tess debug系列的第一篇文章以及和大家介紹了一些debugger tools的基本命令。今天我們將一起討論Tess關於debug 系列的第二篇文章。Tess在每個系列中都使用了問題+結果的結構，為了簡化，我將把問題和結果一起給大家。此外，大家在自己機器上重現這些問題的時候，由於機器的差異，許多問題的結果都可能和Tess的不一樣，這個不要緊，只要大家能夠掌握原理就可以了。同時，由於blog的尺寸問題，圖片顯示的內容並不十分清晰，大家可以從Tess的連結上去找。

ASP.NET Debug系列之一：環境搭配

Windbg，sos，tinyget，adplus常用命令

1.問題重現

1.瀏覽頁面：http://localhost/BuggyBits/FeaturedProducts.aspx

大概需要5秒左右的時間來呈現這個頁面，大家也可以從頁面下腳的開始和結束時間來判斷。

2.開啟5個瀏覽器，並同時瀏覽剛才的頁面。

這裡需要注意的是，如果你幾乎同時重新整理剛才的頁面了，但並沒有看到這5個頁面上顯示相近的開始時間，那麼很有可能你沒有運行InternetConnections.reg檔案。如果沒有，雙擊它使它修改註冊表，然後重新測試。

問題1：5個頁面各自的已耗用時間是多少？

結果1：5個瀏覽器的結果分別是：1-5.0s，2-9.1s，3-12.57s，4-16.07s，5-18.61s。如果你看到每個request的時間間隔在5秒左右，那麼你很可能是沒有運行InternetConnections.reg檔案。

問題2：w3wp.exe的CPU佔用率是多少，高還是低？

結果2：非常低的CPU佔用率，只有0～5%。

問題3：對於這種低CPU佔用率的hang問題有什麼潛在原因呢？

結果3：對於這種處理request時間在不斷增加並且CPU佔用率低的情況來說一般有如下兩個原因：1)所有的request在等待一個單thread獨佔的資源，即這個資源只能被1個thread單獨使用。這樣的話，其他所有thread就需要等待。2)我們在等待一個資源，由於該資源仍未可用，導致所有需要該資源的thread阻塞。

2.擷取dump

1.開啟一個命令列視窗，並切換到debugger tools的安裝目錄。輸入以下命令，但請注意，不要立即按enter。

Adplus –hang –pn w3wp.exe –quiet

2.重新開啟一個命令列視窗，同樣切換到debugger tools目錄，使用tinyget指令碼來對頁面進行並發訪問。

tinyget -srv:localhost -uri:/BuggyBits/FeaturedProducts.aspx -threads:30 -loop:50

這個命令將啟動30個threads並發送50個requests到FeaturedProducts頁面。

3.在request仍然被發送的時候，可以在adplus視窗按enter以擷取dump檔案。

問題1：在-hang參數下，是什麼觸發dump檔案的產生呢？

結果1：這個問題有點隱蔽，dump檔案是在你運行adplus的時刻立即產生的，它不同於-crash參數。-crash參數是需要程式滿足crash的條件時才會產生dump檔案。