Reducing the size of minidumps of managed programs while keeping some heap information?

With the dump debugging su开发者_C百科pport in .NET 4.0 we are looking into automatically (after asking the user of course :) creating minidumps of C# program crashes to upload them to our issue tracking system (so that the minidumps can assist in resolving the cause of the crash).

Everything is working fine when using the WithFullMemory minidump type. We can see both stack and heap variables. Unfortunately the (zipped) dumps are quite large even for small C# programs.

If we use the "Normal" minidump type we get a very small dump, but not even stack variable information is available in the managed debugger. In fact, anything less than WithFullMemory seems quite useless in the managed debugger. We have made a few attempts at using a MINIDUMP_CALLBACK_ROUTINE to limit the included module information to our own modules, but it seems that it has almost no effect on a managed dump but still manages to break the managed debugging?

Does anyone have any tips on how to trim the minidump while keeping it useful for managed debugging?

I use the following flags to save space will generating useful minidumps for C++ applications:

MiniDumpWithPrivateReadWriteMemory | 
            MiniDumpWithDataSegs | 
            MiniDumpWithHandleData |
            MiniDumpWithFullMemoryInfo | 
            MiniDumpWithThreadInfo | 
            MiniDumpWithUnloadedModules

The flag values are specified in DbgHelp.h and would need to be marshaled into C#. The dump is further restricted by specifying a CallbackRoutine.

Just fyi, as mentioned above ClrDump looks very cool but it appears it only works with the 1.1. and 2.0 runtimes.

With all due respect, I STRONGLY encourage you to sign-up for a Microsoft WinQual account, register your applications with Microsoft.

http://www.microsoft.com/whdc/winlogo/maintain/StartWER.mspx

This will allow you to not only take advantage of Microsoft's extensive crash collection and analysis services (for free!), but will also allow you to publish fixes and patches for your applications through Windows' built-in error reporting facilties.

Further, by participating in the WinQual program, enterprises who deploy your app and who employ an in-house Windows Error Reporting system will be able to collect, report and receive patches for your app too.

Another benefit is that employing WinQual, you're one step closer to getting your app logo certified!

Every OEM & ISV I've worked with who uses WinQual saves an ENORMOUS amount of effort and expense compared to rolling their own crash collection and reporting system.

I wrote an email to author of ClrDump asking a question what MINIDUMP_TYPE parameters his tool used to create dumps in 'min' mode. I posted his answer here: What is minimum MINIDUMP_TYPE set to dump native C++ process that hosts .net component to be able to use !clrstack in windbg

ClrDump might help you out.

ClrDump is a set of tools that allow to produce small minidumps of managed applications. In the past, it was necessary to use full dumps (very large in size) if you needed to perform post-mortem analysis of a .NET application. ClrDump can produce small minidumps that contain enough information to recover the call stacks of all threads in the application.