[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. I'm not sure when this broke, but it appears that mscordaccore_universal.dll was being installed in the wrong location. It seems that SOS is looking in the sharedFramework directory, so I included the cDAC dll there as well.

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)

[Copilot]

[nitpick] Ensure that moving the installation destination to sharedFramework is well documented to clarify its relation to SOS expectations and to avoid any future confusion.

Suggested change

	<InstallRuntimeComponentDestination Include="." />
	<InstallRuntimeComponentDestination Include="." />
	<!-- The 'sharedFramework' destination is used for runtime components when the RuntimeFlavor is 'coreclr'.
	This aligns with SOS expectations, ensuring that runtime components are correctly installed and accessible
	within the shared framework. Future changes to this destination should consider its impact on SOS and runtime behavior. -->

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

👍

[am11]

@max-charlamb Just curious, the comment on this method mentions it’s a legacy entrypoint. What’s the modern or recommended alternative for cDAC? And what would it take to switch over to it?