Windbg DUMP分析（原创汇总）
1. 引入篇
1.1 下载安装
1.2 调试器
1.3 操作界面
2. 命令篇
2.1 按照来源划分
2.1.1 基本命令
2.1.2 元命令
2.1.3 扩展命令
2.2 按照功能划分
2.2.1 系统信息
2.2.2 进程
2.2.3 模块
2.2.4 符号
2.2.5 线程
2.2.6 内存
2.2.7 事件
3. 探讨篇
3.1方法内联
3.2 字符串驻留池
1. 引入篇
引入篇
1.1 下载安装
1.2 调试器
1.3 操作界面
所谓技术分享，其实是一个自我总结和相互学习、不断成长的过程。
考虑到之前原创的文章http://www.cnblogs.com/LoveOfPrince/p/6032523.html《记一次内存泄漏DUMP分析》被转载，而且有的没有说明出处，这里所有的图片都打了标记，不好意思啊。
1.1 下载安装
WinDbg是微软发布的一款免费而十分强大的调试工具，从官网下载Microsoft Windows SDK，选择安装“Debugging Tools for Windows”。
1.2 调试器
安装目录下，有四个调试器程序。
cdb.exe和 ntsd.exe只支持用户模式调试；Kd.exe主要用于内核调试，有时候也用于用户模式。上述三者只能在控制台界面以命令行形式工作。
Windbg.exe采用可视化的用户界面，支持用户模式和内核模式调试。在两种模式下，都支持实时调试模式和事后调试模式。另外，还支持源码级的调试。
1.3 操作界面
2. 命令篇
命令篇
2.1 按照来源划分
2.2 按照功能划分
2.1 按照来源划分
按照来源划分
2.1.1 基本命令
2.1.2 元命令
2.1.3 扩展命令
2.1.1 基本命令
用?查看基本命令
2.1.2 元命令
用.help查看元命令
2.1.3 扩展命令
用.chain查看扩展模块，再查看指定模块下的所有扩展命令
2.2 按照功能划分
按照功能划分
2.2.1 系统信息
2.2.2 进程
2.2.3 模块
2.2.4 符号
2.2.5 线程
2.2.6 内存
2.2.7 事件
2.2.1 系统信息
为了下载和本地系统匹配的符号，可用如下命令查看本地系统信息。
这里列出了操作系统版本、系统持续运行时间、调试时间等信息。
2.2.2 进程
WinDbg能够同时调试多个进程。可以直接附加已经存在的进程，也可以创建新的进程并附加上去。 需要先切换到目标进程，检查当前进程的环境信息，以确认是否切换成功。 最后，结束对当前进程的调试。
查看进程信息，以及包含的程序域。
2.2.3 模块
模块信息相关的命令。
列出了当前调试进程要加载的模块符号信息，将指定模块保存为程序集，反编译看看效果还不错，不过有些变量名不是能直接看懂的。
比如查看模块镜像文件重定位信息，可以发现基本上都是最优的。也可以查看PE头信息研究一下。
2.2.4 符号
在创建二进制镜像文件时，伴生的后缀名为.dbg、.sym或.pdb的文件称为符号文件，包含如下符号信息：
1）源文件路径以及每个符号的行号。
2）变量的名字和地址。
3）函数名称、地址及其原型。
4）帧指针优化数据。
5）变量、结构等的类型信息。
符号路径用于告诉调试器去哪里寻找符号文件，调试过程中，只有正确设置了符号路径，使得调试器能够将调试目标、符号文件以及源码文件一一对应起来，才能够最好地发挥调试器的强大功用。
如果涉及到成千上万个符号文件，以及同一个符号文件存在不同平台下的不同版本的时候，那么一一手动设置符号路径肯定是不现实的，于是引入符号服务器的概念。符号服务器有一套命名规则，使得调试器能够正确找到对应平台和版本的符号文件。
WinDbg访问符号需要两个文件(SYMSRV.DLL 和 SYMSTORE.EXE)，需要设置系统变量告诉他这两个文件放在什么地方。
2.2.5 线程
查看线程的基本信息。
比如列出所有（托管）线程。
线程号是由调试器软件内部维护的线程ID值，是一个从0开始的整数，在外部是没有太大意义的。
线程ID是系统维护的系统唯一的ID值。
线程的冻结状态，决定了是否分发CPU时间给它。
查看线程的堆栈信息。
查看线程的时间信息，包括三个方面：自创建之初到现在的总消耗时间、用户模式执行时间、内核模式执行时间。
除了耗时，还可以查看线程池的信息。
2.2.6 内存
内存是存储数据、代码的地方，通过内存查看命令可以分析很多问题。通过查看堆上的大对象，以及对象的持有者，了解没有被回收的原因等。
通过查看堆上的大对象，以及对象的持有者，了解没有被回收的原因等。
2.2.7 事件
Windbg是事件驱动的。
比如程序故障分析，电脑蓝屏故障分析等。
查看C盘确实发现百度浏览器目录，卸载百度杀毒、删除C盘百度浏览器（也可清理下注册表），重启电脑，恢复正常。
3. 探讨篇
探讨篇
3.1方法内联
3.2 字符串驻留池
3.1方法内联
默认情况下，Release版本进行了各种优化，其中，将被调用方法的方法主体移入调用方的主体，就可以避免某些方法的调用开销，这一操作称为方法内联。
可以发现，DoCalc方法被内联，而Calc方法却不会。这里提到一个问题，什么是优秀的代码，我的理解是除了让人看的舒服，还要更贴近编译优化后的代码。
3.2 字符串驻留池
程序启动时，系统域中的驻留池负责管理被驻留的字符串。抓取DUMP分析，查找这些字符串的根，发现都在一个object数组中，查看这个数组，果然是驻留池。
引用架构师修炼中的一段话：
发现问题永远都比解决问题更加重要。一般来说，从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。
最坏情况就是当我们时间或者能力有限，实在是无法定位出是谁的问题的时候，比如系统出故障，也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本，尽量去隔离问题影响的范围，留出时间和空间去识别真正的问题。