Generate minimal .NET dumps that can be analyzed effectively
goldshtn opened this issue · 4 comments
Currently, there's nothing that we can do with a .NET dump unless it has the full process memory. But it's possible (and some attempts were made in the past, e.g. ClrDump) to include only specific memory regions in the dump. We can use CLRMD to determine which regions must be included -- heap, loader heaps, JIT data, etc. -- and then generate a dump that is potentially much smaller. This can be a utility that takes a list of flags (want all heap objects, want all modules, want native heap, etc.) and generates the minimal dump that can satisfy all requirements.
Check what CLRMD needs to successfully display minimal exception information in a .NET dump. Does a default WER minidump work? Looks like Procdump's default configuration is enough (without -ma).
Basic exception triage seems to be possible with what WER DumpType=1 or Procdump's default configuration generates: getting the list of threads, loaded modules, !clrstack, and !pe (small bug notwithstanding). But to get good symbols in that case the modules themselves (.exe/.dll) need to be provided to the debugger on the symbol path.
Other commands will fail spuriously, mostly because the heap is not available -- so need to add some mode that disables these commands when working with a small dump. This was done in #36.
Now working on a a slightly different approach. MiniDumpWriteDump takes a callback that tells it which memory regions to include in the dump. Before letting it do its thing, attach CLRMD to the live target, run some commands that touch all the required memory regions (e.g. enumerate objects, threads, types, etc.), and use a custom IDataReader that logs all memory accesses against the live target. Aggregate these accesses to figure out which regions we need to include (additionally, include everything reported by ClrRuntime.EnumerateMemoryRegions).