学习Tess的Windbg调试：（一）线程Hang住分析
一、准备工作
1、下载例子：BuggyBits.zip
使用IIS将下载的下来的站点架设起来。访问下主页，确保网站正常运行。
本地可以使用主机头+HOST表，建立虚拟域名，比如：www.buggybits.com
2、下载并发测试工具：IIS6 资源工具
对于本实验，该资源工具安装时，只需要勾选安装TinyGet工具。
二、模拟网站Hang住的状态
1、请求地址：http://www.buggybits.com/FeaturedProducts.aspx
查看网站底部：
[start time: 11:59:54] [execution time: 5.161 seconds]
2、同时开启5个浏览器窗口，同时访问该网页，并查看任务管理，查看w3wp.exe进程的CPU。页面执行完成后，查看各网页底部执行的时间：
应该是每个页面都差不多有4-5秒的递增。但在页面请求过程中，CPU却使用率依然很低。
由此可以推断，程序同步过程中，有大量线程在等着同一个锁的释放。
三、抓取DUMP包
1、准备好windbg的抓包脚本：
运行一个Command，并将目录定位到windbg安装目录，输入下面脚本，但不立即运行：
adplus –hang –pn w3wp.exe –quiet
2、使用TinyGet模拟并发请求：
再运行一个Command，并将目录定位到TinyGet的安装目录，运行以下脚本：
tinyget -srv:www.buggybits.com -uri:/FeaturedProducts.aspx -threads:30 -loop:50
如下图：
现在已有30个线程，做50次并发请求。
3、抓包：
运行步骤1 所准备下的脚本。
此时，若包无法抓下，可使用windbg直接附加到w3wp.exe去做分析。
四、分析DUMP包
1、输入~* kb 2000 查看本地资源的callstack
可看出大量线程执行，都在等待一个同步锁，如下:
由此可知，在获取同步锁后，线程确实sleep了5秒。
到此，整个线程Hang的分析已全部完成。
