dump 内存分析

CPU 及内存占用过大，这也是我们日常调试工作中最常见的两个问题
首先附上两链接
一个样例演示
http://www.cnblogs.com/xioxu/archive/2009/09/04/1560326.html
一点文档信息
http://www.cnblogs.com/kissdodog/p/3731743.html

抓取 Dump 文件
可以用工具或系统自带的命令抓取Minidump文件，但是用任务管理器抓取的是FullDump文件比较大，信息比较多，但多余的信息也多
使用 Windbg 调试 Dump 文件
(1) 启动 Windbg 打开 Dump 文件 (File -> Open Crash Dump...)
(2) 载入 SOS.dll
--1、元命令loadby加载SOS .net版本相同

0:000> .load sos
0:000> .loadby sos mscorwks
Unable to find module 'mscorwks'

--2、元命令load加载SOS .net版本不相同

　　如果使用的.Net版本不同，那么还可以手动指定版本，如手动指定载入4.0版本命令：

.load C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/sos.dll
.load C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/sos.dll

　　如果是64位，那么应该加载如下sos.dll

.load C:/Windows/Microsoft.NET/Framework64/v2.0.50727/sos.dll
.load C:/Windows/Microsoft.NET/Framework64/v2.0.50727/sos.dll

(3) 对于 CPU 占用过高的问题，别忘了 ThreadPool 也可能是造成问题的根源。

0:000> !threadpool

可以看到线程池对cpu的利用率，线程数量，上限
(4) 我们看看是哪个线程占用 CPU 时间过多。

0:000> !runaway

(5) 切换到该线程，查看调用堆栈。

0:000> ~3 s

这里3是要切换的线程id序号在上面runaway里会显示序号

0:003> !clrstack

会显示当前线程托管代码的调用堆栈
(6) 看看这个 "Learn.CUI.Program.b__0()" 的 IL 代码。

0:003> !name2ee * dumptest.Program

name2ee显示指定模块中指定类型或方法的MethodTable结构和EEClass结构,然后就能看到模块或方法表的地址了
(7)导出模块

0:003> !dumpdomain

就可以使用MSIL反汇编器 (Ildasm.exe) 浏览模块或方法表也可以用Reflector.exe 或者最新流行的ILSpy.exe(推荐)
然后可以查看是否是gc出了问题
大对象堆在进行full gc会耗时比较久

0:003> !eeheap -gc

显示被公共语言运行时内部数据结构使用的进程内存的有关信息
可以发现是否有内存占用比较大的段
(8) 查证这些大户的身份。

0:003> !dumpheap -min 85000 -stat

大于等于85000KB的就是大对象了
然后看是那种类型的大对象造成的
(9) 找出大户的具体内存地址。

0:003> !dumpheap -type Byte[] -min 85000

这里你找出的假设是Byte[]类型
然后会列出这种类型大对象的地址
(10) 挑一个出来，看看谁持有该大户的引用。

0:003> !gcroot 022d3250

显示对在指定地址上的一个对象的引用（或根）信息。
往上接着找找到调用它的根对象或你觉得能看出猫腻的对象

0:003> !do 012d2e2c

然后会列出对象的字段信息，和名字
然后你能根据包含的类型，和根对象的名字，根对象类型取代码里找到可能出问题的地方了。

如果cpu占用率高可以通过前面的!threadpool 或其它方式看到CPU utilization 99%，找到可能出问题的线程在压缩或者计算啥的
ProcInfo [-env] [-time] [-mem]
显示针对该进程的环境变量、内核CPU时间和内存使用统计

另外建议直接使用Jetbrains的dotMemory看内存对象数量泄露等和 dotTrace工具看哪些东西被调用多少次，占用率等