cDAC stress build break: match GetObjectStringData's quirky dac behavior by leculver · Pull Request #129297 · dotnet/runtime

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

leculver · 2026-06-11T16:17:18Z

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the cDac: fix the weird behavior that we don't depend on in the legacy dac, and assert similar data here.

This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865.

dotnet-policy-service · 2026-06-11T16:18:37Z

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

Copilot

Pull request overview

Updates the legacy cDAC ISOSDacInterface.GetObjectStringData implementation to better match the legacy DAC’s HRESULT behavior for length-only string queries by returning E_INVALIDARG while still reporting the required buffer length.

Changes:

After copying/string-length computation via OutputBufferHelpers.CopyStringToBuffer, return E_INVALIDARG when there is no output buffer (stringData == null || count == 0).
Add an explanatory comment documenting the legacy DAC parity intent.

Show a summary per file

File	Description
src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs	Adjusts `GetObjectStringData` HRESULT for length-only queries to align with legacy DAC behavior.

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when no output buffer is available (count == 0) even on a valid string, while still populating *pNeeded. The cDAC implementation returned S_OK, which trips the cDAC-vs-DAC HResult parity assert when CLRMA (clrma under dotnet-dump) sizes an exception string via GetObjectStringData(obj, 0, nullptr, &needed). Mirror the DAC: validate args as it does (so a non-null buffer with count == 0 still reports the needed size), populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG when count == 0. CLRMA explicitly ignores that HRESULT and uses the reported size. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 1/1 changed files
Comments generated: 1

Invoke the legacy DAC with the same stringData/pNeeded nullness the caller passed to the cDAC, so the debug HRESULT comparison is apples-to-apples and can't manufacture a spurious divergence from substituted arguments. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng it Rather than tolerating the divergence via AllowCdacSuccess, fix the legacy DAC: ClrDataAccess::GetObjectStringData no longer returns E_INVALIDARG for a size-only query (no output buffer) on a valid string -- it reports the needed size via *pNeeded and succeeds, matching the cDAC. The cDAC debug parity check returns to the default validation mode. Also mirror the caller's stringData/pNeeded nullness into the legacy DAC call in the debug validation, and derive the content-compare length from the cDAC string (neededLocal is only populated when a size-out is requested), avoiding an out-of-range span when pNeeded is null. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot

Copilot's findings

Files reviewed: 2/2 changed files
Comments generated: 2

…ior (#129297) The legacy DAC (ClrDataAccess::GetObjectStringData) returns E_INVALIDARG when called on a valid string with no output buffer (stringData == null or count == 0), while still populating *pNeeded. The cDAC implementation returned S_OK in that case, which trips the cDAC-vs-DAC HResult parity assert (SOSDacImpl.cs ValidateHResult) when clrma sizes an exception string. Mirror the DAC: populate *pNeeded via CopyStringToBuffer, then return E_INVALIDARG for the no-buffer case. This fixes the build/test-break in the cDac introduced by dotnet/diagnostics#5865. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

CopilotAI review requested due to automatic review settings June 11, 2026 16:17

leculver added the area-Diagnostics-cdac label Jun 11, 2026

Copilotstarted reviewing on behalf of leculver June 11, 2026 16:17 View session

leculver requested a review from steveisok June 11, 2026 16:17

dotnet-policy-serviceBot assigned leculver Jun 11, 2026

leculver mentioned this pull request Jun 11, 2026
Add CLRMA diagnostic command runnable under dotnet-dump dotnet/diagnostics#5865
Merged

leculver changed the title ~~cDAC: GetObjectStringData returns E_INVALIDARG for length-only queries~~cDAC stress build break: match GetObjectStringData's quirky dac behaviorJun 11, 2026

CopilotAI reviewed Jun 11, 2026
View reviewed changes

Comment threadsrc/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs Outdated

leculver force-pushed the cdac-getobjectstringdata-invalidarg branch from 5de372f to 629af16Compare June 11, 2026 16:26

rcj1 reviewed Jun 11, 2026
View reviewed changes

Comment threadsrc/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs Outdated

Use AllowCdacSuccess instead of matching the quirk
f4540e3

CopilotAI review requested due to automatic review settings June 11, 2026 16:47

Copilotstarted reviewing on behalf of leculver June 11, 2026 16:47 View session

CopilotAI reviewed Jun 11, 2026
View reviewed changes

Comment threadsrc/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs Outdated

max-charlamb approved these changes Jun 11, 2026
View reviewed changes

leculver enabled auto-merge (squash) June 11, 2026 17:30

CopilotAI review requested due to automatic review settings June 11, 2026 18:35

Copilotstarted reviewing on behalf of leculver June 11, 2026 18:35 View session

CopilotAI reviewed Jun 11, 2026
View reviewed changes

Comment threadsrc/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/SOSDacImpl.cs
Comment threadsrc/coreclr/debug/daccess/request.cpp

steveisok approved these changes Jun 11, 2026
View reviewed changes

rcj1 approved these changes Jun 11, 2026
View reviewed changes

leculver merged commit c8f7ed2 into dotnet:mainJun 11, 2026
128 of 130 checks passed

build-analysisBot mentioned this pull request Jun 11, 2026
[browser][coreCLR] Wasm.Console.Node.Sample - undefined symbol: SystemInteropJS_GetManagedStackTrace #129229
Closed

leculver deleted the cdac-getobjectstringdata-invalidarg branch June 12, 2026 00:24

dotnet-maestroBot mentioned this pull request Jun 12, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7196
Merged

rcj1 mentioned this pull request Jun 12, 2026
[cDAC]: Implement GetTypedByRefInfo, GetStringData, GetArrayData, GetBasicObjectInfo #129200
Merged

dotnet-milestone-botBot added this to the 11.0-preview6 milestone Jun 17, 2026

github-actionsBot locked and limited conversation to collaborators Jul 18, 2026