Skip to content

Distinguish memory read failures from corrupt method tables in SOS error messages - #5680

Merged
noahfalk merged 2 commits into
mainfrom
copilot/fix-sos-dumpheap-error
Jan 12, 2026
Merged

Distinguish memory read failures from corrupt method tables in SOS error messages#5680
noahfalk merged 2 commits into
mainfrom
copilot/fix-sos-dumpheap-error

Conversation

Copilot AI commented Jan 9, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

SOS commands like !dumpheap -stat throw identical error messages for two distinct failure modes: memory read failures vs. successfully reading a zero/invalid MethodTable. These require different diagnostic approaches.

Changes

  • Memory read failure (DataRead): "Failed to read memory at Object %s."
  • Corrupt MethodTable (HeapCorruption): "Object %s has a corrupt method table."

Modified Object::GetMT() in src/SOS/Strike/sos.cpp:

if (FAILED(MOVE(temp, mAddress)))
    sos::Throw<DataRead>("Failed to read memory at Object %s.", DMLListNearObj(mAddress));

if (temp == (TADDR)0)
    sos::Throw<HeapCorruption>("Object %s has a corrupt method table.", DMLListNearObj(mAddress));

Users can now immediately determine whether the issue is with dump file integrity/memory access or actual heap corruption in the target process.

Original prompt

This section details on the original issue you should resolve

<issue_title>SOS dumpheap error doesn't distinguish missing memory from corrupt memory</issue_title>
<issue_description>A user might run the SOS command "!dumpheap -stat" and see an error message:

Object <exec cmd="!ListNearObj /d 0000017ad8c00028">0000017ad8c00028</exec> has an invalid method table

This error message occurs when SOS observes a zero valued MethodTable for an object, but it doesn't distinguish whether the memory failed to be read or the memory was successfully read and the MethodTable pointer was bad. It would be very useful to distinguish those because the steps to resolve each of those issues is completely different.

Internally it appears SOS does actually distinguish the two cases, but then it emits an identical error message for both so the user doesn't know which one occured.

diagnostics/src/SOS/Strike/sos.cpp

Lines 105 to 109 in 6efc893

if (FAILED(MOVE(temp, mAddress)))
sos::Throw<DataRead>("Object %s has an invalid method table.", DMLListNearObj(mAddress));
if (temp == (TADDR)0)
sos::Throw<HeapCorruption>("Object %s has an invalid method table.", DMLListNearObj(mAddress));

</issue_description>

Comments on the Issue (you are @copilot in this section)

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

Copilot AI changed the title [WIP] Fix SOS dumpheap error to distinguish memory issues Distinguish memory read failures from corrupt method tables in SOS error messages Jan 9, 2026
Copilot AI requested a review from noahfalk January 9, 2026 08:32
noahfalk
noahfalk reviewed Jan 9, 2026
View reviewed changes

@noahfalk noahfalk left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hoyosjs - this look good to you? It seems about right to me.

hoyosjs
hoyosjs approved these changes Jan 10, 2026
View reviewed changes

@hoyosjs hoyosjs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's only one case where this is... not great. LLDB is not the most consistent here. It will return

diagnostics/src/SOS/Strike/platform/datatarget.cpp

Line 154 in 6efc893

// LLDB synthesizes memory (returns 0's) for missing pages (in this case the missing metadata pages)
. I wonder if we should make it clear in the message.

@noahfalk
noahfalk marked this pull request as ready for review January 12, 2026 23:54
Copilot AI review requested due to automatic review settings January 12, 2026 23:54
@noahfalk
noahfalk requested a review from a team as a code owner January 12, 2026 23:54
@noahfalk
noahfalk merged commit 82d1e68 into main Jan 12, 2026
20 of 21 checks passed
@noahfalk

noahfalk commented Jan 12, 2026

Copy link
Copy Markdown
Member

@hoyosjs - thanks for the heads up about LLDB. I went ahead and committed as-is because I think this moves us in the right direction for other debuggers despite the still not great experience for LLDB.

@hoyosjs
hoyosjs deleted the copilot/fix-sos-dumpheap-error branch January 17, 2026 00:38
@dotnet-maestro dotnet-maestro Bot mentioned this pull request Jan 20, 2026
Merged
@github-actions github-actions Bot locked and limited conversation to collaborators Feb 16, 2026
Copilot AI removed the request for review from Copilot March 23, 2026 22:04
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Reviewers

@noahfalk noahfalk noahfalk left review comments
@hoyosjs hoyosjs hoyosjs approved these changes

Assignees

@noahfalk noahfalk

Copilot code review Copilot

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

SOS dumpheap error doesn't distinguish missing memory from corrupt memory

3 participants

@noahfalk @hoyosjs