DUMP进程.docxVIP

dump文件在生产环境下进行故障诊断时，为了不终止正在运行的服务或应用程序，有两种方式可以对正在运行的服务或应用程序的进程进行分析和调试。首先一种比较直观简洁的方式就是用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调试器作的一个包装脚本。其路径与Debugging Tools for Windows的安装路径相同，使用的方法也很简单，如下所示:adplus.vbs -hang -p 1234 -o d:\dump其中-hang指明使用hang模式，亦即在进程运行过程中附加上去snapshot抓取一个dump文件，完成之后detach。与之对应的是-crash崩溃模式，用户先启动adplus，然后由它启动要监控的程序，在出现异常崩溃时自动生成dump文件，或者通过Ctrl-C人为发出抓取指令。但是-crash模式在抓取完成之后，被监控的进程就必须终止。因此我们在这里只选用-hang模式。-p是要调试的进程ID，比如ASP.NET应用线程池，在Win2003下就是w3wp.exe-o 指定要output的dump文件路径。另外，与adplus类似的，有个UserDump工具，但是抓取用户模式的进程，而adplus则是内核模式和用户模式两者皆可。而总所周至的Dr. Waston，则会在进程崩溃之后的自动时候抓取dump文件，一样可以用于windbg等调试器来事后分析程序崩溃时的状态。＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝0:000 !dumpheap -stat No export dumpheap found ======解决方法：.load clr20\sos.dll，你要先执行的。sos.dll在默认的c:\windows\\framework\v2.....下面，你复制到c:\program files\debugging tools for windows下面的clr20目录下面（clr20是你手工创建的） ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ 在.NET下开发时，最基本的调试方法就是使用Visual Studio的单步调试。但是对于一些特殊情况，特别是涉及到CLR内部的时候使用这种方式就达不到目的了。 如果要查看运行时内存使用情况，IL代码，CLR信息等可以使用以下两种方式： 1、使用VS2005 + sos.dll 2、使用Windbg + sos.dll 第二种方式功能更加强大，下面我就通过实际操作展示一下怎么使用这种方法得到运行时ArrayList内部的值。 有人可能会说：我直接用Visual Studio的单步调试岂不是更快？当然，这个只是一个演示，通过这个演示是为以后的高级调试打下基础 在操作之前，先熟悉一下基本知识： A、使用VS2005 + sos.dll调试 1、需要在项目-属性-调试-〉启用非托管代码调试 2、打开调试-〉窗口-〉即时 3、在即时窗口中输入 !load sos 加载调试模块 4、输入其它调试语句 B、使用Windbg + sos.dll 1、去微软的网站下载最新的Windbg 2、打开Windbg在File-〉Symbol File Path ...窗口中输入 srv*c:\symbols*/download/symbols 3、运行需要调试的程序，然后在Windbg中File-〉Attach to Process中选择刚才运行的程序 4、在出现的Command窗口中就可以输入调试语句 5、常用调试语句： lm //查看加载了哪些模块 .load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\sos.dll //加载调试模块 ld Tes