TL;DR Does it make sense to write multiple dumps for the same crash event, and if yes, what do you need to look out for.
We're using MiniDumpWriteDump to write a crash dump when there is a unhandled-exception / abort / younameit in our application.
The code so far actually writes two dumps:
MiniDumpWithDataSegs to get a small one that can be sent by even crappy email w/o problem once zipped.MiniDumpWithFullMemory to have the full info available should we need it.To make this work, we call MiniDUmpWriteDump twice:
1 Open/create file for small dump
2 Write small dump
3 Open/create file for large dump
4 Write large dump
As far as I can tell, one additinoal idea of this scheme was that writing the small dump is faster. It's always subsecond basically, while writing the large dump often can take quite a few seconds, especially when the application is fully loaded and the large dump will easily be 1.2 GB or more.
The idea behind writing the small dump first, as far as I can tell, was that because it's faster, it would take a more detailed snapshot of the crashed process at the point in time it crashed, as the process is heavily multithreaded.
Obviously, the threads of the process continue to run between the end of the first call and the start of the second call to MDWP, so we do have quite some cases where the info in the small dump is actually more accurate than the info in the large dump.
After thinking about this, I would assume however, that to write the dump, MiniDumpWriteDump has to suspend the threads of the process anyway, so if we were to write the large dump first, we would have the large dump more accurate than the small one.
Should we write the large dump before the small one? Should we even be writing two dumps? Could we somehow have the system first suspend the threads of the process and then write two dumps that are completely "synchronous"?
I ever analyzed dumps from various customers for a couple years, the followings is only my personal perspective to your question, hope this helps.
Should we write the large dump before the small one? i don't consider the order is important for crash, hang etc typical issues. the crash spot is there, the deadlock is there in dump, first captured or after.
Should we even be writing two dumps? i would suggest write at least 1 full dump, the small dump is very convenient for you to get an initial impression of what's the problem, but it's very limited esp. when your application crash. so you may suggest customer to email you the small dump to do first round triage, if this can not help you find the root cause, then ask the full dump. technically you can strip a small dump out from a full dump, however, you may not want your customer to do this sort of work for you. so this depends on how you interact with your customer.
Could we somehow have the system first suspend the threads of the process and then write two dumps that are completely "synchronous"?
technically this is doable. e.g. it's relatively easy to do out-proc, a simple NtSuspendProcess() suspend all target threads, but it have to be called from another process. if you prefer to do in-proc, you have to enumerate all threads and call SuspendThread(), this is how MiniDumpWriteDump() works. However, i think sync/asyn does not affect the accuracy of the dump.