[hoyosjs]

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 or DotNetRuntimeContractDescriptor

runtimes --all passes every module to the registered ClrMD providers. Additional IRuntimeProvider implementations can append runtimes to the runtime service without changing the public candidate provider.

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

Two standalone applications and dumps were created outside the repository:

• CoreCLR + Desktop CLR in one process
• self-contained single-file CoreCLR

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.

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.