Skip to content

SOS: activate cDAC through dbgshim - #5966

Merged
hoyosjs merged 9 commits into
dotnet:mainfrom
hoyosjs:juhoyosa/consume-changes
Aug 25, 2026
Merged

SOS: activate cDAC through dbgshim#5966
hoyosjs merged 9 commits into
dotnet:mainfrom
hoyosjs:juhoyosa/consume-changes

Conversation

@hoyosjs

@hoyosjs hoyosjs commented Aug 17, 2026

Copy link
Copy Markdown
Member

Summary

Use dbgshim as SOS's only cDAC activation path. SOS supplies the runtime module and
data target, receives a cDAC-backed IXCLRDataProcess, and registers it with ClrMD.

Remove runtime-version checks from cDAC selection. The cDAC now determines whether it
supports a target through contract validation.

Policy

Policy Behavior
PreferCDac Try cDAC, then allow DAC fallback
OnlyUseCDac Require cDAC; do not fall back
UseLegacyDac Use the DAC without trying cDAC

runtimes --usecdac sets the policy for the SOS session.

Design

  • CreateClrDataProcessFromCDac always requests CDacOnly from dbgshim, so a
    successful result is known to be cDAC-backed.
  • Runtime owns and caches the cDAC process, activation HRESULT, and lifetime.
  • RuntimeWrapper is the COM projection of Runtime used by native SOS; it does not
    independently activate cDAC.
  • Native SOS without managed hosting uses the equivalent dbgshim activation path.
  • ClrMD receives an activated cDAC interface through AddLoadedRuntime; ClrMD only
    loads the legacy DAC fallback.
  • dbgshim is packaged for every SOS RID. cDAC is packaged for every SOS RID when
    enabled.

SOS enumerates the runtime and hands the module base to dbgshim, which prefers the co-located cDAC and falls back to the legacy DAC. The resulting IXCLRDataProcess is registered with ClrMD (managed host, via DataTarget.AddLoadedRuntime) or returned to native SOS, replacing the direct cDAC LoadLibrary path.

Remove the runtime-version gate from the cDAC load policy: every runtime attempts the cDAC and the cDAC's own contract-support validation decides. Rework Runtime.CreateRuntime so a cDAC that loads but declines falls back to the in-box DAC; a forced cDAC (UseCDac) stays a hard failure rather than silently using the DAC. Extract TryCreateRuntimeFromLibrary.

Move the dbgshim managed interop (ICLRDebugging, ICLRDebuggingPolicy) from the test project into SOS.Hosting as the single product copy.

Add IClrDataProcessActivator (DebugServices) implemented by ClrDataProcessActivator (SOS.Hosting), which loads the co-located dbgshim, sets the prefer-cDAC policy, builds a runtime-bound DataTargetWrapper, and returns the IXCLRDataProcess from OpenVirtualProcess.
Add greppable 'data-access:' trace lines at every branch of the cDAC/DAC decision in both the managed ClrMD path (Runtime.CreateRuntime) and the native SOS path (RuntimeWrapper.GetClrDataProcess): seam tried, seam activated the cDAC, seam declined, no seam in host, direct cDAC tried/declined, forced-cDAC hard failure, and in-box DAC fallback. A log now shows exactly which engine served each runtime.
Remove the remaining native runtime-version check and let the cDAC validate whether it can service each target. Carry the effective cDAC policy through the hosted dbgshim activator, including a cDAC-only mode that cannot silently fall back to the DAC.

Preserve forced-cDAC rejection across the RuntimeWrapper boundary so native SOS and CLRMA do not replace it with DbgEng's DAC. Serialize per-activation dbgshim policy changes and keep the default prefer-cDAC fallback behavior for unsupported targets.
Make the IXCLRDataProcess service contract implementation-neutral and remove comments that describe callers, fallback policy, or historical behavior.

Remove the direct ClrMD cDAC load and the separate cDAC path resolver from Runtime. cDAC activation now only occurs through the registered service; ClrMD loads only the DAC fallback.
Keep the host-owned IXCLRDataProcess reference alive until the Runtime and its ClrMD services are disposed. ClrMD adds and releases its own independent reference while retaining a factory that may return the host pointer.

Allow native SOS and CLRMA to use DbgEng DAC fallback only when cDAC is not enforced.
Replace native SOS's direct cDAC LoadLibrary path with CLRCreateInstance and ICLRDebugging::OpenVirtualProcess against the dbgshim next to SOS. The native path requests cDAC-only activation and retains the legacy DAC fallback only when policy allows it.

This keeps cDAC activation available when managed hosting is disabled or fails while preserving the same support-based policy behavior.
@hoyosjs
hoyosjs marked this pull request as ready for review August 20, 2026 22:24
@hoyosjs
hoyosjs requested a review from a team as a code owner August 20, 2026 22:24
Copilot AI lite review requested due to automatic review settings August 20, 2026 22:24

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Routes SOS cDAC activation through dbgshim with policy-based DAC fallback and ClrMD runtime registration.

