最近有一本书，虽然还没有出版本，但已经引起了很多人的关注的。那就是熊大牛（请熊力老师别生气，绝对没有恶意，是尊称）的《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以内。原来这样才是最真实的！
相关链接：
阿不
