Skip to content

SOS: control runtime candidate enumeration - #6010

Draft
hoyosjs wants to merge 3 commits into
dotnet:mainfrom
hoyosjs:juhoyosa/sos-runtime-enumeration
Draft

SOS: control runtime candidate enumeration#6010
hoyosjs wants to merge 3 commits into
dotnet:mainfrom
hoyosjs:juhoyosa/sos-runtime-enumeration

Conversation

@hoyosjs

@hoyosjs hoyosjs commented Sep 4, 2026

Copy link
Copy Markdown
Member

Summary

Move runtime candidate selection into SOS while retaining ClrMD providers for exact ClrInfo metadata construction and legacy Desktop DAC activation.

Default enumeration considers:

  • clr.dll, coreclr.dll, libcoreclr.so, and libcoreclr.dylib
  • the entrypoint module and same-named Windows DLL when they export DotNetRuntimeInfo, DotNetRuntimeContractDescriptor, or DotNetRuntimeDebugHeader

runtimes --all considers every module. Descriptor-bearing modules without CoreCLR's g_dacTable are classified as NativeAOT. NativeAOT data access uses the same dbgshim OpenVirtualProcess route as CoreCLR. Dbgshim resolves the module's contract descriptor and asks the co-located cDAC to activate the requested data-access interface.

A short-lived filtered IDataReader is used only for ClrInfo discovery. Production DataTargets retain the complete module list, so debugger module enumeration, DAC GetImageBase, image-backed reads, and stress-log resolution are unchanged.

Acceptance applications

Four standalone applications and dumps were created outside the repository:

  • CoreCLR + Desktop CLR in one process
  • self-contained single-file CoreCLR
  • NativeAOT main executable
  • CoreCLR main executable with a side-loaded NativeAOT shared library

Results

  • Dual runtime: default enumeration finds CoreCLR and Desktop CLR; both can be selected; heap commands work for each.
  • Native-only dual-runtime coverage: with managed SOS hosting disabled, native eeversion and threads succeed after switching to CoreCLR and then Desktop CLR. CoreCLR reports version 11.0.26.41219 and four threads; Desktop CLR reports version 4.8.9337.0 and three threads.
  • Single-file: default and --all find the same runtime; clrstack and dumpheap work. Existing clrstack -i limitation remains.
  • NativeAOT main: default enumeration finds NativeAOT.
  • NativeAOT side module: default enumeration finds CoreCLR only; --all additionally finds the NativeAOT module.
  • NativeAOT shim activation: main-module and --all side-module cases both return a live IXCLRDataProcess through dbgshim when the cDAC supports the target.
  • Private cDAC: NativeAOT main and side-module activation return a live IXCLRDataProcess when the private package is paired with its matching 11.0.100-rc.2.26431.116 target SDK.

Transitional ClrMD behavior

ClrMD enumeration remains enabled internally on each production DataTarget because the current legacy DacLibrary rejects activation when DataTarget.ClrVersions is empty. SOS ignores that internal list and exposes only its candidate-controlled RuntimeService list. A future metadata-only ClrMD AddRuntime(ClrInfo) API can remove this duplicate internal enumeration and enable SkipRuntimeEnumeration=true end to end.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants