Skip to content

Query IDebugDataSpaces2/4 in the TTD adapter#1142

Draft
xusheng6 wants to merge 1 commit into
devfrom
test_dbgeng_dataspaces
Draft

Query IDebugDataSpaces2/4 in the TTD adapter#1142
xusheng6 wants to merge 1 commit into
devfrom
test_dbgeng_dataspaces

Conversation

@xusheng6

Copy link
Copy Markdown
Member

Fixes #1141.

DbgEngTTDAdapter::Start() creates its own IDebugClient7 and queries the interfaces it needs, but IDebugDataSpaces2 was only ever queried by the base class in DbgEngAdapter::ConnectToDebugServerInternal() — a path the TTD adapter never takes, since it opens the trace with OpenDumpFile(). m_debugDataSpaces2 therefore stayed nullptr for the entire TTD session, and code depending on it silently did nothing instead of failing visibly. GetMemoryMap() is the reachable case: it returns early on if (!m_debugDataSpaces2), so under TTD it never called into dbgeng at all.

This also queries IDebugDataSpaces4 on both the live-debug and TTD paths. Unlike QueryVirtual, IDebugDataSpaces4's GetValidRegionVirtual / GetNextDifferentlyValidOffsetVirtual / GetOffsetInformation do work against a TTD trace and are useful for validating whether a given address range is present.

What this does not do

It does not fix the empty memory map widget (#1132). IDebugDataSpaces2::QueryVirtual — which GetMemoryMap() walks — is unimplemented for TTD replay targets and returns E_UNEXPECTED even for an address whose bytes read back fine. WinDbg's own !address and !vprot are equally blank on a trace. Full analysis: #1132 (comment)

So this is the latent half of that investigation: worth landing on its own so the interfaces are actually available and the null-pointer path stops masking real engine behavior.

Testing

  • Live DbgEng debugging: no behavior change expected. That path already queried IDebugDataSpaces2; IDebugDataSpaces4 is purely additive.
  • Both IDebugDataSpaces2 and IDebugDataSpaces4 were confirmed to QueryInterface successfully (S_OK) against a TTD trace using the pinned WinDbg's dbgeng.dll (TTD 1.01.11, release 1.11.592.0), via a standalone harness. This matters because QUERY_DEBUG_INTERFACE throws on failure — both interfaces are long-standing and were observed present.
  • Not built in-tree: this checkout has no BN_API_PATH and no Qt 6.11.1, so the plugin was not compiled. The changes are 10 lines following the exact pattern of the adjacent QUERY_DEBUG_INTERFACE / SAFE_RELEASE lines, but CI should be the real check.

🤖 Generated with Claude Code

DbgEngTTDAdapter::Start() creates its own IDebugClient7 and queries the interfaces it
needs, but the base class only ever queries IDebugDataSpaces2 in
ConnectToDebugServerInternal(), which the TTD adapter never goes through (it opens the
trace with OpenDumpFile()). So m_debugDataSpaces2 stayed null for the whole TTD session
and anything built on it silently did nothing -- GetMemoryMap() in particular returns
early on a null check, so it never even called into dbgeng.

Also query IDebugDataSpaces4 on both the live-debug and TTD paths. Unlike QueryVirtual,
which is unimplemented for TTD replay targets, its GetValidRegionVirtual /
GetNextDifferentlyValidOffsetVirtual / GetOffsetInformation do work on a trace and are
useful for validating an address range.

This does not fix the empty memory map widget (#1132): QueryVirtual fails on TTD targets
regardless of whether the interface pointer is valid.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@xusheng6
xusheng6 marked this pull request as draft July 24, 2026 18:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DbgEngTTDAdapter::Start() never queries IDebugDataSpaces2, leaving it null for the whole TTD session

1 participant