为何仅GUI进程的Minidump文件内容异常？

从你的描述来看，核心矛盾点非常明确：同样的崩溃处理逻辑，非GUI进程生成的minidump能准确定位崩溃点，但GUI进程的dump却指向无关函数，还伴随0xC0150010错误。结合你提供的补充信息和代码，我判断最可能的原因是GUI进程特有的激活上下文（Activation Context）栈溢出，以下是具体分析和解决思路：

1. 先解读0xC0150010错误码 #

这个错误对应的是STATUS_ACTIVATION_CONTEXT_STACK_OVERFLOW——简单说就是激活上下文栈已经耗尽了。MFC GUI进程因为要频繁加载资源（对话框、控件、图标等），会大量使用激活上下文来管理DLL依赖和资源定位；当空指针崩溃发生时，进程的激活上下文栈可能已经处于溢出状态，此时在进程内调用MinidumpWriteDump会因为无法正确读取进程的激活上下文信息，导致生成的dump不完整或指向错误地址。

而你手动调用WriteStackDetails()能正常输出栈信息，是因为这个操作只需要直接读取当前线程的栈内存，不需要访问进程级的激活上下文状态，所以不受影响。

2. 针对性解决方法 #

方法一：在异常处理中重置激活上下文 #

在调用MinidumpWriteDump之前，先尝试清空当前线程的激活上下文栈，避免溢出状态干扰dump生成。可以在你的UnhandledExceptionFilter函数中加入以下代码：

LONG WINAPI CCrashReporter::UnhandledExceptionFilter(struct _EXCEPTION_POINTERS* pExceptionInfo)
{
    // 重置激活上下文栈，解决STATUS_ACTIVATION_CONTEXT_STACK_OVERFLOW问题
    ACTIVATION_CONTEXT_STACK_FRAME frame = {0};
    while (GetActiveActCtx(&frame.hActCtx))
    {
        DeactivateActCtx(0, frame.lCookie);
        ZeroMemory(&frame, sizeof(frame));
    }

    // 原有dump生成逻辑
    ::EnterCriticalSection(&s_csGuard);
    HANDLE hFile = CreateFile(s_szLogFileNameDmp, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
    if (hFile != INVALID_HANDLE_VALUE)
    {
        MINIDUMP_EXCEPTION_INFORMATION mei;
        mei.ThreadId = GetCurrentThreadId();
        mei.ExceptionPointers = pExceptionInfo;
        mei.ClientPointers = TRUE;

        if (s_fpMiniDumpWriteDump)
        {
            // 可以尝试增加更多dump类型参数，确保信息完整
            s_fpMiniDumpWriteDump(GetCurrentProcess(), GetCurrentProcessId(), hFile, 
                                  MiniDumpWithFullMemoryInfo | MiniDumpWithThreadInfo | MiniDumpWithUnloadedModules, 
                                  &mei, NULL, NULL);
        }

        CloseHandle(hFile);
    }
    ::LeaveCriticalSection(&s_csGuard);

    return s_previousFilter ? s_previousFilter(pExceptionInfo) : EXCEPTION_EXECUTE_HANDLER;
}

方法二：改用跨进程生成dump（推荐长期方案） #

你提到“知晓Minidump理想为跨进程创建”，这确实是规避进程内dump各种问题的最优解——GUI进程崩溃时，由外部监控进程调用MinidumpWriteDump，完全避开进程内的异常状态干扰。

实现思路很简单：

• 写一个轻量的控制台监控程序，启动时接收GUI进程的PID；
• 监控程序通过OpenProcess获取GUI进程的句柄，调用WaitForSingleObject等待进程退出；
• 当GUI进程异常退出时，监控程序调用MinidumpWriteDump生成完整dump。

这种方式不仅能解决当前的激活上下文问题，还能避免进程内dump可能出现的死锁、资源访问冲突等风险。

方法三：排查DbgHelp.dll的加载问题 #

虽然你说其他进程正常，但GUI进程可能因为加载了更多MFC相关DLL，导致LoadDBGHELP()加载了不兼容的DbgHelp版本。建议修改LoadDBGHELP()函数，明确加载系统目录下的DbgHelp.dll：

void CCrashReporter::LoadDBGHELP()
{
    TCHAR szSysDir[MAX_PATH];
    GetSystemDirectory(szSysDir, MAX_PATH);
    PathAppend(szSysDir, _T("dbghelp.dll"));
    s_hDbgHelp = LoadLibrary(szSysDir);
    if (s_hDbgHelp)
    {
        s_fpMiniDumpWriteDump = (tMiniDumpWriteDump)GetProcAddress(s_hDbgHelp, "MiniDumpWriteDump");
    }
}

确保使用系统自带的、与当前系统兼容的DbgHelp版本，避免程序目录下的旧版本DLL干扰。

3. 额外排查点 #

• 检查GUI进程的MFC异常处理设置：确认没有启用特殊的MFC异常捕获逻辑（比如自定义的CATCH块），导致全局异常过滤器无法拿到完整的异常上下文；
• 测试在非UI线程触发崩溃：如果GUI进程的非UI线程崩溃时dump正常，那就进一步验证了是UI线程的激活上下文问题。

内容的提问来源于stack exchange，提问作者Marcello