如何使用 MiniDumpWriteDump 获得有意义的堆栈跟踪
How do I get a meaningful stack-trace using MiniDumpWriteDump
我正在尝试以编程方式生成堆栈跟踪。当我的用户遇到崩溃时，尤其是随机崩溃时，很难通过获取转储的过程与他们交谈，以便我可以解决问题。过去，一旦他们向我发送跟踪信息，我就会将其中的地址交叉引用到 Intermediate/foo.map 文件，以找出问题所在的函数（这是最好的方法吗？）
我根据在网上找到的各种示例构建了一个库，以输出小型转储，使我的工作更轻松。我上演了一次崩溃，但我从小型转储文件中获得的堆栈跟踪与我通过附加 windbg 获得的实时堆栈跟踪截然不同。两者的示例如下：
MiniDump.dmp:
KERNELBASE.dll!76a6c42d()
[Frames below may be incorrect and/or missing, no symbols loaded for KERNELBASE.dll]
KERNELBASE.dll!76a6c42d()
kernel32.dll!75bd14bd()
game.exe!00759035()
game.exe!00575ba3()
WinDbg.exe:
0:000:x86> kv
ChildEBP RetAddr Args to Child
00186f44 00bc8ea9 19460268 0018a9b7 03f70a28 Minidump!crashme+0x2 (FPO: [0,0,0]) (CONV: cdecl) [c:\project\debug\minidump.cpp @ 68]
0018795c 00b9ef31 0018796c 03f56c00 6532716d Main!LoadPlugin+0x339 (FPO: [1,642,4]) (CONV: cdecl) [c:\project\main\pluginloader.cpp @ 129]
00188968 00b9667d 19460268 0018a9ac 00000000 Main!Command+0x1f1 (FPO: [2,1024,4]) (CONV: cdecl) [c:\project\main\commands.cpp @ 2617]
*** WARNING: Unable to verify checksum for C:\Game\game.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Game\game.exe
0018b1a8 005b5095 19460268 0018beac 00000000 Main!Hook::Detour+0x52d (FPO: [2,2570,0]) (CONV: thiscall) [c:\project\main\hook.cpp @ 275]
WARNING: Stack unwind information not available. Following frames may be wrong.
0018b1b4 00000000 19495200 19495200 00000006 game+0x1b5095
game.exe不是我的，我也没有source/symbols。 Main.dll 被注入到 game.exe 中，它提供前端功能以从游戏中加载额外的 DLL。调试代码和阶段性崩溃在 Minidump.dll 中。 Main.dll 加载 Minidump 后调用 AfterLoad()，设置异常过滤器，然后触发崩溃。相关的小型转储代码如下：
当我打开 MiniDump.dmp 时，我将它指向我所有的符号文件（game.exe 除外，我没有），那部分似乎可以正常工作。我确实将它指向 game.exe 二进制文件，因为我有它。我从中得到的堆栈跟踪确实没有帮助。我的最终目标是用户只需加载 DLL，导致崩溃，然后将转储文件通过电子邮件发送给我。然后我将附加符号文件和二进制文件，并能够为它们诊断问题。是我做错了什么，还是根本无法得到我想要的。
typedef BOOL (WINAPI *MINIDUMPWRITEDUMP)(
HANDLE hProcess,
DWORD ProcessId,
HANDLE hFile,
MINIDUMP_TYPE DumpType,
CONST PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
CONST PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
CONST PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
LONG WINAPI WriteDumpFilter(struct _EXCEPTION_POINTERS *pExceptionPointers)
{
HANDLE hFile = NULL;
HMODULE hDll = NULL;
MINIDUMPWRITEDUMP pMiniDumpWriteDump = NULL;
_MINIDUMP_EXCEPTION_INFORMATION ExceptionInformation = {0};
//load MiniDumpWriteDump
hDll = LoadLibrary(TEXT("DbgHelp.dll"));
pMiniDumpWriteDump = (MINIDUMPWRITEDUMP)GetProcAddress(hDll, "MiniDumpWriteDump");
//create output file
hFile = CreateFile( _T( "C:\temp\MiniDump.dmp"),
GENERIC_READ|GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
//bail if we don't have a file
if ((hFile != NULL) && (hFile != INVALID_HANDLE_VALUE))
{
//get exception information
ExceptionInformation.ThreadId = GetCurrentThreadId();
ExceptionInformation.ExceptionPointers = pExceptionPointers;
ExceptionInformation.ClientPointers = TRUE;
//write the debug dump
pMiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, MiniDumpWithFullMemory, &ExceptionInformation,
NULL, NULL );
//close the debug output file
CloseHandle(hFile);
}
return EXCEPTION_EXECUTE_HANDLER;
}
VOID crashme() {int* foo = 0; *foo = 0;}
VOID AfterLoad(VOID)
{
SetUnhandledExceptionFilter(WriteDumpFilter);
crashme();
}
我试图 trim 从所有细节中删除一些细节以简化问题，但如果需要，我可以更明确。我在 CodeProject 上找到了一篇很好的文章，我尝试寻找更多的背景信息来阅读以帮助我理解问题，但我能找到的并没有帮助我理解它们只是逐步解决问题运行（已经是）。任何人都知道我做错了什么，或者可以指点我相关的阅读材料吗？
在 Sergei 的建议下，我在 windbg 中执行了 .ecxr 并获得了更好的输出，但它仍然与我直接将 windbg 挂接到进程并触发崩溃时得到的跟踪不匹配。这是小型转储跟踪；
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0018e774 00759035 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58
0018e7b4 00575ba3 00000000 00000000 00000001 game+0x359035
0018fc50 0057788a 009855ef 0018fdcb 00000001 game+0x175ba3
0018fc78 77b7e013 012d9230 002d91d0 002d9200 game+0x17788a
0018fc90 77ba9567 00290000 00000000 002d91d0 ntdll!RtlFreeHeap+0x7e
0018fd6c 0076ece2 0018ff78 007e1b7e ffffffff ntdll!LdrRemoveLoadAsDataTable+0x4e0
002bbc38 5c306174 61666544 00746c75 5d4c3055 game+0x36ece2
002bbc3c 61666544 00746c75 5d4c3055 8c000000 0x5c306174
002bbc40 00746c75 5d4c3055 8c000000 00000101 0x61666544
002bbc44 5d4c3055 8c000000 00000101 01000000 game+0x346c75
002bbc48 8c000000 00000101 01000000 00000000 0x5d4c3055
002bbc4c 00000000 01000000 00000000 0000006e 0x8c000000
以及将调试器附加到进程的跟踪
0:000:x86> kv
ChildEBP RetAddr Args to Child
00186f44 00bc8ea9 19460268 0018a9b7 03f70a28 Minidump!crashme+0x2 (FPO: [0,0,0]) (CONV: cdecl) [c:\project\debug\minidump.cpp @ 68]
0018795c 00b9ef31 0018796c 03f56c00 6532716d Main!LoadPlugin+0x339 (FPO: [1,642,4]) (CONV: cdecl) [c:\project\main\pluginloader.cpp @ 129]
00188968 00b9667d 19460268 0018a9ac 00000000 Main!Command+0x1f1 (FPO: [2,1024,4]) (CONV: cdecl) [c:\project\main\commands.cpp @ 2617]
*** WARNING: Unable to verify checksum for C:\Game\game.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Game\game.exe
0018b1a8 005b5095 19460268 0018beac 00000000 Main!Hook::Detour+0x52d (FPO: [2,2570,0]) (CONV: thiscall) [c:\project\main\hook.cpp @ 275]
WARNING: Stack unwind information not available. Following frames may be wrong.
0018b1b4 00000000 19495200 19495200 00000006 game+0x1b5095
我没有 game.exe 的源代码（我有 DLL 的源代码，这是错误所在），但我反编译了 game.exe，这是 game+0x359035 中的内容.
.text:00759001 ; =============== S U B R O U T I N E =======================================
.text:00759001
.text:00759001 ; Attributes: library function bp-based frame
.text:00759001
.text:00759001 ; __stdcall _CxxThrowException(x, x)
.text:00759001 __CxxThrowException@8 proc near ; CODE XREF: .text:0040100Fp
.text:00759001 ; sub_401640+98p ...
.text:00759001
.text:00759001 dwExceptionCode = dword ptr -20h
.text:00759001 dwExceptionFlags= dword ptr -1Ch
.text:00759001 nNumberOfArguments= dword ptr -10h
.text:00759001 Arguments = dword ptr -0Ch
.text:00759001 var_8 = dword ptr -8
.text:00759001 var_4 = dword ptr -4
.text:00759001 arg_0 = dword ptr 8
.text:00759001 arg_4 = dword ptr 0Ch
.text:00759001
.text:00759001 push ebp
.text:00759002 mov ebp, esp
.text:00759004 sub esp, 20h
.text:00759007 mov eax, [ebp+arg_0]
.text:0075900A push esi
.text:0075900B push edi
.text:0075900C push 8
.text:0075900E pop ecx
.text:0075900F mov esi, offset unk_853A3C
.text:00759014 lea edi, [ebp+dwExceptionCode]
.text:00759017 rep movsd
.text:00759019 mov [ebp+var_8], eax
.text:0075901C mov eax, [ebp+arg_4]
.text:0075901F mov [ebp+var_4], eax
.text:00759022 lea eax, [ebp+Arguments]
.text:00759025 push eax ; lpArguments
.text:00759026 push [ebp+nNumberOfArguments] ; nNumberOfArguments
.text:00759029 push [ebp+dwExceptionFlags] ; dwExceptionFlags
.text:0075902C push [ebp+dwExceptionCode] ; dwExceptionCode
.text:0075902F call ds:RaiseException
.text:00759035 pop edi
.text:00759036 pop esi
.text:00759037 leave
.text:00759038 retn 8
.text:00759038 __CxxThrowException@8 endp
我触发的错误在 Minidump.dll 中，但堆栈顶部的这段代码在 game.exe 中。 game.exe 内部可能发生了很多我不知道的事情，它是否可能劫持了我以某种方式触发的错误？即，我在 DLL 中触发了错误，但是 game.exe 中的某些设置会在调用写入小型转储的异常过滤器之前捕获程序流？
如果是这样，当我将调试器附加到进程时，触发错误并获得指向错误的正确输出在我的 DLL 中，那么这意味着 game.exe 没有捕获调试器可以进行跟踪之前的程序流程。我怎样才能使我的小型转储代码以相同的方式运行...这正在进入我不太熟悉的领域。有什么想法吗？
我追得更远，调用那个函数的函数中有这一行：
.text:00575A8D mov esi, offset aCrashDumpTooLa ; "Crash dump too large to send.\n"
所以，我认为 game.exe 正在劫持异常以在我的代码尝试获取转储之前执行它自己的转储。然后我的转储跟踪只是 game.exe 的转储过程的跟踪...
回答
我已经弄明白了。我不确定如何回答我自己的 post，所以这是交易。
.text:0057494A push offset aDbghelp_dll ; "DbgHelp.dll"
.text:0057494F call ds:LoadLibraryA
.text:00574955 test eax, eax
.text:00574957 jz short loc_5749C8
.text:00574959 push offset aMinidumpwrited ; "MiniDumpWriteDump"
.text:0057495E push eax ; hModule
.text:0057495F call ds:GetProcAddress
.text:00574965 mov edi, eax
.text:00574967 test edi, edi
.text:00574969 jz short loc_5749C8
.text:0057496B mov edx, lpFileName
.text:00574971 push 0 ; hTemplateFile
.text:00574973 push 80h ; dwFlagsAndAttributes
.text:00574978 push 2 ; dwCreationDisposition
.text:0057497A push 0 ; lpSecurityAttributes
.text:0057497C push 0 ; dwShareMode
.text:0057497E push 40000000h ; dwDesiredAccess
.text:00574983 push edx ; lpFileName
.text:00574984 call ds:CreateFileA
.text:0057498A mov esi, eax
.text:0057498C cmp esi, 0FFFFFFFFh
.text:0057498F jz short loc_5749C8
.text:00574991 call ds:GetCurrentThreadId
.text:00574997 push 0
.text:00574999 push 0
.text:0057499B mov [ebp+var_1C], eax
.text:0057499E lea eax, [ebp+var_1C]
.text:005749A1 push eax
.text:005749A2 push 0
.text:005749A4 push esi
.text:005749A5 mov [ebp+var_18], ebx
.text:005749A8 mov [ebp+var_14], 1
.text:005749AF call ds:__imp_GetCurrentProcessId
.text:005749B5 push eax
.text:005749B6 call ds:GetCurrentProcess
.text:005749BC push eax
.text:005749BD call edi
.text:005749BF push esi ; hObject
.text:005749C0 call ds:CloseHandle
.text:005749C6 jmp short loc_574A02
来自 game.exe。原来 game.exe 是它自己的小型转储。我的小型转储是在他们之后触发的，所以我在堆栈跟踪中看到的是他们转储过程的跟踪。我在游戏的安装目录中找到了一个 dmp 文件，当我将我的符号加载到其中后，它显示了我想要的正确输出。
你做得很好。打开生成的小型转储时，加载符号后，执行
.ecxr
首先将上下文设置为您在 ExceptionInformation 参数中保存到 MiniDumpWriteDump() 的内容。然后你就会有一个合法的堆栈跟踪。
我们在我工作的地方使用类似的转储生成机制。
虽然未来会有一些陷阱。您想检查您的转储捕获机制是否在 abort() 调用之类的事情上被触发。
为此，请查看 _set_invalid_parameter_handler() 和 signal(SIGABRT, ...)。
我明白了。基本上 game.exe 有自己的 MiniDumpWriteDump 代码，该代码在我的代码之前触发。所以我得到的堆栈跟踪不是错误的跟踪，而是 game.exe 执行它自己的 MiniDump 的跟踪。我把更多的细节放在了原来的 post.
谢谢！
我正在尝试以编程方式生成堆栈跟踪。当我的用户遇到崩溃时，尤其是随机崩溃时，很难通过获取转储的过程与他们交谈，以便我可以解决问题。过去，一旦他们向我发送跟踪信息，我就会将其中的地址交叉引用到 Intermediate/foo.map 文件，以找出问题所在的函数（这是最好的方法吗？）
我根据在网上找到的各种示例构建了一个库，以输出小型转储，使我的工作更轻松。我上演了一次崩溃，但我从小型转储文件中获得的堆栈跟踪与我通过附加 windbg 获得的实时堆栈跟踪截然不同。两者的示例如下：
MiniDump.dmp:
KERNELBASE.dll!76a6c42d()
[Frames below may be incorrect and/or missing, no symbols loaded for KERNELBASE.dll]
KERNELBASE.dll!76a6c42d()
kernel32.dll!75bd14bd()
game.exe!00759035()
game.exe!00575ba3()
WinDbg.exe:
0:000:x86> kv
ChildEBP RetAddr Args to Child
00186f44 00bc8ea9 19460268 0018a9b7 03f70a28 Minidump!crashme+0x2 (FPO: [0,0,0]) (CONV: cdecl) [c:\project\debug\minidump.cpp @ 68]
0018795c 00b9ef31 0018796c 03f56c00 6532716d Main!LoadPlugin+0x339 (FPO: [1,642,4]) (CONV: cdecl) [c:\project\main\pluginloader.cpp @ 129]
00188968 00b9667d 19460268 0018a9ac 00000000 Main!Command+0x1f1 (FPO: [2,1024,4]) (CONV: cdecl) [c:\project\main\commands.cpp @ 2617]
*** WARNING: Unable to verify checksum for C:\Game\game.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Game\game.exe
0018b1a8 005b5095 19460268 0018beac 00000000 Main!Hook::Detour+0x52d (FPO: [2,2570,0]) (CONV: thiscall) [c:\project\main\hook.cpp @ 275]
WARNING: Stack unwind information not available. Following frames may be wrong.
0018b1b4 00000000 19495200 19495200 00000006 game+0x1b5095
game.exe不是我的，我也没有source/symbols。 Main.dll 被注入到 game.exe 中，它提供前端功能以从游戏中加载额外的 DLL。调试代码和阶段性崩溃在 Minidump.dll 中。 Main.dll 加载 Minidump 后调用 AfterLoad()，设置异常过滤器，然后触发崩溃。相关的小型转储代码如下：
当我打开 MiniDump.dmp 时，我将它指向我所有的符号文件（game.exe 除外，我没有），那部分似乎可以正常工作。我确实将它指向 game.exe 二进制文件，因为我有它。我从中得到的堆栈跟踪确实没有帮助。我的最终目标是用户只需加载 DLL，导致崩溃，然后将转储文件通过电子邮件发送给我。然后我将附加符号文件和二进制文件，并能够为它们诊断问题。是我做错了什么，还是根本无法得到我想要的。
typedef BOOL (WINAPI *MINIDUMPWRITEDUMP)(
HANDLE hProcess,
DWORD ProcessId,
HANDLE hFile,
MINIDUMP_TYPE DumpType,
CONST PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
CONST PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
CONST PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
LONG WINAPI WriteDumpFilter(struct _EXCEPTION_POINTERS *pExceptionPointers)
{
HANDLE hFile = NULL;
HMODULE hDll = NULL;
MINIDUMPWRITEDUMP pMiniDumpWriteDump = NULL;
_MINIDUMP_EXCEPTION_INFORMATION ExceptionInformation = {0};
//load MiniDumpWriteDump
hDll = LoadLibrary(TEXT("DbgHelp.dll"));
pMiniDumpWriteDump = (MINIDUMPWRITEDUMP)GetProcAddress(hDll, "MiniDumpWriteDump");
//create output file
hFile = CreateFile( _T( "C:\temp\MiniDump.dmp"),
GENERIC_READ|GENERIC_WRITE, 0, NULL,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL );
//bail if we don't have a file
if ((hFile != NULL) && (hFile != INVALID_HANDLE_VALUE))
{
//get exception information
ExceptionInformation.ThreadId = GetCurrentThreadId();
ExceptionInformation.ExceptionPointers = pExceptionPointers;
ExceptionInformation.ClientPointers = TRUE;
//write the debug dump
pMiniDumpWriteDump( GetCurrentProcess(), GetCurrentProcessId(),
hFile, MiniDumpWithFullMemory, &ExceptionInformation,
NULL, NULL );
//close the debug output file
CloseHandle(hFile);
}
return EXCEPTION_EXECUTE_HANDLER;
}
VOID crashme() {int* foo = 0; *foo = 0;}
VOID AfterLoad(VOID)
{
SetUnhandledExceptionFilter(WriteDumpFilter);
crashme();
}
我试图 trim 从所有细节中删除一些细节以简化问题，但如果需要，我可以更明确。我在 CodeProject 上找到了一篇很好的文章，我尝试寻找更多的背景信息来阅读以帮助我理解问题，但我能找到的并没有帮助我理解它们只是逐步解决问题运行（已经是）。任何人都知道我做错了什么，或者可以指点我相关的阅读材料吗？
在 Sergei 的建议下，我在 windbg 中执行了 .ecxr 并获得了更好的输出，但它仍然与我直接将 windbg 挂接到进程并触发崩溃时得到的跟踪不匹配。这是小型转储跟踪；
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
WARNING: Stack unwind information not available. Following frames may be wrong.
0018e774 00759035 e06d7363 00000001 00000003 KERNELBASE!RaiseException+0x58
0018e7b4 00575ba3 00000000 00000000 00000001 game+0x359035
0018fc50 0057788a 009855ef 0018fdcb 00000001 game+0x175ba3
0018fc78 77b7e013 012d9230 002d91d0 002d9200 game+0x17788a
0018fc90 77ba9567 00290000 00000000 002d91d0 ntdll!RtlFreeHeap+0x7e
0018fd6c 0076ece2 0018ff78 007e1b7e ffffffff ntdll!LdrRemoveLoadAsDataTable+0x4e0
002bbc38 5c306174 61666544 00746c75 5d4c3055 game+0x36ece2
002bbc3c 61666544 00746c75 5d4c3055 8c000000 0x5c306174
002bbc40 00746c75 5d4c3055 8c000000 00000101 0x61666544
002bbc44 5d4c3055 8c000000 00000101 01000000 game+0x346c75
002bbc48 8c000000 00000101 01000000 00000000 0x5d4c3055
002bbc4c 00000000 01000000 00000000 0000006e 0x8c000000
以及将调试器附加到进程的跟踪
0:000:x86> kv
ChildEBP RetAddr Args to Child
00186f44 00bc8ea9 19460268 0018a9b7 03f70a28 Minidump!crashme+0x2 (FPO: [0,0,0]) (CONV: cdecl) [c:\project\debug\minidump.cpp @ 68]
0018795c 00b9ef31 0018796c 03f56c00 6532716d Main!LoadPlugin+0x339 (FPO: [1,642,4]) (CONV: cdecl) [c:\project\main\pluginloader.cpp @ 129]
00188968 00b9667d 19460268 0018a9ac 00000000 Main!Command+0x1f1 (FPO: [2,1024,4]) (CONV: cdecl) [c:\project\main\commands.cpp @ 2617]
*** WARNING: Unable to verify checksum for C:\Game\game.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Game\game.exe
0018b1a8 005b5095 19460268 0018beac 00000000 Main!Hook::Detour+0x52d (FPO: [2,2570,0]) (CONV: thiscall) [c:\project\main\hook.cpp @ 275]
WARNING: Stack unwind information not available. Following frames may be wrong.
0018b1b4 00000000 19495200 19495200 00000006 game+0x1b5095
我没有 game.exe 的源代码（我有 DLL 的源代码，这是错误所在），但我反编译了 game.exe，这是 game+0x359035 中的内容.
.text:00759001 ; =============== S U B R O U T I N E =======================================
.text:00759001
.text:00759001 ; Attributes: library function bp-based frame
.text:00759001
.text:00759001 ; __stdcall _CxxThrowException(x, x)
.text:00759001 __CxxThrowException@8 proc near ; CODE XREF: .text:0040100Fp
.text:00759001 ; sub_401640+98p ...
.text:00759001
.text:00759001 dwExceptionCode = dword ptr -20h
.text:00759001 dwExceptionFlags= dword ptr -1Ch
.text:00759001 nNumberOfArguments= dword ptr -10h
.text:00759001 Arguments = dword ptr -0Ch
.text:00759001 var_8 = dword ptr -8
.text:00759001 var_4 = dword ptr -4
.text:00759001 arg_0 = dword ptr 8
.text:00759001 arg_4 = dword ptr 0Ch
.text:00759001
.text:00759001 push ebp
.text:00759002 mov ebp, esp
.text:00759004 sub esp, 20h
.text:00759007 mov eax, [ebp+arg_0]
.text:0075900A push esi
.text:0075900B push edi
.text:0075900C push 8
.text:0075900E pop ecx
.text:0075900F mov esi, offset unk_853A3C
.text:00759014 lea edi, [ebp+dwExceptionCode]
.text:00759017 rep movsd
.text:00759019 mov [ebp+var_8], eax
.text:0075901C mov eax, [ebp+arg_4]
.text:0075901F mov [ebp+var_4], eax
.text:00759022 lea eax, [ebp+Arguments]
.text:00759025 push eax ; lpArguments
.text:00759026 push [ebp+nNumberOfArguments] ; nNumberOfArguments
.text:00759029 push [ebp+dwExceptionFlags] ; dwExceptionFlags
.text:0075902C push [ebp+dwExceptionCode] ; dwExceptionCode
.text:0075902F call ds:RaiseException
.text:00759035 pop edi
.text:00759036 pop esi
.text:00759037 leave
.text:00759038 retn 8
.text:00759038 __CxxThrowException@8 endp
我触发的错误在 Minidump.dll 中，但堆栈顶部的这段代码在 game.exe 中。 game.exe 内部可能发生了很多我不知道的事情，它是否可能劫持了我以某种方式触发的错误？即，我在 DLL 中触发了错误，但是 game.exe 中的某些设置会在调用写入小型转储的异常过滤器之前捕获程序流？
如果是这样，当我将调试器附加到进程时，触发错误并获得指向错误的正确输出在我的 DLL 中，那么这意味着 game.exe 没有捕获调试器可以进行跟踪之前的程序流程。我怎样才能使我的小型转储代码以相同的方式运行...这正在进入我不太熟悉的领域。有什么想法吗？
我追得更远，调用那个函数的函数中有这一行：
.text:00575A8D mov esi, offset aCrashDumpTooLa ; "Crash dump too large to send.\n"
所以，我认为 game.exe 正在劫持异常以在我的代码尝试获取转储之前执行它自己的转储。然后我的转储跟踪只是 game.exe 的转储过程的跟踪...
回答
我已经弄明白了。我不确定如何回答我自己的 post，所以这是交易。
.text:0057494A push offset aDbghelp_dll ; "DbgHelp.dll"
.text:0057494F call ds:LoadLibraryA
.text:00574955 test eax, eax
.text:00574957 jz short loc_5749C8
.text:00574959 push offset aMinidumpwrited ; "MiniDumpWriteDump"
.text:0057495E push eax ; hModule
.text:0057495F call ds:GetProcAddress
.text:00574965 mov edi, eax
.text:00574967 test edi, edi
.text:00574969 jz short loc_5749C8
.text:0057496B mov edx, lpFileName
.text:00574971 push 0 ; hTemplateFile
.text:00574973 push 80h ; dwFlagsAndAttributes
.text:00574978 push 2 ; dwCreationDisposition
.text:0057497A push 0 ; lpSecurityAttributes
.text:0057497C push 0 ; dwShareMode
.text:0057497E push 40000000h ; dwDesiredAccess
.text:00574983 push edx ; lpFileName
.text:00574984 call ds:CreateFileA
.text:0057498A mov esi, eax
.text:0057498C cmp esi, 0FFFFFFFFh
.text:0057498F jz short loc_5749C8
.text:00574991 call ds:GetCurrentThreadId
.text:00574997 push 0
.text:00574999 push 0
.text:0057499B mov [ebp+var_1C], eax
.text:0057499E lea eax, [ebp+var_1C]
.text:005749A1 push eax
.text:005749A2 push 0
.text:005749A4 push esi
.text:005749A5 mov [ebp+var_18], ebx
.text:005749A8 mov [ebp+var_14], 1
.text:005749AF call ds:__imp_GetCurrentProcessId
.text:005749B5 push eax
.text:005749B6 call ds:GetCurrentProcess
.text:005749BC push eax
.text:005749BD call edi
.text:005749BF push esi ; hObject
.text:005749C0 call ds:CloseHandle
.text:005749C6 jmp short loc_574A02
来自 game.exe。原来 game.exe 是它自己的小型转储。我的小型转储是在他们之后触发的，所以我在堆栈跟踪中看到的是他们转储过程的跟踪。我在游戏的安装目录中找到了一个 dmp 文件，当我将我的符号加载到其中后，它显示了我想要的正确输出。
你做得很好。打开生成的小型转储时，加载符号后，执行
.ecxr
首先将上下文设置为您在 ExceptionInformation 参数中保存到 MiniDumpWriteDump() 的内容。然后你就会有一个合法的堆栈跟踪。
我们在我工作的地方使用类似的转储生成机制。
虽然未来会有一些陷阱。您想检查您的转储捕获机制是否在 abort() 调用之类的事情上被触发。
为此，请查看 _set_invalid_parameter_handler() 和 signal(SIGABRT, ...)。
我明白了。基本上 game.exe 有自己的 MiniDumpWriteDump 代码，该代码在我的代码之前触发。所以我得到的堆栈跟踪不是错误的跟踪，而是 game.exe 执行它自己的 MiniDump 的跟踪。我把更多的细节放在了原来的 post.
谢谢！