WinDbg初始体验,问题来了怎么办?


最近有一本书,虽然还没有出版本,但已经引起了很多人的关注的。那就是熊大牛(请熊力老师别生气,绝对没有恶意,是尊称)的《Windows 高效排错》。提到Windows排错,我相信有很多像我这样普通的程序员想都不敢自己能去做这件事。面对那些犹如天书般的16进制表示的内存地址,二进制表示的代码,和数目繁多的数据对象。我们一看都会把它当成是乱码了,更别提去了解它了。但当我们遇到,无休止的内存溢出,程序阻塞,CPU 100%时候,我们又都手足无措。我们在怀疑,自己的代码写的有问题?.NET的垃圾回收有BUG?程序的压力巨大,或许它本来就应该是这样的?当我们没有能力为我们的程序出现的问题找到合理解释的时候,我们能做什么呢?给IIS设置一个最大内存使用限制,或定时重启一下IIS吧。可是当你们程序每20分钟重启一起后,你才会发现,问题的严重性...

这时,我们就应该意识到,不是别人的错,是我们程序本身的问题。但当你面对你亲手所生产出来的代码,你非常自信,没有文件操作,没有非拖管资源的释放问题,没有大量的数据缓存。这时候我们又非常的不自信,我们不知道该从哪里下手,面对这风格几近统一的代码,我们找不到突破口,我们迷茫,我们失落,我们能做些什么?

熊力老师的《Windows 高效排错》文章,告诉我们,我们能够自己亲手解决我们自己的问题,给自己一个合理的解释。我们只要需要几步就能解决我们的实际问题:

1.知道怎么捕捉dump文件

2.知道如何简单使用WinDbg

3.知道如何使用dump命令(不知道称呼是否正确),按照《不是我舍不得 - .NET里面的Out Of Memory》介绍的步骤来分析内存。

4.你具有一定.NET原理性知识,能够分析你所看到的现象。

那么什么是dump文件呢,我也不知道该给什么样的解释。据我直观体验,它就是当存指定进程的内存详细信息,包括线程,内存地址和数据等等很多东西全部都给写到一个文件里面,这里指的是FullDump。dump文件还可以分为hang和crash,分别可以分析不同类型的程序错误。这里并不会解释很多的名词,这些名词大部分我也都不是很懂,留着给专家来解释吧。

第一步,我们要来捕捉dump文件。你首先要安装一个WinDbg软件,在这个软件下,带有一个adplus.vbs文件。利用这个文件我们可以在服务器上捕捉dump文件了。大致的命令格式可以参考WinDbg的帮助文档,这里我是这样使用这个命令的。

adplus -Crash -p 进程ID(或-IIS) -quiet -fullonfirst -o C:\dumps

-Crash:表示我捕捉的是一个Crash dump。

-p:指定要捕捉的进程ID。 -IIS表示我们捕捉IIS的所有进程。

-quiet:不弹出提示窗口

-fullonfirst:表示我希望在first chance时捕捉完整的dump信息,也就是进程的所有完整信息。

-o :后面跟着dump文件的存放路径。

这样的一个命令,就能让我们得到需要的dump文件了。

接下来就是如何使用WinDbg,打开WinDbg,在File菜单选择Open Crash Dump,可以打开一个Crash dump文件。在之后弹出的窗口的最下面的输入框就是输入和执行命令的地方了。由于我们要调试.NET程序,用到的很多命令都在SOS.dll里面。这时我们就需要执行:.load C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\SOS.dll 来加载这个程序集,从而才能顺利的执行我们之后要使用的命令。

后面的工作,就是开始分析dump文件了。其实就单单分析OutOfMemory异常,步骤还是比较简单的。目前大部分命令我都还不懂是什么意思。但我按照《不是我舍不得 - .NET里面的Out Of Memory》的步骤也已经能很好的解决我的问题了,但是这要有一个前提。你必须具有分析你看到的异常的能力,这个前提很重要。如果你没法分析,即使你看到了现象,也无法分析出本质。

接下来,还会有两篇后续文章来介绍我分析程序出现问题的地方和原因,从而使用我的程序得到完美的性能改善。使原来20分钟就能窜到1.2G的程序,到目前稳定运行于300M以内。原来这样才是最真实的!

 相关链接:

WinDbg初始体验2,抓住不放的恶棍

WinDbg初始体验3,剪不断的链条

阿不

最新文章