[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BMPFX7S3D729F1N89AAP6":3,"skill-same:01M69BMPFX7S3D729F1N89AAP6":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":21,"linkOnly":22,"markdownContent":23,"markdownBody":24,"frontMatter":25,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":6,"ownerHtmlUrl":31,"ownerBlogUrl":32,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M69BMPFX7S3D729F1N89AAP6","windbg-user-heap-corruption-investigation",null,"Use when an app, service, or user-mode driver host heap fails or Application Verifier detects corruption; inspect history and bounds. Not for kernel pool corruption or ordinary OOM.","microsoft\u002Fwin-dev-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69BM5T5HHSGVF6KZPTNENXK",506,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-heap-corruption-investigation\u002FSKILL.md",[],[19,20],"windbg user heap corruption investigation","kernel","2026-11-10 10:12:30",false,"---\nname: windbg-user-heap-corruption-investigation\ndescription: 'Use when an app, service, or user-mode driver host heap fails or Application Verifier detects corruption; inspect history and bounds. Not for kernel pool corruption or ordinary OOM.'\n---\n\n# Heap Corruption Investigation\n\n**Load `windbg-diagnostic-method` first** if it is not already loaded in this\nconversation, and apply it throughout for evidence ranking, hypothesis testing,\nconfidence calibration, independent review, and report validation. This skill\nadds the bug-family-specific commands and evidence requirements.\n\n## Detection and limits\n\nLook for `STATUS_HEAP_CORRUPTION` (`0xC0000374`), Application Verifier stops,\nor failures in heap allocate\u002Ffree\u002Freallocate paths in an application, service,\nor user-mode driver host such as an UMDF host process. A crash inside the allocator\nmay be the first detection of an earlier bad write, not the faulty operation.\nDistinguish corruption from allocation failure; for the latter use\n`windbg-user-virtual-memory-exhaustion`.\n\nAllocation\u002Ffree history depends on how the process was instrumented and which\npages were captured. A missing history is a limitation, not proof of a leak or\nuse-after-free.\n\n## Workflow\n\n### 1. Decode the stop\n\n```text\n.exr -1\n.ecxr\n!analyze -v\nk\n```\n\nRecord the stop reason, corrupted block, corruption address, and the operation\nthat detected the damage. If a verifier stop frame has parameter\u002Flocal symbols,\nselect it with `.frame \u002Fr \u003Cframe>` and inspect `dv`; otherwise use the captured\nstop output and the documented stop definition. Do not assume one fixed\nparameter layout or a stop code shared by all verifier versions.\n\n### 2. Recover available block history\n\n```text\n!heap -p -a \u003Caddress>\n!avrf -hp -a \u003Caddress>\n```\n\nThe first command inspects a Page Heap allocation; the second searches available\nApplication Verifier heap-operation history. Use `!heap -?` and `!avrf -?` to\nconfirm support in the installed extension. On an uninstrumented dump these\ncommands may not recover the history needed to identify the writer.\n\nCapture allocation and free stacks when present. Check the address is inside\nthe user allocation rather than a header or neighboring block.\n\n### 3. Test competing explanations\n\n| Hypothesis | Evidence to seek |\n|---|---|\n| Use-after-free | Confirmed free before a later access through a retained reference |\n| Double-free | Two ownership\u002Fcompletion paths freeing the same allocation |\n| Overrun\u002Funderrun | A write outside the allocated user bounds |\n| Wild write | Corrupted header or payload and a writer with an invalid target |\n| Allocation\u002Ffree contract mismatch | Different allocator\u002Fdeallocator or incorrect owning heap |\n\nInspect bytes with `db \u003Caddress> L\u003Csize>` and disassembly around the access.\nFill patterns and plausible pointers are clues, not causal proof. Correlate with\nsource, history, or a repro and trace the ownership transition.\n\n### 4. Obtain stronger evidence if necessary\n\nWith user approval, enable full Page Heap for a named test executable:\n\n```text\ngflags \u002Fp \u002Fenable target.exe \u002Ffull\n```\n\nRestart that process and reproduce under the debugger. Application Verifier\nheap checks can also be configured for that test executable. Explain memory\noverhead, timing changes, and potential deliberate stops before doing this.\nRecord the previous settings and restore them when finished; if Page Heap was\nnewly enabled for this test, disable it with:\n\n```text\ngflags \u002Fp \u002Fdisable target.exe\n```\n\nDo not change an existing application's verification policy without approval.\nIf a user-mode TTD trace is available, use `windbg-user-ttd-reverse-debugging-triage` to\nfind the relevant mutation or free.\n\n## Fix patterns\n\n- Enforce the actual lifetime contract with ownership types or explicit\n  acquire\u002Frelease rules. Shared ownership is appropriate only when the design\n  genuinely has multiple owners.\n- Synchronize shared state separately: `shared_ptr` ownership does not make a\n  concurrently modified cache or pointed-to object thread-safe.\n- Size buffers and check arithmetic, lengths, and terminators; use bounds-aware\n  containers where appropriate.\n- Keep allocation and deallocation compatible across DLL\u002FAPI boundaries.\n\n## Validation\n\nEstablish the affected block and supported corruption class, name the path that\nviolated bounds or ownership, and distinguish the detector from the writer.\nExercise the fix with the same instrumentation and relevant concurrency\u002Fload.\nReport unresolved writer history rather than presenting a guessed fix as proven.\n\n## References\n\n- [Application Verifier stop definitions](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdevtest\u002Fapplication-verifier-stop-codes-and-definitions)\n- [Heap extension](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-heap)\n- [Application Verifier extension](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-avrf)\n- [GFlags and Page Heap](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebugger\u002Fgflags-and-pageheap)\n\n## Feedback\n\nFollow `FEEDBACK.md` and report reviewed, sanitized feedback to\n[WinDbg-Feedback](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FWinDbg-Feedback\u002Fissues).\nInclude `windbg-user-heap-corruption-investigation` and the package version from\n`plugin.json`; no automatic dump, source, or transcript upload.\n","# Heap Corruption Investigation\n\n**Load `windbg-diagnostic-method` first** if it is not already loaded in this\nconversation, and apply it throughout for evidence ranking, hypothesis testing,\nconfidence calibration, independent review, and report validation. This skill\nadds the bug-family-specific commands and evidence requirements.\n\n## Detection and limits\n\nLook for `STATUS_HEAP_CORRUPTION` (`0xC0000374`), Application Verifier stops,\nor failures in heap allocate\u002Ffree\u002Freallocate paths in an application, service,\nor user-mode driver host such as an UMDF host process. A crash inside the allocator\nmay be the first detection of an earlier bad write, not the faulty operation.\nDistinguish corruption from allocation failure; for the latter use\n`windbg-user-virtual-memory-exhaustion`.\n\nAllocation\u002Ffree history depends on how the process was instrumented and which\npages were captured. A missing history is a limitation, not proof of a leak or\nuse-after-free.\n\n## Workflow\n\n### 1. Decode the stop\n\n```text\n.exr -1\n.ecxr\n!analyze -v\nk\n```\n\nRecord the stop reason, corrupted block, corruption address, and the operation\nthat detected the damage. If a verifier stop frame has parameter\u002Flocal symbols,\nselect it with `.frame \u002Fr \u003Cframe>` and inspect `dv`; otherwise use the captured\nstop output and the documented stop definition. Do not assume one fixed\nparameter layout or a stop code shared by all verifier versions.\n\n### 2. Recover available block history\n\n```text\n!heap -p -a \u003Caddress>\n!avrf -hp -a \u003Caddress>\n```\n\nThe first command inspects a Page Heap allocation; the second searches available\nApplication Verifier heap-operation history. Use `!heap -?` and `!avrf -?` to\nconfirm support in the installed extension. On an uninstrumented dump these\ncommands may not recover the history needed to identify the writer.\n\nCapture allocation and free stacks when present. Check the address is inside\nthe user allocation rather than a header or neighboring block.\n\n### 3. Test competing explanations\n\n| Hypothesis | Evidence to seek |\n|---|---|\n| Use-after-free | Confirmed free before a later access through a retained reference |\n| Double-free | Two ownership\u002Fcompletion paths freeing the same allocation |\n| Overrun\u002Funderrun | A write outside the allocated user bounds |\n| Wild write | Corrupted header or payload and a writer with an invalid target |\n| Allocation\u002Ffree contract mismatch | Different allocator\u002Fdeallocator or incorrect owning heap |\n\nInspect bytes with `db \u003Caddress> L\u003Csize>` and disassembly around the access.\nFill patterns and plausible pointers are clues, not causal proof. Correlate with\nsource, history, or a repro and trace the ownership transition.\n\n### 4. Obtain stronger evidence if necessary\n\nWith user approval, enable full Page Heap for a named test executable:\n\n```text\ngflags \u002Fp \u002Fenable target.exe \u002Ffull\n```\n\nRestart that process and reproduce under the debugger. Application Verifier\nheap checks can also be configured for that test executable. Explain memory\noverhead, timing changes, and potential deliberate stops before doing this.\nRecord the previous settings and restore them when finished; if Page Heap was\nnewly enabled for this test, disable it with:\n\n```text\ngflags \u002Fp \u002Fdisable target.exe\n```\n\nDo not change an existing application's verification policy without approval.\nIf a user-mode TTD trace is available, use `windbg-user-ttd-reverse-debugging-triage` to\nfind the relevant mutation or free.\n\n## Fix patterns\n\n- Enforce the actual lifetime contract with ownership types or explicit\n  acquire\u002Frelease rules. Shared ownership is appropriate only when the design\n  genuinely has multiple owners.\n- Synchronize shared state separately: `shared_ptr` ownership does not make a\n  concurrently modified cache or pointed-to object thread-safe.\n- Size buffers and check arithmetic, lengths, and terminators; use bounds-aware\n  containers where appropriate.\n- Keep allocation and deallocation compatible across DLL\u002FAPI boundaries.\n\n## Validation\n\nEstablish the affected block and supported corruption class, name the path that\nviolated bounds or ownership, and distinguish the detector from the writer.\nExercise the fix with the same instrumentation and relevant concurrency\u002Fload.\nReport unresolved writer history rather than presenting a guessed fix as proven.\n\n## References\n\n- [Application Verifier stop definitions](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdevtest\u002Fapplication-verifier-stop-codes-and-definitions)\n- [Heap extension](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-heap)\n- [Application Verifier extension](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-avrf)\n- [GFlags and Page Heap](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebugger\u002Fgflags-and-pageheap)\n\n## Feedback\n\nFollow `FEEDBACK.md` and report reviewed, sanitized feedback to\n[WinDbg-Feedback](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FWinDbg-Feedback\u002Fissues).\nInclude `windbg-user-heap-corruption-investigation` and the package version from\n`plugin.json`; no automatic dump, source, or transcript upload.\n",{"name":5,"description":7},"main","5ce74fa89c49ca353c6ab03bd5889aa519aa9e5e","plugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-heap-corruption-investigation",41,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-09 06:27:16",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add microsoft\u002Fwin-dev-skills --skill windbg-user-heap-corruption-investigation",{"tool":41,"command":42},"bunx","bunx skills add microsoft\u002Fwin-dev-skills --skill windbg-user-heap-corruption-investigation",{"tool":44,"command":45},"pnpm","pnpm dlx skills add microsoft\u002Fwin-dev-skills --skill windbg-user-heap-corruption-investigation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-heap-corruption-investigation\u002FSKILL.md",true,[],[50,68,76,86,96,106],{"skillNo":51,"name":52,"nameZh":6,"description":53,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":54,"categories":55,"keywords":64,"publishedAt":21},"01M69BN1YCR77KBJHPBB1KBXAB","sample-skill","Sample skill used to test the catalog tooling. Use when testing CI. Not for real work.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fscripts\u002Ftests\u002Ffixtures\u002Flocal-plugin\u002Fplugins\u002Fsample\u002Fskills\u002Fsample-skill\u002FSKILL.md",[56,61],{"categoryNo":57,"categoryName":58,"taxonomyType":59,"taxonomyTypeDesc":60},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":62,"categoryName":63,"taxonomyType":59,"taxonomyTypeDesc":60},"01JBSEEDCAT000000000000023","Skill与智能体开发",[65,66,67],"sample skill","testing","test",{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":21},"01M69BMZFWAWBRE71DKPHT282F","windbg-user-wait-chain-analysis","Use when an app, service, or user-mode driver host is unresponsive on locks, COM\u002FRPC, I\u002FO, or another process; follow the blocker chain. Not for a crash solely from an exception stack.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-wait-chain-analysis\u002FSKILL.md",[],[75],"windbg user wait chain analysis",{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":82,"publishedAt":21},"01M69BMX6T725RH7TZK7RDP8YQ","windbg-user-virtual-memory-exhaustion","Use when a native app, service, or user-mode driver host allocation fails; distinguish VA exhaustion, fragmentation, and commit pressure. Not for managed .NET heap growth, proving a leak from one snapshot, or corruption.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-virtual-memory-exhaustion\u002FSKILL.md",[],[83,84,85],"windbg user virtual memory exhaustion","memory","commit",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":21},"01M69BMTTSCGTJ6W18YNYDWEVE","windbg-user-ttd-reverse-debugging-triage","Use when an app, service, or user-mode driver host TTD recording is available and earlier calls, writes, or lifetimes matter. Not for kernel replay or history from a normal dump.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-ttd-reverse-debugging-triage\u002FSKILL.md",[],[93,94,95,20],"triage","windbg user ttd reverse debugging triage","debugging",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":21},"01M69BMRKH2MF07GD357PK5S4Q","windbg-user-mutex-held-across-co-await","Use when app, service, or user-mode driver C++ coroutine code holds a thread-affine lock across suspension and later hangs or fails. Not for all coroutine crashes or choosing lock performance.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-mutex-held-across-co-await\u002FSKILL.md",[],[103,104,105],"windbg user mutex held across co await","code","performance",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":21},"01M69BMM5G8J8WJWKBWB6J0SA7","windbg-user-exception-triage","Use when a native C\u002FC++ app, service, or user-mode driver host (including UMDF) crashes with a structured exception in a dump or WinDbg session, including native faults inside managed processes. Not for managed .NET exceptions, WinUI\u002FXAML app errors, or kernel bugchecks.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-exception-triage\u002FSKILL.md",[],[113,93,20,114,115],"windbg user exception triage","xaml","winui"]