symbolicate-crash-dump

Symbolicate native VS Code crash dumps into readable backtraces using electron-minidump.

Updated Sep 3, 2026
One-click install
npx skills add https://github.com/az0512124155azz-sys/CodeForge --skill symbolicate-crash-dump-az0512124155azz-sys
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: symbolicate-crash-dump
Source: https://github.com/az0512124155azz-sys/CodeForge/tree/main/.github/skills/symbolicate-crash-dump
Command: npx skills add https://github.com/az0512124155azz-sys/CodeForge --skill symbolicate-crash-dump-az0512124155azz-sys

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires electron-minidump.

What problem does it solve? Native VS Code crash dumps (.dmp files) contain raw memory addresses instead of readable method names, making root-cause analysis nearly impossible without the correct Electron symbol files and a multi-step symbolication workflow. ## Core Features & Use Cases - Crash Dump Symbolication: Runs electron-minidump against a .dmp file and resolves missing method names by matching Breakpad debug-ids with the correct symbol zips. - Symbol Acquisition Guidance: Directs you to the right symbol source — the private microsoft/vscode-electron-prebuilt releases for Insiders/Stable builds, or public electron/electron releases for Code - OSS — matched by Electron version, quality, platform, and architecture. - Crash Attribution: Identifies which module and process type (main, renderer, GPU, or extension host via node.mojom.NodeService) crashed, distinguishing product faults from third-party DLL injection. - Use Case: A user reports an extension host crash-loop on Windows. You obtain the .dmp file, run the initial symbolication pass, download the matching stable-symbols zip via the GitHub CLI, copy the .sym files into the cache, and produce a backtrace showing the crash originates in an injected antivirus DLL rather than VS Code. ## Quick Start Symbolicate the attached crash dump file crash-file.dmp and tell me which module and process caused the crash.

Frequently Asked Questions about symbolicate-crash-dump

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I symbolicate a VS Code crash dump file?▼

Install electron-minidump globally via npm, then run electron-minidump crash-file.dmp to generate a backtrace. If frames lack method names, download the matching symbol zip for your build's Electron version and copy the .sym files into the electron-minidump breakpad_symbols cache, then re-run.

Where do I download Electron symbol files for VS Code Insiders or Stable?▼

Insiders and Stable symbols come from the private microsoft/vscode-electron-prebuilt releases, downloaded with an authenticated GitHub CLI using gh release download. Code - OSS symbols are publicly available from electron/electron releases. Match the zip by Electron version, quality, platform, and architecture.

Can I symbolicate a crash dump on Windows?▼

No, electron-minidump does not run on Windows; you need a macOS or Linux device to perform symbolication. The crash dump itself can come from any platform, including Windows, as long as you process it on a supported machine.

Why are method names still missing after adding symbol files?▼

Breakpad matches symbols by exact debug-id, not version name, so the .sym file's hash must exactly match the directory the cache expects. This commonly fails for officially-shipped builds whose exact binary hash is not in any public prebuilt zip, and for runtime.node, which often has no public symbols.

How do I identify which process crashed in an Electron dump?▼

Search the dump strings for markers like --type=renderer, --type=gpu-process, or utility-sub-type=node.mojom.NodeService. The extension host runs as a NodeService utility process in modern Electron, while no --type marker indicates the main process.

How do I debug a remote VS Code server extension host crash on Linux?▼

Remote extension host crashes produce core dumps rather than .dmp files. Enable core dumps with ulimit -c unlimited, retrieve the core via coredumpctl, then load it in gdb against the server's node binary and collect backtrace, registers, and shared library info.