使用windbg分析iis崩溃的一个实例

问题背景说明：客户的生产环境不定时发生崩溃，需要定位崩溃的原因。在开发环境不能重现该问题，准备抓取IIS的dump文件分析

第一步：在客户的生产环境抓取dump文件

参考：IIS崩溃时自动抓取Dump

等IIS崩溃时，会自动转存dump文件

第二步：分析dump文件

2.1  选择在那个环境分析dump文件

一般可以选择在生产环境分析dump文件，（如果开发环境有符号表文件，也可以把dump文件拷贝到开发环境分析）

2.2 安装windbg

参考：wndbg下载与安装

2.2 选择dump文件

2.3 设置符号服务器与符号缓存

.symfix d:\symbols

符号服务器：在调试过程中，需要涉及成千上万个符号文件，以及同一个符号文件存在不同平台下的不同符号文件版本的时候。一一手动设置符号路径肯定是不现实的，于是引入了符号服务器的概念。符号服务器有一套命名规则，使得调试软件能够正确找到需要的符号文件。一般来说，符号服务器比较大，都是共用的，放在远程主机上。为了降低网络访问的成本，又引入了符号缓存的概念，即将从服务器上下载到的符号文件，保存在本地缓存中，以后调试器需要符号文件的时候，先从缓存中寻找，找不到的时候再到服务器上下载。

　这是一台微软对外公开的服务器，使用http地址访问，不是所有人都能牢记这个网址，所以最好的办法就是使用.symfix命令(自动记忆了上面那个微软符号服务器地址)，语法如下：

.symfix [+] [符号缓存地址]

2.4 加载sos

.loadby sos clr

2.5 分析异常

!pe

能看出来是堆栈溢出异常，接下来我们看看堆栈

!dumpstack

能看出来死循环

接下来要看一下堆栈头部，看看是什么对象什么参数下会发生死循环

如果要查看更详细的对象，可以用下面的命令

!dso 列出所有对象【DumpStackObjects】

!do 查看对象【DumpObj】

如果手上没有源码，需要分析组件的代码

!dumpheap -mt methodTable 查看方法表
!savemodule module d:\xxx.dll

保存一个dll组件，用ilspy反编译看一下源代码

sos命令参考：http://blog.csdn.net/puncha/article/details/11953723