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

• ClrDataAccess::Initialize removed the platform-mismatch validation (GetPlatform + CORDBG_E_INCOMPATIBLE_PLATFORMS). There doesn’t appear to be a replacement check in daccess/, so a mismatched DAC/target combination could proceed further and fail later with harder-to-diagnose memory read errors/crashes instead of a clear incompatibility HRESULT.

HRESULT
ClrDataAccess::Initialize(void)
{
    HRESULT hr;
    CLRDATA_ADDRESS base = { 0 };

    // Get the current DLL base for mscorwks globals.
    // In case of multiple-CLRs, there may be multiple dlls named "mscorwks".
    // code:OpenVirtualProcess can take the base address (clrInstanceId) to select exactly
    // which CLR to is being target. If so, m_globalBase will already be set.
    //

    if (m_globalBase == 0)
    {
        // Caller didn't specify which CLR to debug, we should be using a legacy data target.
        if (m_pLegacyTarget == NULL)
        {
            DacError(E_INVALIDARG);
            UNREACHABLE();
        }

        ReleaseHolder<ICLRRuntimeLocator> pRuntimeLocator(NULL);
        if (m_pLegacyTarget->QueryInterface(__uuidof(ICLRRuntimeLocator), (void**)&pRuntimeLocator) != S_OK || pRuntimeLocator->GetRuntimeBase(&base) != S_OK)
        {
            IfFailRet(m_pLegacyTarget->GetImageBase(TARGET_MAIN_CLR_DLL_NAME_W, &base));
        }

        m_globalBase = TO_TADDR(base);
    }

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs:5764

• Consider initializing the output struct to a known default value before populating individual fields. As written, if an exception occurs after setting Arch but before OS/PointerSize, callers could observe partially-updated data even when a failure HRESULT is returned.

            if (pTargetInfo is null)
                throw new ArgumentException("Output pointer cannot be null.", nameof(pTargetInfo));
            Contracts.IRuntimeInfo runtimeInfo = _target.Contracts.RuntimeInfo;

            pTargetInfo->Arch = runtimeInfo.GetTargetArchitecture() switch

src/coreclr/debug/di/rspriv.h:11400

• AlignAddressForType now unconditionally calls CordbType::RequiresAlign8. On targets where FEATURE_64BIT_ALIGNMENT is not enabled, the DAC side (DacDbiInterfaceImpl::RequiresAlign8) throws E_NOTIMPL, causing IfFailThrow here to throw unexpectedly during varargs argument walking. This helper should be a no-op unless the target architecture actually uses FEATURE_64BIT_ALIGNMENT (currently ARM and WASM).

inline void AlignAddressForType(CordbType* pArgType, CORDB_ADDRESS& argBase)
{
    BOOL align = FALSE;
    IfFailThrow(pArgType->RequiresAlign8(&align));

src/coreclr/debug/di/process.cpp:8174

• GetTargetOpcodeSize doesn’t handle kArchWasm, even though IDacDbiInterface::TargetArchitecture includes it and debug/inc/wasm/primitives.h defines a 1-byte breakpoint instruction. As-is, any path that needs opcode sizing on Wasm will hit the default case and return E_NOTIMPL.

    switch (targetInfo.arch)
    {
        case IDacDbiInterface::kArchX86:
        case IDacDbiInterface::kArchAMD64:
            *pcbSize = 1;
            break;

src/coreclr/debug/di/cordb.cpp:474

• Same issue as the corresponding DbiGetThreadContext guard above: Unix builds should keep the local-debugging exclusion (previously via SUPPORT_LOCAL_DEBUGGING) so this doesn't try to use PAL SetThreadContext for remote scenarios.

{
#if !defined(HOST_ARM) || defined(FEATURE_DBGIPC_TRANSPORT_DI) || defined(__ANDROID__)
    _ASSERTE(!"Can't use local GetThreadContext remotely, this needed to go to datatarget");
    return FALSE;

src/coreclr/debug/di/rspriv.h:11400

• AlignAddressForType used to be a true no-op except on platforms that need 8-byte argument alignment (historically ARM32 via FEATURE_64BIT_ALIGNMENT). After this change it calls into DAC for every non-x86 target, which adds avoidable overhead (and can now throw) on architectures where this alignment adjustment is unnecessary. Consider gating the alignment computation on the target architecture so the helper stays a no-op for the common case.

    BOOL align = FALSE;
    IfFailThrow(pArgType->RequiresAlign8(&align));

    if (align)
        argBase = ALIGN_ADDRESS(argBase, 8);

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs:5799

• GetTargetInfo writes to an output pointer but does not initialize the output struct on failure paths (exceptions are caught and converted to HRESULT). This can leave the caller with partially-initialized data if an exception occurs mid-way; initialize the output to default once the pointer is validated.

            if (pTargetInfo is null)
                throw new ArgumentException("Output pointer cannot be null.", nameof(pTargetInfo));
            Contracts.IRuntimeInfo runtimeInfo = _target.Contracts.RuntimeInfo;

src/coreclr/debug/di/valuehome.cpp:212

• In release builds, the pointer-size invariant in the 8-byte case is only asserted, so if this path is ever hit on a non-64-bit target it will silently proceed and truncate/produce incorrect results. Consider turning the pointer-size check into a real failure (and keep the assert as a debug aid).

                IfFailThrow(m_pFrame->GetProcess()->GetTargetInfo(&targetInfo));
                _ASSERTE(targetInfo.pointerSize == 8);
                extendedVal = (SSIZE_T) *(INT64*)newValue.StartAddress();
                break;

src/coreclr/debug/di/valuehome.cpp:235

• In release builds, the pointer-size invariant in the 8-byte case is only asserted, so if this path is ever hit on a non-64-bit target it will silently proceed and truncate/produce incorrect results. Consider turning the pointer-size check into a real failure (and keep the assert as a debug aid).

                IfFailThrow(m_pFrame->GetProcess()->GetTargetInfo(&targetInfo));
                _ASSERTE(targetInfo.pointerSize == 8);
                extendedVal = (SIZE_T) *(UINT64*)newValue.StartAddress();
                break;

src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs:5832

• In the DEBUG parity check, the legacy call always uses a non-null local buffer. If this method returns E_INVALIDARG due to a null pTargetInfo, hrLocal will be S_OK (because &targetInfoLocal is non-null) and Debug.ValidateHResult will assert even though both implementations would return E_INVALIDARG for a null output pointer.

Consider passing a null pointer through to the legacy implementation when pTargetInfo is null, while still using a local buffer for the successful case, so the parity check compares like-for-like HRESULTs.

        if (_legacy is not null)
        {
            TargetInfo targetInfoLocal;
            int hrLocal = _legacy.GetTargetInfo(&targetInfoLocal);
            Debug.ValidateHResult(hr, hrLocal);
            if (hr == HResults.S_OK)