必须查main.log和sharedprocess.log：main.log记录主进程启动全过程，定位gui弹出前崩溃点；sharedprocess.log揭示跨进程通信失败，如failed to connect或eacces错误；配合code --log trace --enable-logging生成全链路日志，再用grep快速筛选关键错误。
VSCode 深度崩溃（比如启动失败、主进程闪退、界面完全无响应）必须查系统级日志，不能只看 Output 面板或开发者工具——那些只反映渲染层问题，真正卡死点藏在 main.log 和 sharedprocess.log 里。
main.log 是定位启动卡点的第一现场
它记录 Electron 主进程从初始化到窗口创建的全过程，崩溃若发生在 GUI 弹出前，main.log 就是唯一线索。终端运行 code --verbose 后没弹窗？最后一行成功的日志后面紧跟着的报错，基本就是根因。
- Windows 路径：
%APPDATA%\Code\logs\<timestamp>\main.log</timestamp> - macOS 路径：
~/Library/Application Support/Code/logs/<timestamp>/main.log</timestamp> - Linux 路径：
~/.config/Code/logs/<timestamp>/main.log</timestamp> - 常见致命错误：
Error: Cannot find module（核心模块损坏）、Failed to create CoreImage context（macOS 显卡驱动不兼容）、OOM killed process（内存不足被系统回收）
sharedprocess.log 揭露跨进程通信失败
当 VSCode 多窗口共用一个共享进程时，插件安装、设置同步、远程连接等操作都依赖它。如果反复提示“无法加载扩展”或“设置未保存”，但 exthost.log 看不出异常，就得翻 sharedprocess.log。
- 它和
main.log在同一时间戳文件夹下，文件名固定为sharedprocess.log - 重点搜：
failed to connect、permission denied、EACCES（尤其 Linux 下$XDG_RUNTIME_DIR权限错误）、dbus相关超时 - 删掉整个
logs/<timestamp></timestamp>文件夹再重启，能排除日志轮转逻辑干扰判断
code --enable-logging --log trace 生成全链路调试日志
普通日志太简略，偶发崩溃抓不到上下文？这个组合参数强制输出带进程 ID 和毫秒级时间戳的原始事件流，覆盖主进程、渲染进程、扩展主机三端混合日志。
- 先关闭所有 VSCode 实例
- 终端执行：
code --log trace --enable-logging（macOS/Linux）或code --log trace --enable-logging（PowerShell/CMD，别用 Git Bash） - 复现崩溃后立即
Ctrl+C中断，当前目录会生成vscode-debug.log - 该文件体积大，用
grep -A 5 -B 5 "ERR\|crash\|abort"快速定位关键段，比全文阅读高效得多
崩溃后连 logs 文件夹都打不开？试试 --disable-gpu 快速验证
很多“深度崩溃”本质是 GPU 渲染线程锁死，导致主进程卡在 createWindow 阶段，连日志写入都失败。此时 --disable-gpu 是最轻量的验证手段。
- 终端运行：
code --disable-gpu，如果能正常启动，基本锁定显卡驱动或 Electron WebGL 兼容问题 - macOS 用户遇到
Failed to create CoreImage context，大概率需升级系统或换用 VSCode ARM64 原生版（1.75+） - Windows 上若伴随
igd10iumd64.dll报错，说明 Intel 核显驱动过旧，更新驱动或禁用 GPU 加速即可绕过
真正难排查的崩溃，往往不是某一行报错，而是多个日志文件中同一时间戳下的几条看似无关的警告拼起来才指向真相——比如 main.log 里一句 failed to load native module，配上 sharedprocess.log 里的 EACCES，再加上 vscode-debug.log 中某次 chmod 调用失败，才能确认是权限配置破坏了原生模块加载路径。