Changes:

  • Adds native and managed dbgshim activation paths.
  • Centralizes cDAC policy handling and removes direct cDAC loading.
  • Registers activated runtimes with ClrMD.

Reviewed changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file
File Review summary
src/SOS/Strike/util.cpp Reviewed; no final comments.
src/SOS/Strike/platform/runtimeimpl.h Reviewed; no final comments.
src/SOS/Strike/platform/runtimeimpl.cpp Moderate: restore CLR notification setup for live targets.
src/SOS/Strike/clrma/managedanalysis.cpp Reviewed; no final comments.
src/SOS/SOS.Hosting/RuntimeWrapper.cs Moderate: honor cDAC environment gates while preserving forced-policy behavior.
src/SOS/SOS.Hosting/ICLRDebuggingPolicy.cs Reviewed; no final comments.
src/SOS/SOS.Hosting/ICLRDebugging.cs Reviewed; no final comments.
src/SOS/SOS.Hosting/ClrDataProcessActivator.cs Moderate: release retained wrappers and services after failed activation and teardown.
src/SOS/inc/runtime.h Reviewed; no final comments.
src/Microsoft.Diagnostics.TestHelpers/TestHost/TestDataWriter.cs Reviewed; no final comments.
src/Microsoft.Diagnostics.DebugServices/IRuntime.cs Reviewed; no final comments.
src/Microsoft.Diagnostics.DebugServices/IClrDataProcessActivator.cs Reviewed; no final comments.
src/Microsoft.Diagnostics.DebugServices.Implementation/Runtime.cs Reviewed; no final comments.
Suppressed comments (1)

src/SOS/Strike/platform/runtimeimpl.cpp:546

  • The new CDacOnly flag is not considered by GetClrDataProcess; the failure and fallback checks below consult only s_cdacLoadPolicy. A caller passing CDacOnly while the global policy is Default therefore falls back to the DAC when dbgshim declines, despite the flag's documented no-fallback semantics (and the managed wrapper treating it as forced). Include the flag in both the activation decision and the fallback suppression checks.
            HRESULT hr = CreateClrDataProcessWithDbgShim(&m_cdacDataProcess);
            if (FAILED(hr) && s_cdacLoadPolicy == CDacLoadPolicy::UseCDac)
            {
                *ppClrDataProcess = nullptr;
                return hr;

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

Comment thread src/SOS/SOS.Hosting/ClrDataProcessActivator.cs Outdated
Comment thread src/SOS/SOS.Hosting/RuntimeWrapper.cs Outdated
Comment thread src/SOS/Strike/platform/runtimeimpl.cpp
Use dbgshim as the only cDAC activation path for managed-hosted and native SOS. Let the cDAC validate target support instead of filtering by runtime version, and preserve the configured DAC fallback policy.

Centralize cDAC process ownership and failure caching in Runtime, expose it to native SOS through RuntimeWrapper, preserve activation HRESULTs, and package dbgshim and cDAC for every SOS RID.
@hoyosjs hoyosjs changed the title SOS: activate data access through dbgshim using cDAC support policy SOS: activate cDAC through dbgshim Aug 25, 2026
@hoyosjs
hoyosjs requested a balanced review from Copilot August 25, 2026 06:14

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 19 out of 20 changed files in this pull request and generated 2 comments.

Suppressed comments (1)

src/SOS/SOS.Hosting/ClrDataProcessActivator.cs:188

  • This stores the creator reference returned by CLRCreateInstance, but ICLRDebugging calls SuppressRelease(), so neither the wrapper nor the global service ever releases it. The same reference is leaked on the policy-setup failure path. Make the activator disposable and release the shared interface at global-service teardown, while also releasing it before returning from initialization failures (the existing dbgshim tests explicitly balance these wrappers with Release()).
                ICLRDebugging clrDebugging = ICLRDebugging.Create(punk);
                hr = SetCDacLoadPolicy(clrDebugging, DbgShimCDacLoadPolicy.CDacOnly);
                if (!hr)
                {
                    Trace.TraceError($"ClrDataProcessActivator: SetCDacLoadPolicy(CDacOnly) failed (hr={hr:x8}).");
                    return null;
                }
                _clrDebugging = clrDebugging;

Comment thread src/Microsoft.Diagnostics.DebugServices.Implementation/Runtime.cs
Comment thread src/SOS/SOS.Hosting/ClrDataProcessActivator.cs
@hoyosjs
hoyosjs enabled auto-merge (squash) August 25, 2026 07:48
Comment thread src/Microsoft.Diagnostics.DebugServices/CDacLoadPolicy.cs Outdated
Remove the separate tool-defined default state. Use PreferCDac as the zero/default policy, keep OnlyUseCDac and UseLegacyDac as explicit overrides, and limit runtimes --usecdac to true, false, and prefer.
@hoyosjs
hoyosjs merged commit 213ee92 into dotnet:main Aug 25, 2026
25 checks passed
@hoyosjs
hoyosjs deleted the juhoyosa/consume-changes branch August 27, 2026 01:17
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.

4 participants