7

Currently we call MiniDumpWriteDump with the MiniDumpNormal | MiniDumpWithIndirectlyReferencedMemory flags. That works just fine for internal builds in Debug configuration, but isn't giving as much information as we need in Release configuration.

In Release, the minidump data contains enough stack information for the debugger to work out where in the code the failure occurred, but no other data. I don't simply mean local variables are missing due to being optimised out, as you'd expect in a Release build - I mean, there is nothing useful except for the call stack and current code line. No registers, no locals, no globals, no objects pointed to by locals - nothing. We don't even get 'this' which would allow us to view the current object. That was the point of using MiniDumpWithIndirectlyReferencedMemory - it should have included memory referenced by locals and stack variables, but doesn't seem to.

What flags should we be using instead? We don't want to use MiniDumpWithFullMemory and start generating 600MB+ dumps, but would happily expand the dumps somewhat beyond the 90KB we currently get if it meant getting more useful data. Perhaps we should be using MiniDumpWithDataSegments (globals) or...?

Ahmed Ashour
  • 5,179
  • 10
  • 35
  • 56
Andy Patrick
  • 280
  • 1
  • 4
  • 11

1 Answers1

0

WinDbg uses the following flags for a .dump /ma:

0:003> .dumpdebug
----- User Mini Dump Analysis

MINIDUMP_HEADER:
Version         A793 (62F0)
NumberOfStreams 13
Flags           41826
                0002 MiniDumpWithFullMemory
                0004 MiniDumpWithHandleData
                0020 MiniDumpWithUnloadedModules
                0800 MiniDumpWithFullMemoryInfo
                1000 MiniDumpWithThreadInfo
                40000 MiniDumpWithTokenInformation

I suggest you replace MiniDumpWithFullMemory by MiniDumpWithIndirectlyReferencedMemory.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
  • The flags are [version specific](https://msdn.microsoft.com/en-us/library/windows/desktop/ms680519%28v=vs.85%29.aspx). Make sure you have a new version of dbghelp.dll that supports the flag – Thomas Weller Oct 14 '15 at 22:42