GPU process gone 导致 Claude Desktop 卡死——为什么毫不相干的会话也会被一起拖下水
工作到一半 Claude Desktop 突然卡住，开着的 Claude Code 会话全部一起停摆；强制退出再重启，有时应用干脆起不来了——这种时候日志的最后一行往往都是 GPU process gone: { type: GPU, reason: crashed, exitCode: 101457950, serviceName: GPU }。本文要说清楚的是：这个 exitCode 101457950（即 0x060C201E）意味着什么，为什么毫不相干的会话也会被一起拖下水，以及现实中哪些办法能用、哪些用不了。先做切分：就算你感觉是“Claude Code 崩了”，崩掉的其实并不是 Claude Code（CLI），而是承载它的桌面应用（Electron）的 GPU 进程；判断方法很简单，看 %APPDATA%\Claude\logs\main.log 的末尾，如果重启前那一行是 GPU process gone 就是本文这件事。它最难缠的地方在于应用不会消失，而是无响应地留在那里——既不弹崩溃对话框，也不会自己重启，在用户察觉并强制退出之前就那么僵着（笔者机器上观测到的一次长达约 30 分钟，期间开着的 8 个会话全都停着）。全军覆没的原因是结构性的：Electron（Chromium）把渲染集中到一个 GPU 进程里，而这个进程每个应用只有一个，所有窗口、标签页、会话都共享它，所以应用内浏览器里的某一个页面把它弄死，八竿子打不着的会话就会同时遭殃，而且用户没法靠设置把它们隔离开。触发因素方面，公开 issue 里最常见的是应用内浏览器：#80444 记录了 WebGL/WebGPU 能力检测后 15～36 秒 GPU 进程死掉、四次都是同一个 0x060C201E；#82967 把触发点定位到预览截图抓取（capturePreviewScreenshotIfChanged）；#83478 称一直开着不断刷新的预览就能复现。但浏览器不是唯一触发因素——#68049 报告 ARM64 环境下启动时就以同样的 exitCode 崩掉，#83028 称 Intel 集成显卡上能复现。本文还给出用三个文件（main.log、unknown-window.log、Crashpad 目录）确认的方法，以及用 exitCode 区分正常退出的对照表，并特别提醒：同一份日志里的 requestAdapter 警告不是罪魁祸首，那只是 Chromium 告知“在 Windows 上 powerPreference 不起作用”的常规消息，不能拿它当依据。恢复部分讲“修复”能救回来的情况（#80444 的 appxState=2）和救不回来的情况（#82967 走到 Modified, NeedsRemediation 后只能彻底重装），并把能做的与做不了的分开列出——--disable-gpu 在 MSIX 版会以“拒绝访问”被挡回来，更新应用与改驱动设置都有不管用的报告，关掉浏览器功能也只能挡住浏览器引起的那一部分。数据这一块要分开理解：transcript 已经写到磁盘上，重启之后重新打开会话就能接着读，但 #81698 报告说正在执行中的工作整个丢了，连并行跑着的子智能体的结果也一起没了——已保存的留得住，正在跑的回不来。如果用的是混合显卡配置，在 Windows 的显卡设置里给 Claude 固定 GPU 优先级值得一试（依据是 Chromium issue 40268366：Windows 上应用侧无法指定用哪块 GPU 绘制），但并没有找到说这招对本文这件事有效的报告，不要抱太大期望。最后区分了容易混淆的商店更新强制退出（日志留下 Windows session ending (close-app)，不会出现 GPU process gone）。截至 2026 年 8 月 15 日，Anthropic 没有发布任何官方的原因说明或修复公告。
