search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.27k stars 4.73k forks source link

Support for MiniDumpWithIndirectlyReferencedMemory #45549

Open pr8x opened 3 years ago

pr8x commented 3 years ago

It seems that the Win32 MiniDumpWithIndirectlyReferencedMemory flag is only working for native memory, but not for managed. I don't really know how dbghelp interacts with the DAC, but apparently it does provide ways to enumerate memory regions etc. (see https://github.com/dotnet/runtime/issues/1269#issuecomment-572715660) Would it be possible to add support for this flag somehow?

Also: Is there a way - from native code - to enumerate CLR memory regions so I can manually include them with the MemoryCallback callback?

Dotnet-GitSync-Bot commented 3 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

ghost commented 3 years ago

Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.

Issue Details
It seems that the Win32 `MiniDumpWithIndirectlyReferencedMemory` flag is only working for native memory, but not for managed. I don't really know how dbghelp interacts with the DAC, but apparently it does provide ways to enumerate memory regions etc. (see https://github.com/dotnet/runtime/issues/1269#issuecomment-572715660) Would it be possible to add support for this flag somehow? Also: Is there a way - from native code - to enumerate CLR memory regions so I can manually include them with the `MemoryCallback` callback?
Author: pr8x
Assignees: -
Labels: `area-Diagnostics-coreclr`, `feature request`, `untriaged`
Milestone: -
tommcdon commented 3 years ago

@hoyosjs @mikem8361

mikem8361 commented 3 years ago

I don't know all the details of MiniDumpWithIndirectlyReferencedMemory (are docs say "Include pages with data referenced by locals or other stack memory. ") but you are right it only works for native memory. The Windows MiniDumpWriteDump API uses the DAC (mscordaccore.dll) ICLRDataEnumMemoryRegions::EnumMemoryRegions() API to get the processes managed state. You can call this API directly to do the managed memory/state enumeration if that is what you are asking (see crashinfo.cpp for an example).

If you are asking for this flag to be added to the .NET Core's createdump code for Windows, the flags we picked should give us the type of dump was requested (Triage, Heap, Full, etc). If you think one of these heap "types" needs this flag, let me know and I'll look into it.

pr8x commented 3 years ago

How exactly is MiniDumpWriteDump invoking the DAC actually? Is it just hardcoded to use EnumMemoryRegions? I fiddled around with the ClrMD library a bit and tried to manually include the CLR memory pages into the dump. I am basically doing what the "minidumper" utility (https://github.com/goldshtn/minidumper/blob/master/DumpWriter/DumpWriter.cs) is doing. I didn't have much success yet though. Visual Studio complains that it's missing information in the dump to start managed debugging.

Having support for MiniDumpWithIndirectlyReferencedMemory in createdump would be quite fantastic as both Heap and Full dump types can become quite large. Do you have any practical example of scanning for stack-referenced heap memory (Preferably using ClrMD since I already have a project setup for that)?

mikem8361 commented 3 years ago

Windows has some "magic" that looks for the DAC (using resources in coreclr.dll to indicate there is a minidump "auxiliary" data providers), loads it and calls the EnumMemoryRegions API. The DAC has to be properly signed with a Microsoft cert before Windows will load it.

I haven't actually tried adding MiniDumpWithIndirectlyReferencedMemory to the Windows createdump to see how much it impacts the size of Heap and Full dumps. It shouldn't affect Full dumps because it should already includes all memory. And I'm hesitant to add it to Heap dumps because of any size increase.

I don't have any examples of stack-referenced heap memory.

It sounds like the reason you are writing your own minidump utility is that something is missing from the createdump generated Heap dumps? If you can give me some specific details on what managed state (like method locals, variables or types) is missing we can try to fix the DAC memory enumeration in the next release.

pr8x commented 3 years ago

haven't actually tried adding MiniDumpWithIndirectlyReferencedMemory

I doubt that's gonna be very helpful on its own. It would require some custom logic to traverse stack memory (and referenced objects) to make it work reliably.

It sounds like the reason you are writing your own minidump utility is that something is missing from the createdump generated Heap dump

The problem is simply that heap and full dumps are too big. I am looking for ways to reduce the size of dumps by only including memory that is really needed to reconstruct the stack and inspect referenced objects etc. The problem is I really don't know which memory areas I need to include into the dump to achieve this.

mikem8361 commented 3 years ago

It is hard to know what memory areas to include which is why the DAC's EnumMemoryRegions is so complicate internally.

In the end, it sounds like Triage dumps don't have enough memory (they were designed just for analysis in Watson so only stacks, threads and the exception that caused the crash are included) and Heap dumps are too big.