目录
一、前言
1. 什么是 core dump
Coredump叫做核心转储，它是进程运行时在突然崩溃的那一刻的一个内存快照。操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下，会把进程此刻内存、寄存器状态、运行堆栈等信息转储保存在一个文件里。
该文件也是二进制文件，可以使用gdb、elfdump、objdump或者windows下的windebug、solaris下的mdb进行打开分析里面的具体内容。
注：core是在半导体作为内存材料前的线圈，当时用线圈当做内存材料，线圈叫做core。用线圈做的内存叫做core memory。
2. 无法生成 dmp 文件
虽然我们知道进程在coredump的时候会产生core文件，但是有时候却发现进程虽然core了，但是我们却找不到core文件
可以将 dmp 文件的大小，调高
二、创建 dmp 方法
1. 修改注册表 当程序崩溃时 产生崩溃转储文件(dmp)
以管理员身份 运行 ：OpenDump.bat 其本质是写注册表。
运行后： 任何程序崩溃都会在C:\CrashDump 产生dmp文件（比较大，约50到200M）。
至少在Win7、Win10的电脑，Win10的平板上运行正确。
a) OpenDump.bat - 自动生成dmp文件
@echo off
echo 正在启用Dump...
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps"
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDump" /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpType /t REG_DWORD /d 2 /f
reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /v DumpCount /t REG_DWORD /d 10 /f
echo Dump已经启用
pause
@echo onb) 注册表 参数说明：
| Value | 描述 | Type | 默认值 |
| DumpFolder | 文件保存路径 | REG_EXPAND_SZ |
%LOCALAPPDATA%CrashDumps |
| DumpCount | dump文件的最大数目 |
REG_DWORD | 10 【注 超过最大值时，将最早的 dmp 文件删除】 |
| DumpType | 指定生成的dump类型: |
REG_DWORD | 1 |
| CustomDumpFlags | 仅在DumpType为0时使用 |
REG_DWORD | MiniDumpWithDataSegs | MiniDumpWithUnloadedModules | MiniDumpWithProcessThreadData |
c) CloseDump.bat - 关闭此功能
@echo off
echo 正在关闭Dump...
reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps" /f
echo Dump已经关闭
pause
@echo on2. 在程序中加入代码
程序中加入存储Dump的代码
通过SetUnhandledExceptionFilter设置捕获dump的入口，然后通过MiniDumpWriteDump生成dump文件
#include<windows.h>
#include<DbgHelp.h>
#include "createdump.h"
// 处理Unhandled Exception的回调函数
LONG WINAPI GPTUnhandledExceptionFilter(PEXCEPTION_POINTERS pExceptionInfo)
{
CreateMiniDump(pExceptionInfo, L"Exception.dmp");
exit(pExceptionInfo->ExceptionRecord->ExceptionCode);
return EXCEPTION_EXECUTE_HANDLER; // 程序停止运行
}
void fun(int *p)
{
p[0]=0;
}
int main(int argc, char * argv[])
{
//注册异常处理函数
SetUnhandledExceptionFilter(GPTUnhandledExceptionFilter);
fun(NULL);
return 0;
}"createdump.h"
#pragma once
#include <windows.h>
#include <imagehlp.h>
#include <stdlib.h>
#pragma comment(lib, "dbghelp.lib")
inline BOOL IsDataSectionNeeded(const WCHAR* pModuleName)
{
if (pModuleName == 0)
{
return FALSE;
}
WCHAR szFileName[_MAX_FNAME] = L"";
_wsplitpath(pModuleName, NULL, NULL, szFileName, NULL);
if (wcsicmp(szFileName, L"ntdll") == 0)
{
return TRUE;
}
return FALSE;
}
inline BOOL CALLBACK MiniDumpCallback(PVOID pParam, const PMINIDUMP_CALLBACK_INPUT pInput, PMINIDUMP_CALLBACK_OUTPUT pOutput)
{
if (pInput == 0 || pOutput == 0)
return FALSE;
switch (pInput->CallbackType)
{
case ModuleCallback:
if (pOutput->ModuleWriteFlags & ModuleWriteDataSeg)
if (!IsDataSectionNeeded(pInput->Module.FullPath))
pOutput->ModuleWriteFlags &= (~ModuleWriteDataSeg);
case IncludeModuleCallback:
case IncludeThreadCallback:
case ThreadCallback:
case ThreadExCallback:
return TRUE;
default:;
}
return FALSE;
}
inline void CreateMiniDump(EXCEPTION_POINTERS* pep, LPCTSTR strFileName)
{
HANDLE hFile = CreateFile(strFileName, GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
if ((hFile != NULL) && (hFile != INVALID_HANDLE_VALUE))
{
MINIDUMP_EXCEPTION_INFORMATION mdei;
mdei.ThreadId = GetCurrentThreadId();
mdei.ExceptionPointers = pep;
mdei.ClientPointers = FALSE;
MINIDUMP_CALLBACK_INFORMATION mci;
mci.CallbackRoutine = (MINIDUMP_CALLBACK_ROUTINE)MiniDumpCallback;
mci.CallbackParam = 0;
MINIDUMP_TYPE mdt = (MINIDUMP_TYPE)(MiniDumpWithPrivateReadWriteMemory | MiniDumpWithDataSegs | MiniDumpWithHandleData | 0x00000800 /*MiniDumpWithFullMemoryInfo*/ | 0x00001000 /*MiniDumpWithThreadInfo*/ | MiniDumpWithUnloadedModules);
MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, mdt, (pep != 0) ? &mdei : 0, 0, &mci);
CloseHandle(hFile);
}
}3. 任务管理器 - 适用崩溃未立即退出
在程序崩溃后，先不关闭程序，在任务管理器中找到该程序对应的进程。右键—>创建转储文件
此时会在默认的目录下创建出一个dump文件。
可以看出，此种方法只适用于程序崩溃但没有立即自行退出的情况。倘若程序故障后自行退出，则此方法就难以应用。
4. WinDbg抓取 - 程序闪退 无法生成 dmp
a）. 崩溃程序
在使用Windbg调试程序之前，先给大家展示下我的测试程序：
int main()
{
char* pStr = (char*)0xa;
printf("%s\n", pStr);
return 0;
}b）. 打开 WinDbg
选择 "File" -- "Open Executable" -- "选择可执行 exe"
Windbg命令窗口打印信息如下：
Microsoft (R) Windows Debugger Version 6.3.9600.16384 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: C:\Users\Administrator\Desktop\testforme.exe
Symbol search path is: *** Invalid ***
****************************************************************************
1. Symbol loading may be unreliable without a symbol search path. *
2. Use .symfix to have the debugger choose a symbol path. *
3. After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
ModLoad: 00000000`00400000 00000000`00410000 testforme.exe
ModLoad: 00000000`77390000 00000000`77539000 ntdll.dll
ModLoad: 00000000`77570000 00000000`776f0000 ntdll32.dll
ModLoad: 00000000`74420000 00000000`7445f000 C:\Windows\SYSTEM32\wow64.dll
ModLoad: 00000000`743c0000 00000000`7441c000 C:\Windows\SYSTEM32\wow64win.dll
ModLoad: 00000000`743b0000 00000000`743b8000 C:\Windows\SYSTEM32\wow64cpu.dll
(9f8.4d4): Break instruction exception - code 80000003 (first chance)
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntdll.dll -
ntdll!CsrSetPriorityClass+0x40:
00000000`7743cb70 cc int 3【备注】
- 请确保所调试的软件，全部都生成 pdb 文件 ( Release 版)
- 可以看到已经加载的模块，以及这些模块所在的内存区域。比如可以看出 exe 的模块位置在内存
0x400000~0x410000 - 调试器中断，这时还没有真正去执行testforme的代码，并且可以通过Windbg命令去设置断点，查看已加载模块的信息等操作
c）. 执行程序
在命令行下使用 g 命令, 可以看到程序中断了在Access Violation，也就是内存访问错误。
0:000:x86> g
(7b8.238): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** ERROR: Module load completed but symbols could not be loaded for testforme.exe
testforme+0x1e88:
00401e88 803800 cmp byte ptr [eax],0 ds:002b:0000000a=??d）. 查找问题函数
然后我们用 kv 指令查看当前异常处的函数调用栈
0:000:x86> kv
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0018fcf0 00812d70 00000000 00810000 0018fd48 testforme+0x1e88
00000000 00000000 00000000 00000000 00000000 0x812d70这个完全看不出来哪里异常了啊，那是因为并没有配置应用程序相应的符号文件，也就是之前所说的PDB文件
e）.设置调试Symbol
0:000:x86> .sympath C:\mysymbols;SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: C:\mysymbols;SRV*C:\symbols*http://msdl.microsoft.com/download/symbols
Expanded Symbol search path is: c:\mysymbols;srv*c:\symbols*http://msdl.microsoft.com/download/symbols
************* Symbol Path validation summary **************
Response Time (ms) Location
OK C:\mysymbols
Deferred SRV*C:\symbols*http://msdl.microsoft.com/download/symbols先通过.sympath设置符号文件的目录。可以将testforme.pdb存放到设置好的符号目录C:\mysymbols。SRV*C:\symbols*http://msdl.microsoft.com/download/symbols这标明将从http://msdl.microsoft.com/download/symbols下载微软的PE文件对应的符号文件，并且缓存到C:\symbols目录下。 你也可以通过File->Symbol Search Path查看符号目录设置（如下图），当然也可以在这里直接对符号目录进行设置。
接着调用.reload命令重新加载模块的符号信息，然后调用kv就可以查看函数异常的函数调用栈了！
0:000:x86> .reload
Reloading current modules
........
0:000:x86> kv
ChildEBP RetAddr Args to Child
0018fee8 00401085 0040c028 0040b344 00000000 testforme!_output_l+0x7f4 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\sp\vctools\crt_bld\self_x86\crt\src\output.c @ 1648]
0018ff2c 0040100c 0040b344 0000000a 004012aa testforme!printf+0x73 (FPO: [Non-Fpo]) (CONV: cdecl) [f:\sp\vctools\crt_bld\self_x86\crt\src\printf.c @ 63]
0018ff88 7700336a 7efde000 0018ffd4 77909f72 testforme!main+0xc (FPO: [0,0,0]) (CONV: cdecl) [d:\vsproject\testforme\testforme\test.cpp @ 11]
0018ff94 77909f72 7efde000 3cf2f376 00000000 kernel32!BaseThreadInitThunk+0xe (FPO: [Non-Fpo])
0018ffd4 77909f45 00401301 7efde000 ffffffff ntdll32!__RtlUserThreadStart+0x70 (FPO: [Non-Fpo])
0018ffec 00000000 00401301 7efde000 00000000 ntdll32!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])通过函数调用栈，可以清楚的看出异常发生在main函数中，在test.cpp第11行处调用了printf。熟悉Windows函数栈的同学应该比较清楚，ChildBEP在32位程序中表示当前调用栈的栈底指针，并且指向的内存处保存的是上一个栈贞的栈底位置。 Args to Child表示当前函数的参数，比如这里printf的参数分别为0040b344和0000000a: 0000000a表示测试程序中变量pStr的值，而0040b344则表示格式化字符串，我们可以使用 da 命令来查看一下：
0:000:x86> da 0040b344
0040b344 "%s."当然有时候你需要切换到特定的栈贞（frame），去查看当前 frame 下的上下文信息，比如局部变量。例如我们现在想去看看main 函数下的变量的值，先用 kn 命令查看栈贞的编号，然后用 .frame 切换到 main 函数那一帧接着用 dv -V 查看所有的局部变量：
0:000:x86> kn
# ChildEBP RetAddr
00 0018fee8 00401085 testforme!_output_l+0x7f4 [f:\sp\vctools\crt_bld\self_x86\crt\src\output.c @ 1648]
01 0018ff2c 0040100c testforme!printf+0x73 [f:\sp\vctools\crt_bld\self_x86\crt\src\printf.c @ 63]
02 0018ff88 7700336a testforme!main+0xc [d:\vsproject\testforme\testforme\test.cpp @ 11]
03 0018ff94 77909f72 kernel32!BaseThreadInitThunk+0xe
04 0018ffd4 77909f45 ntdll32!__RtlUserThreadStart+0x70
05 0018ffec 00000000 ntdll32!_RtlUserThreadStart+0x1b
0:000:x86> .frame 2
02 0018ff88 7700336a testforme!main+0xc [d:\vsproject\testforme\testforme\test.cpp @ 11]
0:000:x86> dv /V奇怪了为啥 dv /V 并没有打印出临时变量 pStr 呢？ 会不会是因为被优化了？ 于是就用 uf 命令反汇编了一下 main 函数 (如下)， 可以看到 printf 的参数压栈直接用的是常量 0A
0:000:x86> uf main
testforme!main [d:\vsproject\testforme\testforme\test.cpp @ 9]:
9 00401000 6a0a push 0Ah
11 00401002 6844b34000 push offset testforme!`string' (0040b344)
11 00401007 e806000000 call testforme!printf (00401012)
11 0040100c 83c408 add esp,8
12 0040100f 33c0 xor eax,eax
13 00401011 c3 ret所以在调试优化后的程序要注意这些可能的变化，当然如果你想让Release的程序不进行优化，可以在Visual Studio中关闭这个选项，如下图：
这里我就不再展示关闭优化后，用windbg调试打印局部变量了，大家可以自己试一试。
5. WinDbg抓取 - 适用崩溃未立即退出
程序运行崩溃后，先不关闭程序，将WinDbg附加到改进程上
执行命令：.dump –ma Test.dmp ，则会产生一个Test.dmp的转储文件。
6. WinDbg - 加载 dmp 文件进行调试
步骤：
1）.软件 dll 库含有调试信息 pdb
2）.将 dmp 文件放置在软件目录exe下
3）.打开 WinDbg，选择 File->Open Crash Dump...选择 dmp 文件
4）.在 WinDbg 命令输入框中输入: !analyze -v;r;kv;lmtn;.logclose; 然后回车
【注】
可先在命令框输入: kv 回车，查看堆栈信息
因 !analyze -v ；lmtn ；命令非常耗时
基本调试命令
r 可以显示系统崩溃时的寄存器，和最后的命令状态。
dd 显示当前内存地址，dd 参数：显示参数处的内存。
u 可以显示反汇编的指令
!analyze -v 显示分析的详细信息。
kb 显示 call stack 内容
kv 显示 call stack 内容 （比 kb 多一列 “Child-SP”）
kv.bugcheck 可以显示出错的代码
三、调试
1. 注意事项
a) 最好把 exe, pdb, dmp 放到同一文件夹下
b) 必须保证pdb与出问题的exe是同一时间生成的
c) 当把 pdb 文件与 dmp 文件放入同一目录下时，就不需设置其路径，否则需要设置 符号表 文件路径 和 源代码路径
工具->选项->调试->符号：
设置源代码路径： 属性->调试源代码
四、Windbg 源码调试
1. 源码调试
习惯于VS调试的同学，可能会觉得Windbg命令调试难记难用（事实上，当你熟悉了之后可能会改变看法）。虽然没有VS的强大的源码调试功能，其实Windbg也提供源码调试的功能。可以通过.srcpath命令或者通过菜单File->Source Search Path去设置源码的目录。
现在我将测试源码拷贝到C:\source目录，然后在用Windbg 程序后，设置断点到测试程序的main函数入口处，然后继续执行程序：
0:000> bp testforme!main
0:000> g这时候你会看到源码文件自动弹出来了，并且中断在main入口处:
Windbg 还提供直接打开Source文件的功能File->Open Source File...，在调试前打开源码文件，可以直接在里面设置断点，调试的快捷键和Visual Studio一样！
2.Windbg工作空间
Windbg的工作空间主要表示调试会话的状态、调试器的设置以及窗口布局的设置等。工作空间的使用主要分为以下几点：
- 未加载任何调试文件的时候，选择File -> Save Workspace保存默认工作空间，则当每次打开Windbg的时候，将采用这个默认的工作空间
- 当调试器已经加载了调试文件的时候，选择File -> Save Workspace将当前工作空间保存为默认工作空间 （这个默认空间仅针对这个调试文件）, 则当下次还是调试这个文件的时候，则采用之前保存的默认工作空间。
- 可以选择File -> Save Workspace As...保存为命名的工作空间，在以后调试应用程序的时候可以选择File -> Open Workspace去打开指定的工作空间
- 以上的工作空间都保存在注册表项HKEY_CURRENT_USER\Software\Microsoft\Windbg\Workspaces里面，你也可以通过File -> Save Worksapce to File...将工作空间保存到文件
还有删除工作空间等操作，大家可以自己去熟悉一下。
3.Windbg的命令分类
Windbg主要分为3大类的调试命令:
- 标准命令 (Standard Command): 这类命令对于所有的调试目标都试用，比如常见的k命令;
- 元命令 (Meta-Command)： 这类目标主要针对特定的目标所做的扩展命令，比如常见的.sympath命令。因为这类命令前面都有一个.,所以也叫作Dot-Command；
- 扩展命令 (Extension Command)：标准命令和元命令都是Windbg内建的命令，而扩展命令是实现在动态加载的DLL中。这类命令前面都有一个!, 比如常用analyze -v.
顺便再这里提一个很实用的命令.hh，用来在Windbg中打开帮助文档，比如使用.hh k则帮助文档会打开到索引k命令处。
详情参照 https://blog.csdn.net/bcbobo21cn/article/details/60468969
