[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699BKNP51ZRY7V51X5X5R5M":3,"skill-same:01M699BKNP51ZRY7V51X5X5R5M":64},{"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":35,"linkOnly":36,"markdownContent":37,"markdownBody":38,"frontMatter":39,"refName":40,"commitSha":41,"skillDirectory":42,"forksCount":43,"repositoryHtmlUrl":44,"repositoryHomepageUrl":45,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M699BKNP51ZRY7V51X5X5R5M","symbolicate-crash-dump",null,"Symbolicate a native VS Code crash dump (.dmp) using electron-minidump. Use when given a crash dump file, asked to symbolicate a crash, resolve missing method names in a native crash backtrace, or attach Electron\u002FInsiders\u002FStable symbol files. VS Code team members only; requires macOS or Linux.","microsoft\u002Fvscode","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M6998NK2WED5M549DX06VBCH",195330,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsymbolicate-crash-dump\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34],"symbolicate crash dump","crash","dump","macos","linux","electron","code","file","team","use","only","files","attach","missing","native","when","2026-11-10 10:12:30",false,"---\nname: symbolicate-crash-dump\ndescription: \"Symbolicate a native VS Code crash dump (.dmp) using electron-minidump. Use when given a crash dump file, asked to symbolicate a crash, resolve missing method names in a native crash backtrace, or attach Electron\u002FInsiders\u002FStable symbol files. VS Code team members only; requires macOS or Linux.\"\n---\n\n# Symbolicate a Crash Dump\n\nTurn a native VS Code crash dump (`.dmp`) into a readable backtrace with method names using [electron-minidump](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Felectron-minidump).\n\n> **VS Code team members only.** Symbol files for internal Electron, Insiders, and Stable builds live in a private-adjacent release repo. A **macOS or Linux** device is required — electron-minidump does not run on Windows.\n\n## Prerequisites\n\n- A crash dump file (`*.dmp`). See [Creating a crash report](#creating-a-crash-report) below if you don't have one yet.\n- A global install of `electron-minidump`:\n    ```bash\n    npm install -g electron-minidump\n    ```\n- For Insiders\u002FStable symbols, an authenticated GitHub CLI (`gh auth status`) with access to the private `microsoft\u002Fvscode-electron-prebuilt` repo.\n\n## Procedure\n\n### 1. Run an initial symbolication pass\n\nThis generates or refreshes the electron-minidump cache and tells you which symbols are still missing.\n\n```bash\nelectron-minidump crash-file.dmp > symbolicated-output.log\n```\n\nInspect `symbolicated-output.log`. Look at the top frames of the backtrace: if a frame names a module (e.g. `Electron Framework`) but has **no method name after it**, symbols for that module are required.\n\n> **Retry on transient download errors.** electron-minidump downloads symbols from public symbol servers, so a run can fail on a transient network error (e.g. `failed to download ... (code 56)` or `(code 28)`). Successfully downloaded symbols are cached, so simply re-running the same command resumes where it left off. Retrying a few times is expected:\n> ```bash\n> for i in 1 2 3 4 5; do\n>     electron-minidump crash-file.dmp > symbolicated-output.log && break\n>     sleep 3\n> done\n> ```\n\n### 2. Get the appropriate symbol files\n\nMatch the symbol source to the build that produced the crash:\n\n| Build that crashed | Symbol files source |\n|--------------------|---------------------|\n| Insiders \u002F Stable (internal Electron) | [microsoft\u002Fvscode-electron-prebuilt releases](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-electron-prebuilt\u002Freleases) |\n| Code - OSS (OSS Electron) | [electron\u002Felectron releases](https:\u002F\u002Fgithub.com\u002Felectron\u002Felectron\u002Freleases) |\n\n`microsoft\u002Fvscode-electron-prebuilt` is a **private** repo — this is why the flow is team-members-only. A plain browser or `curl` link will 404 without auth; download the asset with an authenticated GitHub CLI instead (`gh auth status` should show you logged in):\n\n```bash\n# List releases (tagged by Electron version) to find the right tag:\ngh release list --repo microsoft\u002Fvscode-electron-prebuilt\n\n# Download just the symbol zip you need:\ngh release download v42.5.0-14525058 \\\n    --repo microsoft\u002Fvscode-electron-prebuilt \\\n    --pattern \"stable-symbols-v42.5.0-win32-x64.zip\"\n```\n\nThe releases are tagged by **Electron version**, not VS Code version, so first find the Electron version the crashed VS Code build shipped. It's the `nativeBuild.target` field of that version's `package.json` (e.g. `git show \u003Cversion>:package.json | node -p \"JSON.parse(require('fs').readFileSync(0, 'utf8')).nativeBuild.target\"`). Versions released before that field existed have it as the `target=` in `.npmrc` (e.g. `git show 1.128.0:.npmrc`). Then pick the matching symbol zip by **quality, platform, and architecture** — e.g. a Stable Windows x64 crash on Electron 42.5.0 needs `stable-symbols-v42.5.0-win32-x64.zip` (use `insiders-symbols-…` for Insiders). Code - OSS symbols come from the public [electron\u002Felectron releases](https:\u002F\u002Fgithub.com\u002Felectron\u002Felectron\u002Freleases) and can be downloaded without special access.\n\n> **These zips are small and selective.** A `*-symbols-*.zip` typically contains only a handful of first-party modules — `electron.exe.sym`, `libEGL.dll.sym`, `libGLESv2.dll.sym` on Windows (and the equivalents elsewhere). Many modules that show up in a backtrace — notably `runtime.node` and any OS\u002Fthird-party DLL — are **not** in these zips. `runtime.node` frames often cannot be symbolicated at all from public symbols; when the crash is in a third-party module, attribute it by module name rather than expecting method names on every frame (see [Reading the result](#reading-the-result)).\n\n### 3. Copy the `.sym` files into the electron-minidump cache\n\nThe cache lives at:\n\n```bash\n\"$(npm root -g)\u002Felectron-minidump\u002Fcache\u002Fbreakpad_symbols\"\n```\n\nBreakpad keys symbols by `\u003Cmodule>.pdb\u002F\u003Cdebug-id>\u002F\u003Cmodule>.sym`, and the `\u003Cdebug-id>` **must match exactly** between the dump and the symbol zip — a same-version zip built from a different pipeline run will have a different id and won't be used. After the initial pass, the cache already contains an (empty) directory for each required module whose name and hash you must match:\n\n```bash\nCACHE=\"$(npm root -g)\u002Felectron-minidump\u002Fcache\u002Fbreakpad_symbols\"\n# The debug-id electron-minidump wants for a given module:\nls \"$CACHE\u002Felectron.exe.pdb\"     # e.g. DD081533CD7E33A44C4C44205044422E1\n```\n\nUnzip the downloaded symbols and confirm the same module\u002Fhash exists in the zip before copying it in. The zip's internal layout is also `\u003Cmodule>.pdb\u002F\u003Cdebug-id>\u002F\u003Cmodule>.sym`.\n\nExample (Windows: the shipped main binary is `Code.exe`, but its symbols come from `electron.exe.sym`):\n\n```bash\n# Unzip somewhere, e.g. ~\u002Fstable-symbols\u002F\nunzip stable-symbols-v42.5.0-win32-x64.zip -d ~\u002Fstable-symbols\n\n# Only copy if the debug-id matches what the cache expects.\n# Keep the tilde outside quotes so it expands to your home directory:\nHASH=DD081533CD7E33A44C4C44205044422E1\ncp ~\u002Fstable-symbols\u002Fsymbols\u002Felectron.exe.pdb\u002F\"$HASH\"\u002Felectron.exe.sym \\\n   \"$CACHE\u002Felectron.exe.pdb\u002F$HASH\u002F\"\n```\n\nOn macOS the analogous module is `Electron Framework` (`Electron Framework\u002F\u003Chash>\u002FElectron Framework.sym`). Repeat for any other module the initial pass reported as missing method names — but only when the zip actually contains a matching-hash `.sym` for it.\n\n> **If no matching-hash symbols exist**, you cannot get method names for that module — this is common for officially-shipped Stable\u002FInsiders builds whose exact `electron.exe`\u002F`Code.exe` hash isn't in any public prebuilt zip, and for `runtime.node`. Fall back to attributing the crash by module and process (see [Reading the result](#reading-the-result)); that is usually enough to identify a third-party culprit.\n\n### 4. Re-run symbolication\n\n```bash\nelectron-minidump crash-file.dmp > symbolicated-output.log\n```\n\nThe backtrace in `symbolicated-output.log` should now have method names attached. If some frames are still bare, return to step 2 for the module(s) still missing symbols.\n\n## Reading the result\n\nOnce you have a symbolicated backtrace, turn it into a root cause by answering two questions:\n\n### Which module owns the crash?\n\nLook at the **top frame of the crashing thread** (marked `(crashed)`) and its module name:\n\n- If it's a **VS Code \u002F Electron module** — `Code.exe`, `runtime.node`, `Electron Framework`, `libnode`, `libffmpeg`, V8 frames — the fault is likely inside the product or Electron.\n- If it's a **third-party \u002F OS module** — an antivirus, VPN, proxy, or shell-extension DLL injected into the process — the crash is almost certainly caused by that software, not VS Code. Injected DLLs often appear interleaved with `runtime.node`\u002FV8 frames because they hook the runtime.\n\nFind where the module is loaded on disk to confirm it's third-party. On Windows the `strings` of the dump usually reveal the full path, e.g. a DLL under `C:\\WINDOWS\\system32\\` or a vendor folder rather than the VS Code install directory:\n\n```bash\nstrings -a crash-file.dmp | grep -i \"\u003CSuspectModule>\" | sort -u\n```\n\n### Which process crashed?\n\nThe process type tells you whether this is the main process, a renderer\u002Fwindow, or the extension host. On modern Electron the **extension host runs inside a Node utility process**, so a crash there shows up as the `node.mojom.NodeService` utility — not a process literally named \"extension host\":\n\n```bash\nstrings -a crash-file.dmp | grep -oiE \"utility-sub-type=[a-zA-Z0-9._-]+|node\\.mojom\\.[A-Za-z]+|--type=[a-z-]+\" | sort -u\n```\n\n| Marker | Process |\n|--------|---------|\n| `node.mojom.NodeService` \u002F `utility-sub-type=node.mojom.NodeService` | Extension host (Node utility process) |\n| `--type=renderer` | A workbench window (renderer) |\n| `--type=gpu-process` | GPU process |\n| (no `--type`) | Main process |\n\nMatch this against the reported symptom (e.g. an \"extension host crash-loop\" should correspond to a `NodeService` utility crash).\n\nWhen you have multiple dumps, symbolicate each and compare the crash reason and top frame — an identical signature across dumps confirms a single, reproducible cause.\n\n## Creating a crash report\n\nIf you don't yet have a `.dmp` file, produce one with the `--crash-reporter-directory` option:\n\n1. Close all instances of VS Code.\n2. Run `code --crash-reporter-directory \u003Cabsolute-path>` from the command line (use `code-insiders` for the Insiders build).\n3. Take the steps that lead to the crash.\n4. Look for a `*.dmp` file in that folder.\n\nYou can only symbolicate crashes from a build you have matching symbols for. Crashes from Insiders\u002FStable need the internal Electron symbols; crashes from a local source build (Code - OSS) need the OSS Electron symbols.\n\n## Remote Extension Host crashes (Linux, gdb)\n\nNative crashes in a remote server's extension host use core dumps and `gdb` instead of electron-minidump:\n\n1. Before running the server, allow core dumps: `ulimit -c unlimited`.\n2. Reproduce the crash. Retrieve the core dump via `coredumpctl`, or from the path in `\u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern`.\n3. Load it in gdb and capture output:\n    ```bash\n    gdb -se \u003Cpath-to-vscode-server>\u002Fnode -c \u003Cpath-to-core-file>\n    ```\n   Then run and collect the output of:\n    ```\n    set pagination off\n    info sharedlibrary\n    info registers\n    bt full\n    disassemble\n    ```\n\n## Tips\n\n- Keep `crash-file.dmp` and `symbolicated-output.log` out of the repo — they are throwaway artifacts.\n- The cache path is dynamic; always resolve it with `$(npm root -g)` rather than hardcoding a home directory.\n- Breakpad matches symbols by exact debug-id, not by version name. If method names are still missing after adding symbols, confirm the `.sym` you copied has the exact hash the cache directory expects, and double-check the quality (`stable`\u002F`insiders`), platform (`win32`\u002F`darwin`\u002F`linux`), and arch (`x64`\u002F`arm64`) of the symbol zip.\n- Not every frame can be symbolicated. `runtime.node` and third-party\u002FOS modules frequently have no public symbols; identifying the crashing module and process is usually enough to reach a root cause.\n","# Symbolicate a Crash Dump\n\nTurn a native VS Code crash dump (`.dmp`) into a readable backtrace with method names using [electron-minidump](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Felectron-minidump).\n\n> **VS Code team members only.** Symbol files for internal Electron, Insiders, and Stable builds live in a private-adjacent release repo. A **macOS or Linux** device is required — electron-minidump does not run on Windows.\n\n## Prerequisites\n\n- A crash dump file (`*.dmp`). See [Creating a crash report](#creating-a-crash-report) below if you don't have one yet.\n- A global install of `electron-minidump`:\n    ```bash\n    npm install -g electron-minidump\n    ```\n- For Insiders\u002FStable symbols, an authenticated GitHub CLI (`gh auth status`) with access to the private `microsoft\u002Fvscode-electron-prebuilt` repo.\n\n## Procedure\n\n### 1. Run an initial symbolication pass\n\nThis generates or refreshes the electron-minidump cache and tells you which symbols are still missing.\n\n```bash\nelectron-minidump crash-file.dmp > symbolicated-output.log\n```\n\nInspect `symbolicated-output.log`. Look at the top frames of the backtrace: if a frame names a module (e.g. `Electron Framework`) but has **no method name after it**, symbols for that module are required.\n\n> **Retry on transient download errors.** electron-minidump downloads symbols from public symbol servers, so a run can fail on a transient network error (e.g. `failed to download ... (code 56)` or `(code 28)`). Successfully downloaded symbols are cached, so simply re-running the same command resumes where it left off. Retrying a few times is expected:\n> ```bash\n> for i in 1 2 3 4 5; do\n>     electron-minidump crash-file.dmp > symbolicated-output.log && break\n>     sleep 3\n> done\n> ```\n\n### 2. Get the appropriate symbol files\n\nMatch the symbol source to the build that produced the crash:\n\n| Build that crashed | Symbol files source |\n|--------------------|---------------------|\n| Insiders \u002F Stable (internal Electron) | [microsoft\u002Fvscode-electron-prebuilt releases](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode-electron-prebuilt\u002Freleases) |\n| Code - OSS (OSS Electron) | [electron\u002Felectron releases](https:\u002F\u002Fgithub.com\u002Felectron\u002Felectron\u002Freleases) |\n\n`microsoft\u002Fvscode-electron-prebuilt` is a **private** repo — this is why the flow is team-members-only. A plain browser or `curl` link will 404 without auth; download the asset with an authenticated GitHub CLI instead (`gh auth status` should show you logged in):\n\n```bash\n# List releases (tagged by Electron version) to find the right tag:\ngh release list --repo microsoft\u002Fvscode-electron-prebuilt\n\n# Download just the symbol zip you need:\ngh release download v42.5.0-14525058 \\\n    --repo microsoft\u002Fvscode-electron-prebuilt \\\n    --pattern \"stable-symbols-v42.5.0-win32-x64.zip\"\n```\n\nThe releases are tagged by **Electron version**, not VS Code version, so first find the Electron version the crashed VS Code build shipped. It's the `nativeBuild.target` field of that version's `package.json` (e.g. `git show \u003Cversion>:package.json | node -p \"JSON.parse(require('fs').readFileSync(0, 'utf8')).nativeBuild.target\"`). Versions released before that field existed have it as the `target=` in `.npmrc` (e.g. `git show 1.128.0:.npmrc`). Then pick the matching symbol zip by **quality, platform, and architecture** — e.g. a Stable Windows x64 crash on Electron 42.5.0 needs `stable-symbols-v42.5.0-win32-x64.zip` (use `insiders-symbols-…` for Insiders). Code - OSS symbols come from the public [electron\u002Felectron releases](https:\u002F\u002Fgithub.com\u002Felectron\u002Felectron\u002Freleases) and can be downloaded without special access.\n\n> **These zips are small and selective.** A `*-symbols-*.zip` typically contains only a handful of first-party modules — `electron.exe.sym`, `libEGL.dll.sym`, `libGLESv2.dll.sym` on Windows (and the equivalents elsewhere). Many modules that show up in a backtrace — notably `runtime.node` and any OS\u002Fthird-party DLL — are **not** in these zips. `runtime.node` frames often cannot be symbolicated at all from public symbols; when the crash is in a third-party module, attribute it by module name rather than expecting method names on every frame (see [Reading the result](#reading-the-result)).\n\n### 3. Copy the `.sym` files into the electron-minidump cache\n\nThe cache lives at:\n\n```bash\n\"$(npm root -g)\u002Felectron-minidump\u002Fcache\u002Fbreakpad_symbols\"\n```\n\nBreakpad keys symbols by `\u003Cmodule>.pdb\u002F\u003Cdebug-id>\u002F\u003Cmodule>.sym`, and the `\u003Cdebug-id>` **must match exactly** between the dump and the symbol zip — a same-version zip built from a different pipeline run will have a different id and won't be used. After the initial pass, the cache already contains an (empty) directory for each required module whose name and hash you must match:\n\n```bash\nCACHE=\"$(npm root -g)\u002Felectron-minidump\u002Fcache\u002Fbreakpad_symbols\"\n# The debug-id electron-minidump wants for a given module:\nls \"$CACHE\u002Felectron.exe.pdb\"     # e.g. DD081533CD7E33A44C4C44205044422E1\n```\n\nUnzip the downloaded symbols and confirm the same module\u002Fhash exists in the zip before copying it in. The zip's internal layout is also `\u003Cmodule>.pdb\u002F\u003Cdebug-id>\u002F\u003Cmodule>.sym`.\n\nExample (Windows: the shipped main binary is `Code.exe`, but its symbols come from `electron.exe.sym`):\n\n```bash\n# Unzip somewhere, e.g. ~\u002Fstable-symbols\u002F\nunzip stable-symbols-v42.5.0-win32-x64.zip -d ~\u002Fstable-symbols\n\n# Only copy if the debug-id matches what the cache expects.\n# Keep the tilde outside quotes so it expands to your home directory:\nHASH=DD081533CD7E33A44C4C44205044422E1\ncp ~\u002Fstable-symbols\u002Fsymbols\u002Felectron.exe.pdb\u002F\"$HASH\"\u002Felectron.exe.sym \\\n   \"$CACHE\u002Felectron.exe.pdb\u002F$HASH\u002F\"\n```\n\nOn macOS the analogous module is `Electron Framework` (`Electron Framework\u002F\u003Chash>\u002FElectron Framework.sym`). Repeat for any other module the initial pass reported as missing method names — but only when the zip actually contains a matching-hash `.sym` for it.\n\n> **If no matching-hash symbols exist**, you cannot get method names for that module — this is common for officially-shipped Stable\u002FInsiders builds whose exact `electron.exe`\u002F`Code.exe` hash isn't in any public prebuilt zip, and for `runtime.node`. Fall back to attributing the crash by module and process (see [Reading the result](#reading-the-result)); that is usually enough to identify a third-party culprit.\n\n### 4. Re-run symbolication\n\n```bash\nelectron-minidump crash-file.dmp > symbolicated-output.log\n```\n\nThe backtrace in `symbolicated-output.log` should now have method names attached. If some frames are still bare, return to step 2 for the module(s) still missing symbols.\n\n## Reading the result\n\nOnce you have a symbolicated backtrace, turn it into a root cause by answering two questions:\n\n### Which module owns the crash?\n\nLook at the **top frame of the crashing thread** (marked `(crashed)`) and its module name:\n\n- If it's a **VS Code \u002F Electron module** — `Code.exe`, `runtime.node`, `Electron Framework`, `libnode`, `libffmpeg`, V8 frames — the fault is likely inside the product or Electron.\n- If it's a **third-party \u002F OS module** — an antivirus, VPN, proxy, or shell-extension DLL injected into the process — the crash is almost certainly caused by that software, not VS Code. Injected DLLs often appear interleaved with `runtime.node`\u002FV8 frames because they hook the runtime.\n\nFind where the module is loaded on disk to confirm it's third-party. On Windows the `strings` of the dump usually reveal the full path, e.g. a DLL under `C:\\WINDOWS\\system32\\` or a vendor folder rather than the VS Code install directory:\n\n```bash\nstrings -a crash-file.dmp | grep -i \"\u003CSuspectModule>\" | sort -u\n```\n\n### Which process crashed?\n\nThe process type tells you whether this is the main process, a renderer\u002Fwindow, or the extension host. On modern Electron the **extension host runs inside a Node utility process**, so a crash there shows up as the `node.mojom.NodeService` utility — not a process literally named \"extension host\":\n\n```bash\nstrings -a crash-file.dmp | grep -oiE \"utility-sub-type=[a-zA-Z0-9._-]+|node\\.mojom\\.[A-Za-z]+|--type=[a-z-]+\" | sort -u\n```\n\n| Marker | Process |\n|--------|---------|\n| `node.mojom.NodeService` \u002F `utility-sub-type=node.mojom.NodeService` | Extension host (Node utility process) |\n| `--type=renderer` | A workbench window (renderer) |\n| `--type=gpu-process` | GPU process |\n| (no `--type`) | Main process |\n\nMatch this against the reported symptom (e.g. an \"extension host crash-loop\" should correspond to a `NodeService` utility crash).\n\nWhen you have multiple dumps, symbolicate each and compare the crash reason and top frame — an identical signature across dumps confirms a single, reproducible cause.\n\n## Creating a crash report\n\nIf you don't yet have a `.dmp` file, produce one with the `--crash-reporter-directory` option:\n\n1. Close all instances of VS Code.\n2. Run `code --crash-reporter-directory \u003Cabsolute-path>` from the command line (use `code-insiders` for the Insiders build).\n3. Take the steps that lead to the crash.\n4. Look for a `*.dmp` file in that folder.\n\nYou can only symbolicate crashes from a build you have matching symbols for. Crashes from Insiders\u002FStable need the internal Electron symbols; crashes from a local source build (Code - OSS) need the OSS Electron symbols.\n\n## Remote Extension Host crashes (Linux, gdb)\n\nNative crashes in a remote server's extension host use core dumps and `gdb` instead of electron-minidump:\n\n1. Before running the server, allow core dumps: `ulimit -c unlimited`.\n2. Reproduce the crash. Retrieve the core dump via `coredumpctl`, or from the path in `\u002Fproc\u002Fsys\u002Fkernel\u002Fcore_pattern`.\n3. Load it in gdb and capture output:\n    ```bash\n    gdb -se \u003Cpath-to-vscode-server>\u002Fnode -c \u003Cpath-to-core-file>\n    ```\n   Then run and collect the output of:\n    ```\n    set pagination off\n    info sharedlibrary\n    info registers\n    bt full\n    disassemble\n    ```\n\n## Tips\n\n- Keep `crash-file.dmp` and `symbolicated-output.log` out of the repo — they are throwaway artifacts.\n- The cache path is dynamic; always resolve it with `$(npm root -g)` rather than hardcoding a home directory.\n- Breakpad matches symbols by exact debug-id, not by version name. If method names are still missing after adding symbols, confirm the `.sym` you copied has the exact hash the cache directory expects, and double-check the quality (`stable`\u002F`insiders`), platform (`win32`\u002F`darwin`\u002F`linux`), and arch (`x64`\u002F`arm64`) of the symbol zip.\n- Not every frame can be symbolicated. `runtime.node` and third-party\u002FOS modules frequently have no public symbols; identifying the crashing module and process is usually enough to reach a root cause.\n",{"name":5,"description":7},"main","e0de62d9cf9b9e794ac1aca9c69c369510e3d7d5",".github\u002Fskills\u002Fsymbolicate-crash-dump",43820,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode","https:\u002F\u002Fcode.visualstudio.com","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 03:06:27",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add microsoft\u002Fvscode --skill symbolicate-crash-dump",{"tool":56,"command":57},"bunx","bunx skills add microsoft\u002Fvscode --skill symbolicate-crash-dump",{"tool":59,"command":60},"pnpm","pnpm dlx skills add microsoft\u002Fvscode --skill symbolicate-crash-dump","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsymbolicate-crash-dump\u002FSKILL.md",true,[],[65,89,111,125,140,156],{"skillNo":66,"name":67,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":35},"01M70H0ANBKZAVEP1NVV4K28M3","sweeper-query","Answer natural-language questions about the VS Code Sweeper's published issue index (index-\u003Cname>.json for microsoft\u002Fvscode and the enrolled family repos) — which issues are agent-ready to implement or plan, what the sweeper proposed for an assignee or area, whether the sweeper knows a report as a duplicate, the highest-value open bugs in a lane — and, for one issue, the review's full record (evidence with file citations, fix brief, proposed comment). Use ONLY when the request explicitly names the sweeper — \"sweeper\", \"vscodesweeper\", \"sweeper-query\", a sweeper verdict, record, brief or index, an agent-ready issue — or asks what \"the sweeper\" found, proposed or knows. Do NOT use for general questions about issues, duplicates, priorities or ranking that do not mention the sweeper. Read-only; discovery only.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsweeper-query\u002FSKILL.md",[],[72,73,74,75,76,34,77,78,79,80,81,82,29,83,84,85,86,87,88,25],"sweeper query","query","sweeper","review","fix","request","which","natural-language","ranking","duplicates","ready","read","plan","open","Citations","brief","issues",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":35},"01M699DRJS4YJCV600Q72SVVWE","update-skills","Create or update repository skills and instructions when major learnings are discovered during a session. Use when the user says \"learn!\", when a significant pattern or pitfall is identified, or when reusable domain knowledge should be captured for future sessions.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-skills\u002FSKILL.md",[],[96,97,98,99,100,101,102,28,103,104,105,106,107,108,109,110,34],"update","update skills","for","pattern","domain","learnings","reusable","session","user","instructions","knowledge","repository","learn","create","sessions",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":35},"01M699DPWHZ72B66P82EW31RNE","update-pr","Update the pull request for the current session. Use when the user wants to push new changes to an existing PR.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fupdate-pr\u002FSKILL.md",[],[96,118,119,34,77,120,98,28,103,104,121,122,123,124],"pr","update pr","Existing","push","pull","pull request","changes",{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":35},"01M699DJMR6CE1MH5XCJZ0GFQ0","sync","Sync the current session branch with its upstream branch, or publish the current session branch to a remote. Use when the user asks to sync a branch, pull latest changes, rebase onto upstream, push current branch, publish branch, or set upstream.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync\u002FSKILL.md",[],[127,132,133,121,122,134,34,124,135,136,137,138,28,103,104,139],"SET","publish","rebase","latest","with","remote","upstream","branch",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":35},"01M699DGXHX6A2A72X57R6GGHJ","sync-upstream","Update a stale session branch by rebasing onto the latest origin. Use when the upstream has moved significantly and the session needs to catch up, resolving conflicts by preserving upstream changes and adapting session work to fit.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fsync-upstream\u002FSKILL.md",[],[138,127,147,148,34,149,150,124,135,151,152,153,154,28,103,139,155,96],"sync upstream","fit","catch","catch up","origin","conflicts","stale","up","work",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":35},"01M699DEXYFWDGW0BAXJ5QQ377","merge","Merge changes from the topic branch to the merge base branch. Use when the user wants to merge their session's work back to the base branch.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Fvscode\u002Fblob\u002Fmain\u002Fsrc\u002Fvs\u002Fsessions\u002Fskills\u002Fmerge\u002FSKILL.md",[],[158,103,28,155,139,104,34,163,164,124],"back","base"]