[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69BMZFWAWBRE71DKPHT282F":3,"skill-same:01M69BMZFWAWBRE71DKPHT282F":48},{"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":20,"linkOnly":21,"markdownContent":22,"markdownBody":23,"frontMatter":24,"refName":25,"commitSha":26,"skillDirectory":27,"forksCount":28,"repositoryHtmlUrl":29,"repositoryHomepageUrl":6,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M69BMZFWAWBRE71DKPHT282F","windbg-user-wait-chain-analysis",null,"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.","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-wait-chain-analysis\u002FSKILL.md",[],[19],"windbg user wait chain analysis","2026-11-10 10:12:30",false,"---\nname: windbg-user-wait-chain-analysis\ndescription: '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.'\n---\n\n# Cross-Process Wait Chain Analysis\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\n\nLook for blocked work in an application, service, or user-mode driver host\n(including UMDF), and threads in wait, COM, RPC, or I\u002FO paths.\nThe process displaying the symptom may not own the underlying defect.\nIdle worker threads waiting normally are not evidence of a hang.\n\n## Workflow\n\n### 1. Identify the affected operation and its thread\n\n```text\n.lastevent\n~*kb\n!runaway\n```\n\nConfirm why the dump was collected. A dump is a snapshot; `.lastevent` does not\nby itself certify \"hang\" or \"no crash.\" Identify the UI\u002Fserving thread from\napplication evidence instead of assuming thread zero is always the UI thread.\nIf work is spinning rather than blocked, collect appropriate CPU evidence.\n\n### 2. Identify each wait and its owner\n\nInspect frames around `WaitForSingleObject`, `WaitForMultipleObjects`, COM\nsend\u002Freceive, and RPC calls. Use matching symbols\u002Fsource for your own proxy,\ninterface, and server registration to determine what was requested.\n\nFor each edge record:\n\n```text\nprocess \u002F thread -> waited resource or request -> owner \u002F serving thread\n```\n\nDo not guess a server PID from undocumented private COM layouts. Use available\nWait Chain Traversal, RPC\u002FCOM tracing, application correlation IDs, or\nregistration\u002Fprocess information, and explicitly mark unresolved edges.\n\n### 3. Gather corresponding server evidence\n\nObtain authorized dumps or live state of the relevant server processes close\nenough in time to represent the same operation. Inspect their serving threads.\nFor kernel context use documented commands such as:\n\n```text\n!process 0 7\n!thread \u003Cethread>\n```\n\nAvailable user pages and symbol\u002Fcontext support vary by dump type. If the chain\nends in a kernel lock use `windbg-kernel-lock-deadlock-triage`; if blocked I\u002FO is supported\nby IRP evidence use `windbg-kernel-irp-lifecycle-triage`. Do not promise process heaps or\nuser stacks absent from the dump.\n\n### 4. Distinguish a cycle from a slow or missing responder\n\n- **Cycle:** show every required wait\u002Fowner edge back to the starting actor.\n- **Contention:** a runnable owner may eventually release the resource.\n- **Starvation:** queued work cannot obtain execution capacity.\n- **Lost completion:** the actor\u002Fevent expected to unblock the waiter no\n  longer exists or no path signals it.\n- **Slow server:** the endpoint is doing work, blocked on another dependency,\n  or looping; gather its evidence before blaming the client.\n\nMultiple snapshots or tracing may be needed to distinguish transient waits\nfrom persistent blocking.\n\n## Fix patterns and COM boundaries\n\nA synchronous COM call from an STA can pump messages and permit reentrancy.\nIt is not automatically a deadlock. Investigate locks held across calls,\ncallbacks, apartment access, and any non-pumping waits that form an actual\ndependency cycle.\n\nPossible remedies include asynchronous APIs, shorter lock scopes, moving\ndestruction\u002Fcross-process calls outside critical sections, and bounded\nwait\u002Fcancellation protocols where the API supports them. A timeout on the\ncaller does not cancel server work by itself.\n\nIf work moves to another apartment, marshal apartment-bound interfaces, keep\ncaptured state alive, and dispatch UI updates to the correct thread. Merely\ncapturing a COM pointer and `this` in a worker lambda is not a safe fix.\n\n## Validation\n\nIdentify the affected thread, relevant resources and owners, and demonstrated\ncycle or deepest supported blocker. Test the proposed remedy under concurrency,\nreentrancy, shutdown, and timeout\u002Fcancellation. Do not stop at \"waiting in RPC.\"\nIf the server dump or an owner edge is missing, state the unresolved hypothesis.\n\n## References\n\n- [Wait Chain Traversal](https:\u002F\u002Flearn.microsoft.com\u002Fwindows\u002Fwin32\u002Fdebug\u002Fwait-chain-traversal)\n- [Processes, threads, and COM apartments](https:\u002F\u002Flearn.microsoft.com\u002Fwindows\u002Fwin32\u002Fcom\u002Fprocesses--threads--and-apartments)\n- [Process inspection](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-process)\n- [Thread inspection](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-thread)\n\n## Feedback\n\nFollow `FEEDBACK.md` and submit only reviewed, sanitized feedback to\n[WinDbg-Feedback](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FWinDbg-Feedback\u002Fissues).\nInclude `windbg-user-wait-chain-analysis` and the package version from `plugin.json`; no\nautomatic capture or public upload of process dumps or full diagnostic\ntranscripts.\n","# Cross-Process Wait Chain Analysis\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\n\nLook for blocked work in an application, service, or user-mode driver host\n(including UMDF), and threads in wait, COM, RPC, or I\u002FO paths.\nThe process displaying the symptom may not own the underlying defect.\nIdle worker threads waiting normally are not evidence of a hang.\n\n## Workflow\n\n### 1. Identify the affected operation and its thread\n\n```text\n.lastevent\n~*kb\n!runaway\n```\n\nConfirm why the dump was collected. A dump is a snapshot; `.lastevent` does not\nby itself certify \"hang\" or \"no crash.\" Identify the UI\u002Fserving thread from\napplication evidence instead of assuming thread zero is always the UI thread.\nIf work is spinning rather than blocked, collect appropriate CPU evidence.\n\n### 2. Identify each wait and its owner\n\nInspect frames around `WaitForSingleObject`, `WaitForMultipleObjects`, COM\nsend\u002Freceive, and RPC calls. Use matching symbols\u002Fsource for your own proxy,\ninterface, and server registration to determine what was requested.\n\nFor each edge record:\n\n```text\nprocess \u002F thread -> waited resource or request -> owner \u002F serving thread\n```\n\nDo not guess a server PID from undocumented private COM layouts. Use available\nWait Chain Traversal, RPC\u002FCOM tracing, application correlation IDs, or\nregistration\u002Fprocess information, and explicitly mark unresolved edges.\n\n### 3. Gather corresponding server evidence\n\nObtain authorized dumps or live state of the relevant server processes close\nenough in time to represent the same operation. Inspect their serving threads.\nFor kernel context use documented commands such as:\n\n```text\n!process 0 7\n!thread \u003Cethread>\n```\n\nAvailable user pages and symbol\u002Fcontext support vary by dump type. If the chain\nends in a kernel lock use `windbg-kernel-lock-deadlock-triage`; if blocked I\u002FO is supported\nby IRP evidence use `windbg-kernel-irp-lifecycle-triage`. Do not promise process heaps or\nuser stacks absent from the dump.\n\n### 4. Distinguish a cycle from a slow or missing responder\n\n- **Cycle:** show every required wait\u002Fowner edge back to the starting actor.\n- **Contention:** a runnable owner may eventually release the resource.\n- **Starvation:** queued work cannot obtain execution capacity.\n- **Lost completion:** the actor\u002Fevent expected to unblock the waiter no\n  longer exists or no path signals it.\n- **Slow server:** the endpoint is doing work, blocked on another dependency,\n  or looping; gather its evidence before blaming the client.\n\nMultiple snapshots or tracing may be needed to distinguish transient waits\nfrom persistent blocking.\n\n## Fix patterns and COM boundaries\n\nA synchronous COM call from an STA can pump messages and permit reentrancy.\nIt is not automatically a deadlock. Investigate locks held across calls,\ncallbacks, apartment access, and any non-pumping waits that form an actual\ndependency cycle.\n\nPossible remedies include asynchronous APIs, shorter lock scopes, moving\ndestruction\u002Fcross-process calls outside critical sections, and bounded\nwait\u002Fcancellation protocols where the API supports them. A timeout on the\ncaller does not cancel server work by itself.\n\nIf work moves to another apartment, marshal apartment-bound interfaces, keep\ncaptured state alive, and dispatch UI updates to the correct thread. Merely\ncapturing a COM pointer and `this` in a worker lambda is not a safe fix.\n\n## Validation\n\nIdentify the affected thread, relevant resources and owners, and demonstrated\ncycle or deepest supported blocker. Test the proposed remedy under concurrency,\nreentrancy, shutdown, and timeout\u002Fcancellation. Do not stop at \"waiting in RPC.\"\nIf the server dump or an owner edge is missing, state the unresolved hypothesis.\n\n## References\n\n- [Wait Chain Traversal](https:\u002F\u002Flearn.microsoft.com\u002Fwindows\u002Fwin32\u002Fdebug\u002Fwait-chain-traversal)\n- [Processes, threads, and COM apartments](https:\u002F\u002Flearn.microsoft.com\u002Fwindows\u002Fwin32\u002Fcom\u002Fprocesses--threads--and-apartments)\n- [Process inspection](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-process)\n- [Thread inspection](https:\u002F\u002Flearn.microsoft.com\u002Fwindows-hardware\u002Fdrivers\u002Fdebuggercmds\u002F-thread)\n\n## Feedback\n\nFollow `FEEDBACK.md` and submit only reviewed, sanitized feedback to\n[WinDbg-Feedback](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002FWinDbg-Feedback\u002Fissues).\nInclude `windbg-user-wait-chain-analysis` and the package version from `plugin.json`; no\nautomatic capture or public upload of process dumps or full diagnostic\ntranscripts.\n",{"name":5,"description":7},"main","5ce74fa89c49ca353c6ab03bd5889aa519aa9e5e","plugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-wait-chain-analysis",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":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add microsoft\u002Fwin-dev-skills --skill windbg-user-wait-chain-analysis",{"tool":40,"command":41},"bunx","bunx skills add microsoft\u002Fwin-dev-skills --skill windbg-user-wait-chain-analysis",{"tool":43,"command":44},"pnpm","pnpm dlx skills add microsoft\u002Fwin-dev-skills --skill windbg-user-wait-chain-analysis","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-wait-chain-analysis\u002FSKILL.md",true,[],[49,67,77,88,98,106],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":63,"publishedAt":20},"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",[55,60],{"categoryNo":56,"categoryName":57,"taxonomyType":58,"taxonomyTypeDesc":59},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":61,"categoryName":62,"taxonomyType":58,"taxonomyTypeDesc":59},"01JBSEEDCAT000000000000023","Skill与智能体开发",[64,65,66],"sample skill","testing","test",{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":20},"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",[],[74,75,76],"windbg user virtual memory exhaustion","memory","commit",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":20},"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",[],[84,85,86,87],"windbg user ttd reverse debugging triage","debugging","triage","kernel",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":20},"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",[],[95,96,97],"windbg user mutex held across co await","code","performance",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":20},"01M69BMPFX7S3D729F1N89AAP6","windbg-user-heap-corruption-investigation","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.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fwin-dev-skills\u002Fblob\u002Fmain\u002Fplugins\u002Fwindbg\u002Fskills\u002Fwindbg-user-heap-corruption-investigation\u002FSKILL.md",[],[105,87],"windbg user heap corruption investigation",{"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":20},"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",[],[86,113,114,115,87],"windbg user exception triage","xaml","winui"]