Skip to content

Test dual runtimes in cDAC-only mode - #6026

Merged
max-charlamb merged 1 commit into
dotnet:mainfrom
max-charlamb:max-charlamb/dual-runtime-cdac-only
Sep 14, 2026
Merged

Test dual runtimes in cDAC-only mode#6026
max-charlamb merged 1 commit into
dotnet:mainfrom
max-charlamb:max-charlamb/dual-runtime-cdac-only

Conversation

@max-charlamb

Copy link
Copy Markdown
Member

Summary

  • expose standalone cDAC-only mode to SOS test scripts
  • verify a dual-runtime dump can select Desktop CLR but cannot load its unsupported data-access implementation
  • retain the existing Desktop CLR stack, thread, and heap assertions for non-cDAC-only modes

Testing

  • normal DualRuntimes mode: 4 passed
  • cDAC-only DualRuntimes mode: .NET 11 row passed with the expected Desktop CLR data-access failure
  • .NET 8-10 local rows remain unsupported by standalone cDAC and fail before reaching the new assertion

Assert that Desktop CLR can be selected in a dual-runtime dump but cannot provide data access when standalone cDAC is required.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 2d5c60f7-9c89-42e6-b9fc-04ef78c8f8d8
Copilot AI lite review requested due to automatic review settings September 11, 2026 19:38
@max-charlamb
max-charlamb requested a review from a team as a code owner September 11, 2026 19:38

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.

🟢 Approval recommended

No unresolved review issues were identified.

Pull request overview

Adds cDAC-only awareness to SOS dual-runtime tests and validates the expected Desktop CLR data-access failure.

Changes:

  • Defines CDAC_ONLY for standalone cDAC tests.
  • Adjusts assertions for unsupported Desktop CLR data access.
File summaries
File Description
src/tests/SOS.UnitTests/SOSRunner.cs Adds the CDAC_ONLY script define.
src/tests/SOS.UnitTests/Scripts/DualRuntimes.script Validates cDAC-only Desktop CLR behavior.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 0
  • Review effort level: Lite

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

@max-charlamb
max-charlamb merged commit 95ac844 into dotnet:main Sep 14, 2026
26 checks passed
max-charlamb added a commit to dotnet/runtime that referenced this pull request Sep 14, 2026
Fix the runtime-diagnostics SOS test configuration so it uses a coherent
set of runtime, cDAC, and DBI artifacts.

- Build the interpreter debuggee assets when interpreter testing is
enabled.
- Publish and restore the cDAC transport package produced by the runtime
build, keeping the matching universal cDAC and DBI together.
- Continue exercising strict cDAC-only mode, with a separate forced-DAC
comparison leg.

### Strict cDAC-only coverage

The cDAC leg still passes `-dacMode cdac`. Diagnostics maps this to
`runtimes --usecdac true`, selecting `OnlyUseCDac`: supported runtimes
must use standalone cDAC and SOS may not fall back to a legacy DAC.

`DualRuntimes` also remains covered in this strict mode.
dotnet/diagnostics#6026 updates the test for the expected desktop .NET
Framework behavior: selecting the desktop runtime succeeds, but its
data-access commands must fail because desktop Framework does not
support cDAC and fallback is disabled. This preserves the multi-runtime
test without weakening the cDAC-only policy.

The separate `DAC` leg passes `-dacMode dac` and provides explicit
legacy-DAC comparison coverage.

### Matching cDAC transport package

The cDAC and universal DBI must match the runtime being tested. The
pipeline keeps them coherent as follows:

1. The shared runtime job builds CoreCLR, cDAC, and DBI together and
produces
`runtime.win-x64.Microsoft.DotNet.Cdac.Transport.<version>.nupkg`.
2. That job selects exactly one non-symbol transport package and
publishes it as `BuildArtifacts_windows_x64_Release_cdac`.
3. The strict `cDAC` job downloads that artifact into a clean workspace,
derives the exact package version from its filename, and exposes the
downloaded directory as a local NuGet source.
4. The diagnostics build receives `/p:PackageWithCDac=true`, the
filename-derived `runtimewinx64MicrosoftDotNetCdacTransportVersion`, and
`/p:RestoreAdditionalProjectSources=<downloaded artifact>`.
5. Diagnostics' `InstallNativePackages.targets` restores that exact
transport-package version and copies both `mscordaccore_universal.dll`
and `mscordbi_universal.dll` beside SOS. The runtime itself comes from
the corresponding same-build CoreCLR artifact through `liveRuntimeDir`.

As an artifact-level check, the SHA-256 of `mscordaccore_universal.dll`
inside validation build 1593212's transport package exactly matched the
copy in that build's CoreCLR artifact (`63E8DFFB...33B27B8`). The
package also contains the matching same-build `mscordbi_universal.dll`.

### Validation

- Parsed all modified YAML files successfully.
- `git diff --check` passes.
- [Runtime-diagnostics build
1593582](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1593582)
succeeded using this PR with `diagnosticsBranch=refs/pull/6026/merge`.
- Both `cDAC_windows_x64_release` and `DAC_windows_x64_release` passed.
- The cDAC leg used strict `OnlyUseCDac` together with the transport
package produced by the same runtime build.

Addresses #133282. Related to #132073 and dotnet/diagnostics#6026.

> [!NOTE]
> This pull request description was generated with GitHub Copilot.

---------

Co-authored-by: Max Charlamb <maxcharlamb@microsoft.com>
Copilot-Session: 7b2ca30d-742d-402c-8ba5-afec8b6d69a1
Copilot-Session: 54f4d112-cbd7-48a7-a105-160bb69fa22d
@max-charlamb
max-charlamb deleted the max-charlamb/dual-runtime-cdac-only branch September 14, 2026 14:46
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.

3 participants