SOS: control runtime candidate enumeration - #6010
Draft
hoyosjs wants to merge 3 commits into
Draft
Conversation
noahfalk
approved these changes
Sep 5, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Move runtime candidate selection into SOS while retaining ClrMD providers for exact
ClrInfometadata construction and legacy Desktop DAC activation.Default enumeration considers:
clr.dll,coreclr.dll,libcoreclr.so, andlibcoreclr.dylibDotNetRuntimeInfo,DotNetRuntimeContractDescriptor, orDotNetRuntimeDebugHeaderruntimes --allconsiders every module. Descriptor-bearing modules without CoreCLR'sg_dacTableare classified as NativeAOT. NativeAOT data access uses the same dbgshimOpenVirtualProcessroute 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
IDataReaderis used only forClrInfodiscovery. Production DataTargets retain the complete module list, so debugger module enumeration, DACGetImageBase, image-backed reads, and stress-log resolution are unchanged.Acceptance applications
Four standalone applications and dumps were created outside the repository:
Results
eeversionandthreadssucceed after switching to CoreCLR and then Desktop CLR. CoreCLR reports version11.0.26.41219and four threads; Desktop CLR reports version4.8.9337.0and three threads.--allfind the same runtime;clrstackanddumpheapwork. Existingclrstack -ilimitation remains.--alladditionally finds the NativeAOT module.--allside-module cases both return a liveIXCLRDataProcessthrough dbgshim when the cDAC supports the target.IXCLRDataProcesswhen the private package is paired with its matching11.0.100-rc.2.26431.116target SDK.Transitional ClrMD behavior
ClrMD enumeration remains enabled internally on each production DataTarget because the current legacy
DacLibraryrejects activation whenDataTarget.ClrVersionsis empty. SOS ignores that internal list and exposes only its candidate-controlled RuntimeService list. A future metadata-only ClrMDAddRuntime(ClrInfo)API can remove this duplicate internal enumeration and enableSkipRuntimeEnumeration=trueend to end.