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