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

[Copilot]

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)

• Fixes SOS dumpheap error doesn't distinguish missing memory from corrupt memory #5679

---

💡 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.

[noahfalk]

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

[hoyosjs]

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.