一、准备工作

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

可看出大量线程执行，都在等待一个同步锁，如下:

27  Id: 1200.1100 Suspend: 1 Teb: 7ff90000 Unfrozen
ChildEBP RetAddr  Args to Child              
10e3e998 77d36a04 760b6a36 00000001 10e3e9ec ntdll!KiFastSystemCallRet
10e3e99c 760b6a36 00000001 10e3e9ec 00000001 ntdll!ZwWaitForMultipleObjects+0xc
10e3ea38 77a4bd1e 10e3e9ec 10e3ea60 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100
10e3ea80 584745a2 00000001 7ffd7000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0
10e3eae8 584741cf 00000001 0145b748 00000000 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
10e3eb08 584742d8 00000001 0145b748 00000000 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
10e3eb8c 5847436d 00000001 0145b748 00000000 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
10e3ebdc 584744f1 00000001 0145b748 00000000 mscorwks!Thread::DoAppropriateWait+0x40
10e3ec38 58315402 ffffffff 00000001 00000000 mscorwks!CLREvent::WaitEx+0xf7
10e3ec4c 584498ea ffffffff 00000001 00000000 mscorwks!CLREvent::Wait+0x17