如何手工抓取dump文件及分析

Posted 2023-04-08

首先一种比较直观简洁的方式就是用WinDbg等
调试器直接attach到需要调试的进程，调试完毕之后再detach即可。但是这种方式有个缺点就是执行debugger命令时必须先break这个进
程，执行完debug命令之后又得赶紧F5让他继续运行，因为被你break住的时候意味着整个进程也已经被你挂起。另外也经常会由于First
Chance
Excetpion而自动break，你得时刻留意避免长时间break整个进程。所以这样的调试方式对时间是个很大的考验，往往没有充裕的时间来做仔细
分析。

另一种方式则是在出现问题的时候，比如CPU持续长时间100%，内存突然暴涨等非正常情况下，通过对服务进程snapshot抓取一个dump文件，完成dump之后先deatch，让进程继续运行。然后用windbg等工具来分析这个抓取到的dump文件。

那么如何在不终止进程的情况下抓取dump文件呢？Debugging Tools for Windows里提供了一个非常好的工具，adplus.vbs。从名字可以看出，实际上是一个vb脚本，只是对cdb调试器作的一个包装脚本。 参考技术A 不知道

使用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