[GH-ISSUE #2381] [Design] Inspect recorded .NET dump stacks and heaps with matching runtime/DAC provenance #795

New issue

Open

opened 2026-10-15 18:28:29 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:28:29 +00:00

Owner

Originally created by @matbrgz on GitHub (Oct 12, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/2381

Analyst question

From an already recorded dump of my .NET process, which managed stacks, exceptions and bounded heap/root facts explain its failure or memory growth?

Native minidump work (#2355) and recorded EventPipe (#2370) cannot establish equivalent managed heap or stack facts. Static assembly inspection does not observe the crashed runtime.

Proposed lane

Use caller-selected recorded dumps and explicitly configured local analysis tools/runtime support files. Start with a narrow, documented CoreCLR/host/architecture matrix.

Bind dump digest, available capture metadata, observed runtime/modules, analyzer identity and DAC/runtime support-file identities.
Require established runtime compatibility; report missing/mismatched DAC, partial dump memory and unsupported architectures distinctly.
Expose focused managed thread/stack, exception, object/type and bounded heap/root queries with source evidence and coverage.
Keep observed runtime handles separate from assembly metadata tokens and from addresses in other captures.
Use an admitted command subset. Raw debugger commands, scripts, live collection and arbitrary file exports are separate authority.
No automatic target launch, attachment, dump collection or symbol/source downloads. Running a caller-configured host analyzer remains a declared effect.

Acceptance

Own source-built .NET fixtures generate crash and retained-object dumps outside the inspection operation.
Actual analyzer tests establish stacks and known retained objects for each advertised runtime/platform.
Wrong DAC/runtime, truncated dump and missing memory return partial/unavailable facets rather than empty stacks or heaps.
Paging/bounds apply to heap enumeration and root paths; cancellation cleans the owned analyzer.
CLI/MCP retain dump/module/provider provenance and explicit unknown source associations.
One recorded-managed-dump spec/plan and maintainer provider decision precede substantial implementation.

Primary references

Originally created by @matbrgz on GitHub (Oct 12, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/2381 [![Type: Architecture / RFC](https://img.shields.io/badge/type-architecture_%2F_RFC-darkred.svg?style=flat-square)](https://github.com/morluto/rea) [![Status: Proposed](https://img.shields.io/badge/status-proposed-blue.svg?style=flat-square)](https://github.com/morluto/rea) [![Ecosystem: REA](https://img.shields.io/badge/ecosystem-morluto%2Frea-8A2BE2.svg?style=flat-square)](https://github.com/morluto/rea) ## Analyst question From an already recorded dump of my .NET process, which managed stacks, exceptions and bounded heap/root facts explain its failure or memory growth? Native minidump work (#2355) and recorded EventPipe (#2370) cannot establish equivalent managed heap or stack facts. Static assembly inspection does not observe the crashed runtime. ## Proposed lane Use caller-selected recorded dumps and explicitly configured local analysis tools/runtime support files. Start with a narrow, documented CoreCLR/host/architecture matrix. - Bind dump digest, available capture metadata, observed runtime/modules, analyzer identity and DAC/runtime support-file identities. - Require established runtime compatibility; report missing/mismatched DAC, partial dump memory and unsupported architectures distinctly. - Expose focused managed thread/stack, exception, object/type and bounded heap/root queries with source evidence and coverage. - Keep observed runtime handles separate from assembly metadata tokens and from addresses in other captures. - Use an admitted command subset. Raw debugger commands, scripts, live collection and arbitrary file exports are separate authority. - No automatic target launch, attachment, dump collection or symbol/source downloads. Running a caller-configured host analyzer remains a declared effect. ## Acceptance - [ ] Own source-built .NET fixtures generate crash and retained-object dumps outside the inspection operation. - [ ] Actual analyzer tests establish stacks and known retained objects for each advertised runtime/platform. - [ ] Wrong DAC/runtime, truncated dump and missing memory return partial/unavailable facets rather than empty stacks or heaps. - [ ] Paging/bounds apply to heap enumeration and root paths; cancellation cleans the owned analyzer. - [ ] CLI/MCP retain dump/module/provider provenance and explicit unknown source associations. - [ ] One recorded-managed-dump spec/plan and maintainer provider decision precede substantial implementation. ## Primary references - [dotnet-dump analysis and managed-only boundaries](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/dotnet-dump) - [SOS inspection commands](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/sos-debugging-extension) - [Runtime files needed for Linux dump analysis](https://learn.microsoft.com/en-us/dotnet/core/diagnostics/debug-linux-dumps)

bsakaguchi added the

labels

2026-10-15 18:28:29 +00:00

bsakaguchi commented

2026-10-15 18:28:30 +00:00

Author

Owner

@matbrgz commented on GitHub (Oct 12, 2026):

Design & Capability Matrix Notes

Objective (ELI5):
Examine captured .NET crash dumps (Windows minidump or Linux ELF core dump) using exact matching runtime and DAC (Data Access Component / mscordaccore.dll / libmscordaccore.so) without heuristic memory corruption.

Provider Boundaries:

The bridge should wrap Microsoft SOS / dotnet-dump through an isolated worker subprocess.
Verification must require exact version alignment between the recorded dump's CLR build and the host DAC library; mismatch must fail with dac_version_mismatch rather than producing partial incorrect stack unwinds.

@matbrgz commented on GitHub (Oct 12, 2026): ### Design & Capability Matrix Notes **Objective (ELI5):** Examine captured .NET crash dumps (Windows minidump or Linux ELF core dump) using exact matching runtime and DAC (Data Access Component / `mscordaccore.dll` / `libmscordaccore.so`) without heuristic memory corruption. **Provider Boundaries:** - The bridge should wrap Microsoft SOS / `dotnet-dump` through an isolated worker subprocess. - Verification must require exact version alignment between the recorded dump's CLR build and the host DAC library; mismatch must fail with `dac_version_mismatch` rather than producing partial incorrect stack unwinds.

bsakaguchi referenced this issue

2026-10-16 21:16:13 +00:00

[PR #795] [MERGED] fix(cli): preserve unsupported historical-source imports #2245

bsakaguchi added

enhancement

and removed

enhancement

labels

2026-10-31 00:29:37 +00:00