SOS: control runtime candidate enumeration

[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.

[max-charlamb]

It looks like this enumerates the entire dump's modules again. Could we instead add a DataTarget.AddRuntime(ClrInfo) API to ClrMD, similar to AddLoadedRuntime, and use it here?

AddLoadedRuntime already contains the validation, locking, replacement, and duplicate-handling behavior required to register a host-discovered runtime:

https://github.com/microsoft/clrmd/blob/1ac2ef003da03d39ead37c9c1ab9c1e3afe4858e/src/Microsoft.Diagnostics.Runtime/DataTarget.cs#L68-L146

This would avoid rerunning ClrMD runtime discovery on every final DataTarget. SOS would perform candidate-controlled discovery once, then register the already-selected metadata on each complete reader target.