Expand dotnet-dump documentation with actionable memory analysis and diagnostics

[Copilot]

The dotnet-dump documentation covered only basic exception analysis, which is already available in application logs. Users need guidance for actual diagnostic scenarios: identifying memory leaks, finding deadlocks, and analyzing heap allocations.

Added sections

• Memory leak analysis

  • Identifying largest objects and highest instantiation counts with dumpheap -stat
  • Filtering by namespace/assembly using -type for actionable attribution (e.g., MyCompany.Data consuming 7MB, not just "System.String consuming 19MB globally")
  • Tracing object references with gcroot to find holding classes
  • Size-based filtering with -min/-max options

• Deadlock detection

  • Using threads, clrstack -all, and syncblk to identify lock contention
  • Cross-reference to comprehensive debug-deadlock.md tutorial

• Advanced scenarios

  • Comparing dumps over time to identify growth patterns
  • Deep-diving specific object types with dumpobj

Example of actionable namespace-based memory analysis:

> dumpheap -type MyCompany.Data -stat

Statistics:
              MT    Count    TotalSize Class Name
00007f6c21625038    15000      3600000 MyCompany.Data.CustomerRecord
00007f6c21625040     8000      2560000 MyCompany.Data.OrderHistory
00007f6c21625048     2000       960000 MyCompany.Data.ProductCache
Total 25000 objects, 7120000 bytes

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Need more coverage to analyze memory leaks and memory allocations</issue_title>
<issue_description>The current documentation only talks about an exception and stack trace. These are typically already present in logs, so getting the same information via the far more tedious stack dump route is not useful.

Instead what's required is better documentation for the more typical stack dump problems, like:

1. identifying the largest objects
2. identifying the highest number of instantiations
3. find deadlocked threads
4. the setup required to get all symbols to be properly displayed (no UNKNOWNs)
5. the general approach to figure out which module within a larger process is leaking memory.
   and so on

And by identifying, I don't mean just (e.g.) 200 MB of System.String[] globally but something more actionable like 190 MB of System.String[]s within the MyProject.Data.DbManager namespace.

Also, are there any GUI tools, like how ddd or KDbg wrap gdb? Or a VSCode/VS extension?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 9a269a64-0a27-27d3-a509-47b9a0d114bf
• Version Independent ID: 49ff97ff-b39a-5ae8-e4b8-81a4f8eab50c
• Content: dotnet-dump - .NET Core
• Content Source: docs/core/diagnostics/dotnet-dump.md
• Product: dotnet-core
• GitHub Login: @sdmaclea
• Microsoft Alias: stmaclea</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Need more coverage to analyze memory leaks and memory allocations #17074

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

---

Internal previews

📄 File	🔗 Preview link
docs/core/diagnostics/dotnet-dump.md	Dump collection and analysis utility (dotnet-dump)