Heap Corruption Investigation

Load windbg-diagnostic-method first if it is not already loaded in this conversation, and apply it throughout for evidence ranking, hypothesis testing, confidence calibration, independent review, and report validation. This skill adds the bug-family-specific commands and evidence requirements.

Detection and limits

Look for STATUS_HEAP_CORRUPTION (0xC0000374), Application Verifier stops, or failures in heap allocate/free/reallocate paths in an application, service, or user-mode driver host such as an UMDF host process. A crash inside the allocator may be the first detection of an earlier bad write, not the faulty operation. Distinguish corruption from allocation failure; for the latter use windbg-user-virtual-memory-exhaustion.

Allocation/free history depends on how the process was instrumented and which pages were captured. A missing history is a limitation, not proof of a leak or use-after-free.

Workflow

1. Decode the stop

.exr -1
.ecxr
!analyze -v
k

Record the stop reason, corrupted block, corruption address, and the operation that detected the damage. If a verifier stop frame has parameter/local symbols, select it with .frame /r <frame> and inspect dv; otherwise use the captured stop output and the documented stop definition. Do not assume one fixed parameter layout or a stop code shared by all verifier versions.

2. Recover available block history

!heap -p -a <address>
!avrf -hp -a <address>

The first command inspects a Page Heap allocation; the second searches available Application Verifier heap-operation history. Use !heap -? and !avrf -? to confirm support in the installed extension. On an uninstrumented dump these commands may not recover the history needed to identify the writer.

Capture allocation and free stacks when present. Check the address is inside the user allocation rather than a header or neighboring block.

3. Test competing explanations

Inspect bytes with db <address> L<size> and disassembly around the access. Fill patterns and plausible pointers are clues, not causal proof. Correlate with source, history, or a repro and trace the ownership transition.

4. Obtain stronger evidence if necessary

With user approval, enable full Page Heap for a named test executable:

gflags /p /enable target.exe /full

Restart that process and reproduce under the debugger. Application Verifier heap checks can also be configured for that test executable. Explain memory overhead, timing changes, and potential deliberate stops before doing this. Record the previous settings and restore them when finished; if Page Heap was newly enabled for this test, disable it with:

gflags /p /disable target.exe

Do not change an existing application's verification policy without approval. If a user-mode TTD trace is available, use windbg-user-ttd-reverse-debugging-triage to find the relevant mutation or free.

Fix patterns

• Enforce the actual lifetime contract with ownership types or explicit acquire/release rules. Shared ownership is appropriate only when the design genuinely has multiple owners.
• Synchronize shared state separately: shared_ptr ownership does not make a concurrently modified cache or pointed-to object thread-safe.
• Size buffers and check arithmetic, lengths, and terminators; use bounds-aware containers where appropriate.
• Keep allocation and deallocation compatible across DLL/API boundaries.

Validation

Establish the affected block and supported corruption class, name the path that violated bounds or ownership, and distinguish the detector from the writer. Exercise the fix with the same instrumentation and relevant concurrency/load. Report unresolved writer history rather than presenting a guessed fix as proven.

References

• Application Verifier stop definitions
• Heap extension
• Application Verifier extension
• GFlags and Page Heap

Feedback

Follow FEEDBACK.md and report reviewed, sanitized feedback to WinDbg-Feedback. Include windbg-user-heap-corruption-investigation and the package version from plugin.json; no automatic dump, source, or transcript upload.