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

[xusheng6]

DbgEngTTDAdapter::Start() creates its own IDebugClient7 and queries the interfaces it needs, but it omits IDebugDataSpaces2. The base class only ever queries that interface in DbgEngAdapter::ConnectToDebugServerInternal() (core/adapters/dbgengadapter.cpp:333), and the TTD adapter never goes through that path — it opens the trace with OpenDumpFile() instead.

Result: m_debugDataSpaces2 stays nullptr for the entire TTD session, and any code that depends on it silently does nothing rather than failing visibly.

The reachable consequence today is DbgEngAdapter::GetMemoryMap(), which begins with:

if (!this->m_debugDataSpaces2)
    return {};

so under TTD it returns an empty map without ever calling into dbgeng. That surfaces as the empty memory map widget in #1132 — though note that issue is not fixed by this: IDebugDataSpaces2::QueryVirtual is also unimplemented for TTD replay targets, so the walk fails even with a valid interface pointer (see the analysis in #1132 (comment)). This is the separate, latent half of that investigation, worth fixing on its own so the interface is available when something needs it and so the null-pointer path stops masking real behavior.

Fix

Query IDebugDataSpaces2 in DbgEngTTDAdapter::Start() (and release it in Reset()). Also adds IDebugDataSpaces4, which unlike QueryVirtual does work on TTD traces — GetValidRegionVirtual, GetNextDifferentlyValidOffsetVirtual and GetOffsetInformation all function there and are useful for validating an address range — wired on both the live-debug and TTD paths.

Verification

No behavior change is expected for live DbgEng debugging (that path already queried IDebugDataSpaces2; IDebugDataSpaces4 is additive). Under TTD, m_debugDataSpaces2/4 become non-null.

Both QueryInterface(__uuidof(IDebugDataSpaces2), ...) and IDebugDataSpaces4 were confirmed to return S_OK against a TTD trace using the pinned WinDbg's dbgeng.dll (TTD 1.01.11, release 1.11.592.0) in a standalone harness. Note QUERY_DEBUG_INTERFACE throws on failure, so this matters: both interfaces have existed since the earliest dbgeng versions we support, and both were observed available.

Not yet built in-tree.