dump文件獲取
Windows上處理程序crash的問題可以通過分析dump文件來定位問題。那怎么拿到dump文件呢?有幾種方式可以獲取。
注冊表配置dump文件生成目錄
像我司生產(chǎn)的整機(jī)可以根據(jù)Windows官方文檔在出廠的時候就預(yù)埋注冊表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
配置dump文件生成的路徑:
像這里配置到了%localappdata%\CrashDumps
由于%localappdata%
是個環(huán)境變量,所以當(dāng)程序崩潰的時候會不同的用戶會在存在不同的目錄下產(chǎn)生dump文件,系統(tǒng)服務(wù)和普通應(yīng)用的目錄也不一樣:
- 普通應(yīng)用 :
C:\Users\你的用戶名\AppData\Local\CrashDumps
- 系統(tǒng)服務(wù) :
C:\Windows\system32\config\systemprofile\AppData\Local\CrashDumps
它也支持在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
下添加子項(xiàng),為指定的exe進(jìn)行單獨(dú)配置:
像這樣的Demo2.exe就會在D:\dump2
下生成dump文件。
而像windows出現(xiàn)藍(lán)屏的情況重啟之后就可以看C:\WINDOWS\MEMORY.DMP
這個dump文件了,像我們這段時間做的項(xiàng)目,有個驅(qū)動引發(fā)藍(lán)屏的問題就是看這個dump文件去定位分析的。
使用MiniDumpWriteDump生成dump文件
我們也可以使用SetUnhandledExceptionFilter注冊異常處理函數(shù),在函數(shù)里面調(diào)用MiniDumpWriteDump生成dump文件:
#include <windows.h>
#include<DbgHelp.h>
#pragma comment(lib,"DbgHelp.lib")
LONG ApplicationCrashHandler(EXCEPTION_POINTERS* pException) {
HANDLE hDumpFile = CreateFileW(L"DemoDump.dmp", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
MINIDUMP_EXCEPTION_INFORMATION dumpInfo;
dumpInfo.ExceptionPointers = pException;
dumpInfo.ThreadId = GetCurrentThreadId();
dumpInfo.ClientPointers = TRUE;
MiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hDumpFile, MiniDumpNormal, &dumpInfo, NULL, NULL);
CloseHandle(hDumpFile);
return EXCEPTION_EXECUTE_HANDLER;
}
int main()
{
//注冊異常處理函數(shù)
SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER)ApplicationCrashHandler);
... // 業(yè)務(wù)代碼
return 0;
}
上面的代碼雖然可以打出dump文件,但是里面的信息比較少,如果想要打出更多的信息可以參考crashdump
dump文件分析
拿到dump文件之后就要看看如何分析了,這里寫一個簡單的demo:
#include <iostream>
using namespace std;
struct Data {
char* str;
};
void foo(Data* data) {
cout << std::strlen(data->str)<<endl;
}
int main()
{
Data data = { nullptr };
foo(&data);
return 0;
}
我們可以使用WinDbg去打開dump文件:
注意將pdb文件放到符號目錄下,例如我這里配置的是D盤:
然后就可以用!analyze -v
命令先讓W(xué)inDbg簡單分析一下:
...
ExceptionAddress: 00007ffdcf587cc1 (ucrtbased!strlen+0x0000000000000031)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000000
Attempt to read from address 0000000000000000
...
例如從上面的信息我們可以看到奔潰的原因是strlen里面讀取了空指針。
然后使用kb
命令調(diào)用堆棧查看完整調(diào)用鏈路:
0:000> kb
# RetAddr : Args to Child : Call Site
00 00007ffe`aaf9ffe9 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtWaitForMultipleObjects+0x14
01 00007ffe`aaf9feee : 00000000`000000bc 00000000`00000096 00000000`d000022d 00000000`d000022d : KERNELBASE!WaitForMultipleObjectsEx+0xe9
02 00007ffe`acc527f7 : 00000000`00000000 00000000`00000001 0000008c`ec2fee00 00000000`00000096 : KERNELBASE!WaitForMultipleObjects+0xe
03 00007ffe`acc52236 : 00000000`00000000 00000000`00000000 00000000`00000003 00007ffe`acbe0000 : kernel32!WerpReportFaultInternal+0x587
04 00007ffe`ab09cafb : 00000000`00000000 0000008c`ec2ffec0 00000000`00000001 00007ffd`cf512e59 : kernel32!WerpReportFault+0xbe
05 00007ffe`adaf8abd : 00000000`0005aa79 00007ffe`adbb2b34 00000000`00000000 00007ffe`ada70b5a : KERNELBASE!UnhandledExceptionFilter+0x3db
06 00007ffe`adadf197 : 0000008c`ec2feed0 00000000`00000000 0000008c`ec2fee88 0000008c`ec2ff470 : ntdll!RtlUserThreadStart$filt$0+0xac
07 00007ffe`adaf441f : 00000000`00000000 0000008c`ec2ff3d0 0000008c`ec2ffab0 0000008c`ec2ffab0 : ntdll!_C_specific_handler+0x97
08 00007ffe`ada6e466 : 0000008c`ec2ffab0 00007ffe`ada50000 00007ffe`adaaaa58 00007ffe`adbdebf8 : ntdll!RtlpExecuteHandlerForException+0xf
09 00007ffe`adaf340e : 000001b5`00250000 00000000`00000000 00000000`00000000 00007ffd`00000000 : ntdll!RtlDispatchException+0x286
0a 00007ffd`cf587cc1 : 00007ff7`8d053837 cccccccc`cccccccc 00007ffd`cf4b0dab 00000000`00000000 : ntdll!KiUserExceptionDispatch+0x2e
0b 00007ff7`8d053837 : cccccccc`cccccccc 00007ffd`cf4b0dab 00000000`00000000 00007ff7`8d052367 : ucrtbased!strlen+0x31 [minkernel\crts\ucrt\src\appcrt\string\amd64\strlen.asm @ 70]
0c 00007ff7`8d05389a : 0000008c`ec2ffd48 00000000`00000000 00000000`00000000 00007ffd`cf4b0769 : Demo!foo+0x17 [C:\Users\user\workspace\CppAutoRegisterDemo\main.cpp @ 11]
0d 00007ff7`8d05c7c9 : 00000000`00000001 00007ffd`cf5322a3 00000000`00000000 00007ff7`8d05bc4d : Demo!main+0x2a [C:\Users\user\workspace\CppAutoRegisterDemo\main.cpp @ 18]
0e 00007ff7`8d05c6ae : 00007ff7`8d065000 00007ff7`8d065350 00000000`00000000 00000000`00000000 : Demo!invoke_main+0x39 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 79]
0f 00007ff7`8d05c56e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Demo!__scrt_common_main_seh+0x12e [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288]
10 00007ff7`8d05c85e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Demo!__scrt_common_main+0xe [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 331]
11 00007ffe`acbf257d : 0000008c`ec07d000 00000000`00000000 00000000`00000000 00000000`00000000 : Demo!mainCRTStartup+0xe [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp @ 17]
12 00007ffe`adaaaa58 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x1d
13 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28
從這一行可以看到foo的frame id是0c:
0c 00007ff7
8d05389a : 0000008c
ec2ffd48 0000000000000000 00000000
00000000 00007ffd`cf4b0769 : Demo!foo+0x17 [C:\Users\user\workspace\CppAutoRegisterDemo\main.cpp @ 11]
所以我們可以用.frame 0c
查看這個frame的信息:
從Locals信息里面可以看到data這個指針的值是0x0000008cec2ffd48,而data->str的值則為0x0,所以我們就能定位出是data->str空指針導(dǎo)致strlen出現(xiàn)異常。
有時候奔潰也可能和多線程還有鎖相關(guān),使用到的WinDbg命令可以參考我之前的博客