WinDbg 不显示某些小型转储文件的完整堆栈跟踪
WinDbg does not show full stack trace for some minidump-files
我正在尝试设置一个故障转储系统，以便能够更好地调试我无法在自己的系统上轻松复制的错误
这是我的测试程序(使用Visual Studio 2017的x64版本配置编译(：
#include "pch.h"
#include <iostream>
#include <Windows.h>
#include <DbgHelp.h>
#pragma comment(lib,"Dbghelp.lib")
BOOL MiniDumpWriteDump(
HANDLE hProcess,
DWORD ProcessId,
HANDLE hFile,
MINIDUMP_TYPE DumpType,
PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
LONG CreateMiniDump( struct _EXCEPTION_POINTERS *pExceptionInfo )//EXCEPTION_POINTERS* pep )
{
// Open the file
HANDLE hFile = CreateFile( "MiniDump.dmp", GENERIC_READ | GENERIC_WRITE,
0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
if( ( hFile != NULL ) && ( hFile != INVALID_HANDLE_VALUE ) )
{
// Create the minidump
MINIDUMP_EXCEPTION_INFORMATION mdei;
mdei.ThreadId = GetCurrentThreadId();
mdei.ExceptionPointers = pExceptionInfo;
mdei.ClientPointers = FALSE;
MINIDUMP_TYPE mdt = MiniDumpNormal;
BOOL rv = MiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, mdt, (pExceptionInfo != 0) ? &mdei : 0, 0, 0 );
if( !rv )
std::cout<<"MiniDumpWriteDump failed. Error: "<<GetLastError()<<std::endl;
else
std::cout<<"Minidump created."<<std::endl;
// Close the file
CloseHandle( hFile );
}
else
{
std::cout<<"CreateFile failed. Error: "<<GetLastError()<<std::endl;
}
return EXCEPTION_EXECUTE_HANDLER;
}
static void ftest3()
{
throw std::runtime_error("Error");
}
static void ftest2()
{
ftest3();
}
static void ftest1()
{
ftest2();
}
int main()
{
SetUnhandledExceptionFilter(&CreateMiniDump);
ftest1();
}
(来源：http://www.debuginfo.com/articles/effminidumps2.html(
如果我在我的主系统(我编译程序(上运行它，然后在 Visual Studio 或 WinDbg 中加载.dmp文件，则会正确显示完整堆栈跟踪，我可以看到错误发生的位置：
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 000000fd`3bbbf6f0 00007ff8`a72142cd KERNELBASE!RaiseException+0x68
01 000000fd`3bbbf7d0 00007ff7`7b4f130f VCRUNTIME140!_CxxThrowException+0xad [f:ddvctoolscrtvcruntimesrcehthrow.cpp @ 133]
02 000000fd`3bbbf840 00007ff7`7b4f1319 test_minidump!ftest3+0x1f [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 63]
03 000000fd`3bbbf890 00007ff7`7b4f1329 test_minidump!ftest2+0x9 [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 68]
04 000000fd`3bbbf8c0 00007ff7`7b4f1346 test_minidump!ftest1+0x9 [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 73]
05 000000fd`3bbbf8f0 00007ff7`7b4f1838 test_minidump!main+0x16 [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 79]
06 (Inline Function) --------`-------- test_minidump!invoke_main+0x22 [f:ddvctoolscrtvcstartupsrcstartupexe_common.inl @ 78]
07 000000fd`3bbbf920 00007ff8`b45d3034 test_minidump!__scrt_common_main_seh+0x10c [f:ddvctoolscrtvcstartupsrcstartupexe_common.inl @ 288]
08 000000fd`3bbbf960 00007ff8`b71a1461 kernel32!BaseThreadInitThunk+0x14
09 000000fd`3bbbf990 00000000`00000000 ntdll!RtlUserThreadStart+0x21
但是，如果我在不同的系统上运行该程序，然后尝试在我自己的系统上分析转储，我得到的只是：
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 00000021`ccbef870 00007ffe`8cfd4722 KERNELBASE!RaiseException+0x68
01 00000021`ccbef950 00000021`ccbef9f0 VCRUNTIME140!_CxxThrowException+0xc2 [f:ddvctoolscrtvcruntimesrcehthrow.cpp @ 136]
02 00000021`ccbef958 00007ffe`00000000 0x00000021`ccbef9f0
03 00000021`ccbef960 000001ee`2e25ff30 0x00007ffe`00000000
04 00000021`ccbef968 00000000`00000000 0x000001ee`2e25ff30
这并不完全有帮助。我已经在 WinDbg 中加载了转储文件，然后使用了以下命令：
.symfix
.sympath+ C:UsersFlorianDocumentsProjectstest_minidumpx64Release
.srcpath C:UsersFlorianDocumentsProjectstest_minidumptest_minidump
!analyze -v
.ecxr
k
以下是 WinDbg 的完整输出：
Microsoft (R) Windows Debugger Version 10.0.17134.12 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:UsersFlorianDesktoptmpMiniDump.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available
Symbol search path is: srv*
Executable search path is:
Windows 10 Version 17134 MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
17134.1.amd64fre.rs4_release.180410-1804
Machine Name:
Debug session time: Sun Sep 23 11:56:45.000 2018 (UTC + 2:00)
System Uptime: not available
Process Uptime: not available
..............
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(169c.1b78): C++ EH exception - code e06d7363 (first/second chance not available)
ntdll!NtGetContextThread+0x14:
00007ffe`9abfbc44 c3 ret
0:000> .symfix
0:000> .sympath+ C:UsersFlorianDocumentsProjectstest_minidumpx64Release
Symbol search path is: srv*;C:UsersFlorianDocumentsProjectstest_minidumpx64Release
Expanded Symbol search path is: cache*;SRV*https://msdl.microsoft.com/download/symbols;c:usersfloriandocumentsprojectstest_minidumpx64release
************* Path validation summary **************
Response Time (ms) Location
Deferred srv*
OK C:UsersFlorianDocumentsProjectstest_minidumpx64Release
0:000> .srcpath C:UsersFlorianDocumentsProjectstest_minidumptest_minidump
Source search path is: C:UsersFlorianDocumentsProjectstest_minidumptest_minidump
************* Path validation summary **************
Response Time (ms) Location
OK C:UsersFlorianDocumentsProjectstest_minidumptest_minidump
0:000> !analyze -v
*******************************************************************************
* *
* Exception Analysis *
* *
*******************************************************************************
KEY_VALUES_STRING: 1
TIMELINE_ANALYSIS: 1
Timeline: !analyze.Start
Name: <blank>
Time: 2018-09-24T10:08:32.944Z
Diff: 87107944 mSec
Timeline: Dump.Current
Name: <blank>
Time: 2018-09-23T09:56:45.0Z
Diff: 0 mSec
DUMP_CLASS: 2
DUMP_QUALIFIER: 400
CONTEXT: (.ecxr)
rax=0000000000000000 rbx=00007ffe973da570 rcx=0000000000000000
rdx=0000000000000030 rsi=00007ff798203cd0 rdi=000001ee2e25c750
rip=00007ffe97bba388 rsp=00000021ccbef870 rbp=00000021ccbef9b0
r8=0000000000000000 r9=0000000000000000 r10=000001ee2e0f0000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=00000021ccbef9f0 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206
KERNELBASE!RaiseException+0x68:
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h] ss:00000021`ccbef930=000052660787015b
Resetting default scope
FAULTING_IP:
KERNELBASE!RaiseException+68
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h]
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 00007ffe97bba388 (KERNELBASE!RaiseException+0x0000000000000068)
ExceptionCode: e06d7363 (C++ EH exception)
ExceptionFlags: 00000001
NumberParameters: 4
Parameter[0]: 0000000019930520
Parameter[1]: 00000021ccbef9f0
Parameter[2]: 00007ff798203cd0
Parameter[3]: 00007ff798200000
BUGCHECK_STR: CPP_EXCEPTION
DEFAULT_BUCKET_ID: CPP_EXCEPTION
PROCESS_NAME: test_minidump.exe
ERROR_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>
EXCEPTION_CODE: (NTSTATUS) 0xe06d7363 - <Unable to get error code text>
EXCEPTION_CODE_STR: e06d7363
EXCEPTION_PARAMETER1: 0000000019930520
EXCEPTION_PARAMETER2: 00000021ccbef9f0
EXCEPTION_PARAMETER3: 00007ff798203cd0
EXCEPTION_PARAMETER4: 7ff798200000
WATSON_BKT_PROCSTAMP: 5ba8b478
WATSON_BKT_MODULE: KERNELBASE.dll
WATSON_BKT_MODSTAMP: b0bb231d
WATSON_BKT_MODOFFSET: 3a388
WATSON_BKT_MODVER: 6.2.17134.165
MODULE_VER_PRODUCT: Microsoft® Windows® Operating System
BUILD_VERSION_STRING: 17134.1.amd64fre.rs4_release.180410-1804
MODLIST_WITH_TSCHKSUM_HASH: 636d437315fdc5447e163e64094b1f6a26123a83
MODLIST_SHA1_HASH: 74dec0c40d229cd1e109927f1f5e794fa53165ac
DUMP_FLAGS: 0
DUMP_TYPE: 2
ANALYSIS_SESSION_HOST: DESKTOP-VFOALG8
ANALYSIS_SESSION_TIME: 09-24-2018 12:08:32.0944
ANALYSIS_VERSION: 10.0.17134.12 amd64fre
THREAD_ATTRIBUTES:
PROBLEM_CLASSES:
ID: [0n317]
Type: [@APPLICATION_FAULT_STRING]
Class: Primary
Scope: DEFAULT_BUCKET_ID (Failure Bucket ID prefix)
BUCKET_ID
Name: Omit
Data: Add
String: [CPP_EXCEPTION]
PID: [Unspecified]
TID: [Unspecified]
Frame: [0]
PRIMARY_PROBLEM_CLASS: CPP_EXCEPTION
LAST_CONTROL_TRANSFER: from 00007ffe8cfd4722 to 00007ffe97bba388
STACK_TEXT:
00000021`ccbef870 00007ffe`8cfd4722 : 00000021`ccbef9f0 00007ffe`00000000 000001ee`2e25ff30 00000000`00000000 : KERNELBASE!RaiseException+0x68
00000021`ccbef950 00000021`ccbef9f0 : 00007ffe`00000000 000001ee`2e25ff30 00000000`00000000 00000001`e06d7363 : VCRUNTIME140!_CxxThrowException+0xc2
00000021`ccbef958 00007ffe`00000000 : 000001ee`2e25ff30 00000000`00000000 00000001`e06d7363 00000000`00000000 : 0x00000021`ccbef9f0
00000021`ccbef960 000001ee`2e25ff30 : 00000000`00000000 00000001`e06d7363 00000000`00000000 00000000`00000000 : 0x00007ffe`00000000
00000021`ccbef968 00000000`00000000 : 00000001`e06d7363 00000000`00000000 00000000`00000000 00000000`00000004 : 0x000001ee`2e25ff30
THREAD_SHA1_HASH_MOD_FUNC: 74c55fd19222dcb5ad415427110811b213f4c078
THREAD_SHA1_HASH_MOD_FUNC_OFFSET: 7592380e0f749a34b2d654a7c3b829a033ee79fa
THREAD_SHA1_HASH_MOD: ad69e1f2190edbb9a7df71b4b6403437528645f2
FOLLOWUP_IP:
KERNELBASE!RaiseException+68
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h]
FAULT_INSTR_CODE: 248c8b48
SYMBOL_STACK_INDEX: 0
SYMBOL_NAME: KERNELBASE!RaiseException+68
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: KERNELBASE
IMAGE_NAME: KERNELBASE.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 0
STACK_COMMAND: ~0s ; .ecxr ; kb
BUCKET_ID: CPP_EXCEPTION_KERNELBASE!RaiseException+68
FAILURE_EXCEPTION_CODE: e06d7363
FAILURE_IMAGE_NAME: KERNELBASE.dll
BUCKET_ID_IMAGE_STR: KERNELBASE.dll
FAILURE_MODULE_NAME: KERNELBASE
BUCKET_ID_MODULE_STR: KERNELBASE
FAILURE_FUNCTION_NAME: RaiseException
BUCKET_ID_FUNCTION_STR: RaiseException
BUCKET_ID_OFFSET: 68
BUCKET_ID_MODTIMEDATESTAMP: 0
BUCKET_ID_MODCHECKSUM: 27e598
BUCKET_ID_MODVER_STR: 6.2.17134.165
BUCKET_ID_PREFIX_STR: CPP_EXCEPTION_
FAILURE_PROBLEM_CLASS: CPP_EXCEPTION
FAILURE_SYMBOL_NAME: KERNELBASE.dll!RaiseException
FAILURE_BUCKET_ID: CPP_EXCEPTION_e06d7363_KERNELBASE.dll!RaiseException
TARGET_TIME: 2018-09-23T09:56:45.000Z
OSBUILD: 17134
OSSERVICEPACK: 1
SERVICEPACK_NUMBER: 0
OS_REVISION: 0
SUITE_MASK: 256
PRODUCT_TYPE: 1
OSPLATFORM_TYPE: x64
OSNAME: Windows 10
OSEDITION: Windows 10 WinNt SingleUserTS
OS_LOCALE:
USER_LCID: 0
OSBUILD_TIMESTAMP: 2020-08-28 06:38:41
BUILDDATESTAMP_STR: 180410-1804
BUILDLAB_STR: rs4_release
BUILDOSVER_STR: 10.0.17134.1.amd64fre.rs4_release.180410-1804
ANALYSIS_SESSION_ELAPSED_TIME: a63
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:cpp_exception_e06d7363_kernelbase.dll!raiseexception
FAILURE_ID_HASH: {1253aecc-520d-655b-58e3-5eb61e209188}
Followup: MachineOwner
---------
0:000> .ecxr
rax=0000000000000000 rbx=00007ffe973da570 rcx=0000000000000000
rdx=0000000000000030 rsi=00007ff798203cd0 rdi=000001ee2e25c750
rip=00007ffe97bba388 rsp=00000021ccbef870 rbp=00000021ccbef9b0
r8=0000000000000000 r9=0000000000000000 r10=000001ee2e0f0000
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=00000021ccbef9f0 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000206
KERNELBASE!RaiseException+0x68:
00007ffe`97bba388 488b8c24c0000000 mov rcx,qword ptr [rsp+0C0h] ss:00000021`ccbef930=000052660787015b
0:000> k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 00000021`ccbef870 00007ffe`8cfd4722 KERNELBASE!RaiseException+0x68
01 00000021`ccbef950 00000021`ccbef9f0 VCRUNTIME140!_CxxThrowException+0xc2 [f:ddvctoolscrtvcruntimesrcehthrow.cpp @ 136]
02 00000021`ccbef958 00007ffe`00000000 0x00000021`ccbef9f0
03 00000021`ccbef960 000001ee`2e25ff30 0x00007ffe`00000000
04 00000021`ccbef968 00000000`00000000 0x000001ee`2e25ff30
我能知道的没有警告或错误，那么为什么我没有得到完整的堆栈跟踪信息？
VCRUNTIME140!_CxxThrowException+0xad [f:ddvctoolscrtvcruntimesrcehthrow.cpp @ 133]
对
VCRUNTIME140!_CxxThrowException+0xc2 [f:ddvctoolscrtvcruntimesrcehthrow.cpp @ 136]
有点担心。它表明两台计算机之间的 MSVC 运行时的次要版本不匹配(因为否则，它们为什么要从不同的源代码行调用 RaiseException(。如果 WinDbg 会话没有用于远程计算机VCRUNTIME140的符号(或者更糟糕的是，如果它使用了错误的 PDB(，则回溯将在此时出现问题。WinDbg应该自动下载并加载从小型转储引用的任何版本的符号，但我怀疑这没有正确发生。
使用lm v显示小型转储的模块列表，并密切注意校验和信息。我怀疑您会在两台机器之间看到 vcruntime140.dll 的不同校验和。如果这样做，则需要弄清楚为什么没有为 dll 获得正确的符号。
感谢用户Sneftel和Sean Cline的提示，我找到了解决方案。运行命令！itoldyouso vcruntime140给我以下输出：
sig MISMATCH: vcruntime140.amd64.pdb and VCRUNTIME140.dll
问题是我用于调试的系统在 AMD CPU 上运行，而生成故障转储的系统在英特尔 CPU 上运行。出于某种原因，vcruntime140.dll是特定于系统的，并且两者之间有所不同。(此外，在AMD系统上，PDB称为">vcruntime140.amd64.pdb"，在英特尔上称为">vcruntime140.i386.pdb"。
我从我的英特尔系统中复制了vcruntime140.dll、vcruntime140.i386.pdb 和msvcp140.dll并将它们添加到 WinDbg 的符号路径中。然后我运行了与以前相同的命令，现在它输出完整的堆栈跟踪。
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 00000021`ccbef870 00007ffe`8cfd4722 KERNELBASE!RaiseException+0x68
01 00000021`ccbef950 00007ff7`9820130f VCRUNTIME140!_CxxThrowException+0xc2 [f:ddvctoolscrtvcruntimesrcehthrow.cpp @ 136]
02 00000021`ccbef9d0 00007ff7`98201319 test_minidump!ftest3+0x1f [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 63]
03 00000021`ccbefa20 00007ff7`98201329 test_minidump!ftest2+0x9 [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 68]
04 00000021`ccbefa50 00007ff7`98201346 test_minidump!ftest1+0x9 [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 73]
05 00000021`ccbefa80 00007ff7`98201838 test_minidump!main+0x16 [c:usersfloriandocumentsprojectstest_minidumptest_minidumptest_minidump.cpp @ 79]
06 (Inline Function) --------`-------- test_minidump!invoke_main+0x22 [f:ddvctoolscrtvcstartupsrcstartupexe_common.inl @ 78]
07 00000021`ccbefab0 00007ffe`98983034 test_minidump!__scrt_common_main_seh+0x10c [f:ddvctoolscrtvcstartupsrcstartupexe_common.inl @ 288]
08 00000021`ccbefaf0 00007ffe`9abd1461 kernel32!BaseThreadInitThunk+0x14
09 00000021`ccbefb20 00000000`00000000 ntdll!RtlUserThreadStart+0x21
相关文章：
- 用于解析 win64 堆栈跟踪的命令行客户端(可以访问符号服务器）
- 提升堆栈跟踪不显示函数名称和行号
- cygwin_exception::open_stackdumpfile:将堆栈跟踪转储到 class4.exe.sta
- 如何按指针查看堆栈跟踪
- WinDbg 不显示某些小型转储文件的完整堆栈跟踪
- 发布代码的 gdb 堆栈跟踪可读性如何影响 x64?
- 提升::堆栈跟踪::safe_dump_to输出大小
- Qt 5.9中的QML崩溃-帮助读取堆栈跟踪
- 如何获取崩溃的DLL的堆栈跟踪?
- 当外部源代码中发生异常时，无法正确使用自创建的小型转储文件的堆栈跟踪
- 在 Linux 平台上以 C/C++ 打印进程的所有线程堆栈跟踪
- Boost 堆栈跟踪异步信号安全吗?
- 使用 gdb 时无法获取堆栈跟踪
- VC++ 堆栈跟踪不会解析生产环境中的函数名称
- 从堆栈跟踪中查找共享库中的源代码行
- 捕获异常后的堆栈跟踪
- 是否有一种便携式/标准的方法可以在堆栈跟踪中获取文件名和亚麻布
- 为什么谷歌测试不打印堆栈跟踪或文件名
- 在明夫中打印堆栈跟踪
- GDB 显示奇怪的堆栈跟踪
