TL;DR 为同一个崩溃事件编写多个转储是否有意义，如果是，您需要注意什么。
我们正在使用 MiniDumpWriteDump当我们的应用程序中存在未处理的异常/中止/younameit 时写入故障转储。
到目前为止的代码实际上写了两个转储:
- 使用
MiniDumpWithDataSegs获得一个小的，压缩后甚至可以通过糟糕的电子邮件发送，没有问题。 - 一个完整的
MiniDumpWithFullMemory，以便在我们需要时提供完整的信息。
为了让它工作，我们调用 MiniDUmpWriteDump 两次:
1 Open/create file for small dump
2 Write small dump
3 Open/create file for large dump
4 Write large dump
据我所知，此方案的一个附加想法是写入小型转储更快。它基本上总是亚秒级的，而写入大转储通常需要几秒钟，尤其是当应用程序完全加载并且大转储很容易达到 1.2 GB 或更大时。
据我所知，首先编写小转储背后的想法是，因为它更快，所以它会在崩溃的时间点拍摄崩溃进程的更详细的快照，因为该进程是高度多线程的.
显然，进程的线程在第一次调用 MDWP 结束和第二次调用开始之间继续运行，所以我们确实有很多情况，小转储中的信息实际上比大转储中的信息。
考虑到这一点之后，我会假设但是，要写入转储，MiniDumpWriteDump 无论如何都必须挂起进程的线程，所以如果我们要写首先是大转储，我们会让大转储比小转储更准确。
问题
我们应该先写大转储再写小转储吗？我们甚至应该写两个转储吗？我们能否以某种方式让系统先挂起进程的线程，然后写入两个完全“同步”的转储？
最佳答案
几年来我分析过各种客户的转储，以下仅是我个人对你的问题的看法，希望对你有所帮助。
我们应该先写大转储再写小转储吗？ 我认为顺序对于崩溃、挂起等典型问题并不重要。崩溃点在那里，死锁在转储中，首先捕获或之后。
我们甚至应该写两个转储吗？ 我建议至少写 1 个完整转储，小转储非常方便您对问题的初步印象，但它非常有限，尤其是。当您的应用程序崩溃时。所以你可以建议客户给你发邮件给小转储做第一轮分类，如果这不能帮助你找到根本原因，然后问全转储。从技术上讲，您可以从完整转储中剥离出一个小转储，但是，您可能不希望您的客户为您完成此类工作。所以这取决于您与客户的互动方式。
我们能否以某种方式让系统先挂起进程的线程，然后写入两个完全“同步”的转储？
从技术上讲这是可行的。例如执行 out-proc 相对容易，一个简单的 NtSuspendProcess() 暂停所有目标线程，但它必须从另一个进程调用。如果您更喜欢在进程中执行，则必须枚举所有线程并调用 SuspendThread()，这就是 MiniDumpWriteDump() 的工作原理。但是，我认为 sync/asyn 不会影响转储的准确性。
关于winapi - MiniDumpWriteDump 并为同一个崩溃写入多个转储？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16272451/