前幾天我翻譯了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文件。
