[cDAC] Ensure cDAC is used in test runs

[max-charlamb]

While validating #117088, I found that the cDAC was not actually being invoked in the test runs. This broke when the cdac dll's name was changed. I updated externals.csproj to include the new name.

The cDAC entrypoint through the brittle DAC (DOTNET_ENABLE_CDAC=1) fails back to the DAC silently if the cDAC is not found. To prevent this from happening in the future, I also modified this behavior to fail if the cDAC is requested but cannot be found.

Now that the CI run is testing the cDAC properly, it found two issues.

• AMD64Unwinder had an issue where it wasn't sign-extending a value that should be sign-extended.
• Discrepancies around initial ContextFlag values differing from the DAC caused by varying behavior of underlying CLRDataTarget implementations.

[dotnet-policy-service]

Tagging subscribers to this area: @steveisok, @dotnet/dotnet-diag
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This pull request ensures that the cDAC is properly used in test runs by installing the cDAC DLL into the sharedFramework directory and by updating error handling to fail if the cDAC cannot be created.

• Update the installation destination in the mscordaccore_universal.csproj to install into sharedFramework when using coreclr.
• Add missing PlatformManifestFileEntry items for cDAC DLLs in Directory.Build.props.
• Update daccess.cpp to return an error (E_FAIL) if creating the cDAC interface fails.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/native/managed/cdac/mscordaccore_universal/mscordaccore_universal.csproj	Adjusts the installation destination to sharedFramework.
src/installer/pkg/sfx/Microsoft.NETCore.App/Directory.Build.props	Adds manifest entries for the cDAC libraries.
src/coreclr/debug/daccess/daccess.cpp	Introduces an early failure when the cDAC interface creation returns nullptr.

Comments suppressed due to low confidence (2)

src/installer/pkg/sfx/Microsoft.NETCore.App/Directory.Build.props:118

• [nitpick] If cDAC usage is conditional, consider adding a Condition attribute to these manifest entries to ensure they are only included when necessary.

    <PlatformManifestFileEntry Include="mscordaccore_universal.dll" IsNative="true" />

src/coreclr/debug/daccess/daccess.cpp:7050

• [nitpick] Consider using a more descriptive error code or adding logging to indicate that cDAC interface creation failed, which may help with debugging in case of issues.

            if (cdacInterface == nullptr)

[am11]

It seems that SOS is looking in the sharedFramework directory, so I included the cDAC dll there as well.

Explains why tests started failing https://dev.azure.com/dnceng-public/public/_build/results?buildId=1080586&view=ms.vss-test-web.build-test-results-tab 🙂

Should we add linux and osx legs too in runtime-diagnostics pipeline in case there are similar surprises?

[max-charlamb]

It seems that SOS is looking in the sharedFramework directory, so I included the cDAC dll there as well.

Explains why tests started failing https://dev.azure.com/dnceng-public/public/_build/results?buildId=1080586&view=ms.vss-test-web.build-test-results-tab 🙂

Should we add linux and osx legs too in runtime-diagnostics pipeline in case there are similar surprises?

Yes, I looked into these issues and have addressed them. I will probably move them to a different PR before merging.

We are working on including other platforms legs. This requires some refactoring of the diagnostic repo pipelines that do not currently run on helix.

[am11]

👍

[max-charlamb]

/ba-g Failing/hanging runtime tests are unrelated to cDAC changes