今年开始做C++服务器开发了，所以来记录下自己用到的东西。分析Core Dump文件一般好像都是用windbg、debugdiag、Visual Studio这三种，下面分别介绍
Windbg
可以使用windbg来调试、抓取、分析程序的dump
一、调试
注意，调试程序会导致该程序停止运行，不建议用来调试线上运营的后台程序。
配置
点击File->Symbol File Path File，输入srv*c:\symbols*http://msdl.microsoft.com/download/symbols，其中的c:sysbols可以根据本机环境随意修改。作用是可以自动从Microsoft中下载windows系统的pdb，自动按需下载。如果添加多个目录，可以用 ; 分隔。
1、直接调试可执行程序(*.exe)
点击File->Executable ，然后找到exe程序，打开即可。
Debug->Stop Debug可以停止调试。
2、调试正在运行中的可执行程序
先运行程序，然后打开Windbg，File->Attach to a process。
注意事项：
如果出现该程序调试端口已存在等错误，需要检查在本机是否已经启动了DebugDiag相关进程，如果有，则关闭dgbhost.exe 等进程，大概有两个。 如果是在开发环境，启动了VS的话，可能也需要关闭掉。都会占用被调试程序的调试端口。
3、调试运行时崩溃的程序
只要崩溃的程序没有关闭，
打开Windbg,File->Attach to a process，选中崩溃的程序。
在command中输入[.dump /ma 要保存的文件完整路径名称]，提示Dump successfully written后，就会生成一个dump文件。
二、抓取
抓取程序的dump需要用到windbg中的adpplus，其中抓取方式有三种。
1、Hang模式
进程运行时,随时可以使用-hang参数得到一个Dump文件, 而不需要考虑线程是否真的处于死锁中,用于诊断高内存使用率, 高CPU使用率。
在hang模式下，dump file是以非侵入方式被抓取的, 并没有中断线程, 因此不需要跟启动进程有相同的身份,在客户端调试服务器时,hang模式抓取dump file很有用。
使用： 在命令行进入windbg所在目录，然后执行adplus -hang -pn Prs.exe -o c:/dump
2、Crash模式
在进程异常终止时抓取dump file。进程异常终止有3种情况:
- unhandled的exception
- asp.net进程由于iis reset或recycle而终止
- 出现heap毁坏,栈溢出,内存不足等错误,进程必须退出
使用：adplus -crash -pn w3wp.exe -NoDumpOnFirst
3、使用配置文件
以给adplus指定配置文件,在某个特定的条件下生成dump file,并把dump file存在特定目录下
crash
!load clr10/sos
clr
Log
!clr10/sos.cce System.Runtime.InteropServices.COMException 1; j ($t1 = 1) '.dump /ma /u c:/dumps/exceptiondump.dmp;gn' ; 'gn'
GN
Void
GN
使用：adplus -c myconfig.cfg -pn w3wp.exe
4、服务启动自动附加调试的方法：
在注册表：HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options
- 指向 新建 ，然后单击 键 。 在注册表编辑器在左窗格，会注意到 新项 # 1 （新的注册表子项的名称） 中选择进行编辑。
- 键入 ImageName 替换 新项 # 1 ，然后按 Enter 键。 请注意 ImageName 是进程的承载您要调试的服务的映像名称占位符。 是例如如果您要调试由具有 MyService.exe 作为图像名称的进程承载的服务，键入 MyService.exe 。
- 用鼠标右键单击在步骤 e 中创建注册表子项。
- 指向 新建 ，然后单击 字符串值 。 在注册表编辑器在右窗格，会注意到 新值 # 1 ，一个新的注册表项的名称选择进行编辑。
- 使用 debugger，替换 新值 # 1 ，，然后按 ENTER 键。
- 右键单击您在步骤 h， 调试程序 注册表项，然后单击 修改 。 编辑字符串 对话框。
- 在该 数值数据 文字框键入 DebuggerPath，然后单击 确定 。
请注意 DebuggerPath 是调试器的完整路径，您要使用的占位符。 是例如如果您要使用 WinDbg 调试器调试服务，您可以键入类似于以下的完整路径：
C:/Progra1/Debugg1/windbg.exe
Adplus参数说明
-pn ： 指定要分析的进程名。使用多个“-pn process name”开关来指定多个进程。
-o ： dump file的存储路径,缺省为adplus所在路径
-FullOnFirst ： create full dumps on first chance exceptions
-MiniOnSecond
-NoDumpOnFirst ： 如果exception被try-catch block处理,使用这个参数就不会生成dump file
-NoDumpOnSecond ：
-quiet ： No dialog boxes will be displayed
详解：
1、 什么是First Chance Exception 和 Second ChanceException?
当程序抛出异常(.net 或 native exception),此时这个exception为1st chance exception,如果这个exception 没有被 try-catch block处理,这个exception就会成为2nd chance exception (unhandled exception) 当前进程随后终止.
2、什么是Mini Dump 和Full Dump?
user-mode Mini Dump,保存了进程crash时virtual memory的部分内容.有些SOS的命令在Mini Dump上不能工作.Mini Dump的内容和大小和被dump的程序有关.Mini Dump所包含的信息并不一定比Full Dump少.
Full User-Mode Dumps包含了进程的整个内存空间,程序的image,handle table等调试信息.
参考链接： https://aloneplayer.wordpress.com/2008/10/09/working-with-dump-file/
分析Dump
点击File-> Open Crash Dump,然后选中要分析的dump文件，打开它。
windbg会自动打开command窗口页，在其最下面的命令行可以输入各种指令来分析dump文件。
常用Windbg指令
-
!analyze -v详细列出dump文件的信息，其中会有导致错误的代码片段，以及一些列数据可供分析。 -
kb显示当前线程调用堆栈，一般可确认是程序哪一行出了问题。 -
~*kb显示所有线程调用堆栈。 -
lm显示当前加载的模块信息 (*.pdb *.dll) -
kP可以看函数的入参 -
!for_each_frame dv /t： 可以看函数中的局部变量 -
dc , db： 产看某一内存中的值 可以直接接变量名 不过可能需要回溯栈 -
!threads：显示所有线程 -
~0s ， ~1s：进入某个线程 -
!frame ProcessA!FunctionA： 查看某一变量有时需要。 回溯栈 -
!uniqstack：扩展命令显示当前进程中所有线程的调用堆栈，除开重复的那些。 -
!teb：扩展以的格式化后的形式显示线程环境块(TEB)的信息 -
s-sa 和 s-su：命令搜索未指定的 ASCII 和 Unicode 字符串。这在检查某段内存是否包含可打印字符时有用。 -
dds、dps 和 dqs：命令显示给定范围内存的内容。 该内存被假定为符号表中的一连串地址。相应的符号也会被显示出来。命令显示给定范围内存的内容,它们是把内存区域转储出来，并把内存中每个元素都视为一个符号对其进行解析，dds是四字节视为一个符号，dqs是每8字节视为一个符号，dps是根据当前处理器架构来选择最合适的长度 -
.kframes：命令设置堆栈回溯显示的默认长度。默认20 -
k, kb, kd, kp, kP, kv (Display Stack Backtrace)：k*命令显示给定线程的调用堆栈，以及其他相关信息。通常要结合12)使用否则显示出来的东西很少 -
.reload /i xxx.dll：忽略.pdb 文件版本不匹配的情况。
使用参考链接：http://blog.csdn.net/xuleilx/article/details/17622627
DebugDiag
获取dump文件
打开debugdiag后，点击add Rule，选择Crash 点击下一步，然后选择A specific process 点击下一步，找到要监听的进程，点击下一步；在Action type for unconfigured first chance一栏，选择Log Stack Trace，然后下面的maximum number...意思是最多创建多少个dump文件，默认10个就好，太多了也分析不过来呀。然后点击下一步，上面的rule name默认就好，下面的dump文件输出位置，可以自己找个位置放好。 再点击下一步，这里默认第一个选择就可以了，点击完成就行了。
按上面的步骤，等到程序发生崩溃的时候，就会有dump文件生成了。
分析dump文件
其实我用debugdiag都没分析出什么能看懂的结果，还是用Visual Studio比较直接。
注意
使用工具时，一打开这个软件我的电脑就会弹出警告，（error collection COM+ infomation.依赖服务或组无法启动）， 各种查找后发现是电脑里COM+ System Application 这个服务未能启动，而且无法手动启动，此时点击该服务->属性->依存关系，可以看到此服务依赖三个服务，挨个在服务里查找，发现是System Event Notification Service服务设置的禁用，改状态为手动，然后启动它，然后再去启动COM+ System Application服务，启动成功，DebugDiag就不会再报错了。
Visual Studio
我们可以很方便的利用VS分析dump文件，如果有生成dump文件时对应的.pdb文件，就可以直接定位到出错的代码行。
步骤
1、将.exe和.pdb文件与dump文件放在一个文件夹中，然后在VS中，点击 文件->打开->文件，选择dump文件，打开。
2、在解决方案资源管理器右键单击解决方案'Solution0'（这个0会随着你打开的dump文件而增加，不重要），然后选择属性，点击调试源文件，将项目的源代码对应的文件路径添加进去，然后确定。
3、在工具->选项->调试->常规中，找到“要求源文件与原始版本完全匹配”这一栏，取消掉勾选，这是因为可能你已经修改过某些地方的代码了，会导致找不到位置，而只显示汇编文件的情况。
4、最后，点击右侧的操作那里，有个使用 仅限本机 进行调试，就能出结果啦。
水平有限，有什么不对的希望有大佬指教下，我会改正的。