我依靠Windows Error Reporting为大型多线程应用程序创建完整的用户模式转储。我知道当我开始使用它时（2012年初），这些转储包含所有应用程序内存，并且所有线程的完整堆栈在应用程序崩溃时都是准确的（抛出未处理的异常等）。但是在去年的某个未知点上，WER创建的崩溃转储已经发生了变化。它们仍然包含所有内存，但只显示一个线程，并且该进程已经关闭后，该堆栈似乎来自 ：
ntdll.dll!_LdrpCallInitRoutine@16() + 0x14 bytes
ntdll.dll!_LdrShutdownProcess@0() + 0x141 bytes
ntdll.dll!_RtlExitUserProcess@4() + 0x74 bytes
kernel32.dll!_UnhandledExceptionFilter@4() + 0x18928 bytes
这是一个使用VS2010 SP1编译的非托管（无法管理？）32位C ++应用程序，运行在64位Win7 SP1上（并保持更新）。有谁知道在去年改变了WER行为的任何Windows更新？是否可以配置“HKLM \ SOFTWARE \ Microsoft \ Windows \ Windows错误报告\ LocalDumps \ AppName.exe”以外的其他内容？
此外，通过调用'RaiseFailFastException'来终止应用程序仍会导致所有线程都有一个有效堆栈的良好转储。
答案 0 :(得分：4)
啊哈！第三方库调用SetUnhandledExceptionFilter，这会阻止Windows错误报告获取原始异常。他们的处理程序进行了一些内部清理，然后称为abort，此时WER终于能够创建转储。
对于遇到此类问题的任何人，我建议检查已安装的处理程序（SetUnhandledExceptionFilter，set_terminate等的返回值）是否符合预期（如果您依赖于WER，或者您自己的处理程序或CrashRpt，则为null）
答案 1 :(得分：-1)
最好在应用程序崩溃时使其成为自助转储程序。您只需要调用SetUnhandledExceptionFilter函数，指定回调即可。在回调中，使用带有MiniDumpWithFullMemory转储类型的MiniDumpWriteDump函数。
只要发生未处理（由您的代码）异常，就会调用您的异常过滤器。在回调中，最好枚举和暂停进程的所有其他线程。
您可能还需要为SetUnhandledExceptionFilter本身安装一个钩子！为什么？那么， CRT将始终禁用任何已安装的异常过滤器，并且通过钩子函数，您可以避免这种情况。