工作到一半，Claude Desktop 突然卡住，开着的 Claude Code 会话全部一起停摆。强制退出再重启，有时应用干脆起不来了——这种时候，日志的最后一行往往都是同一句话。
GPU process gone: { type: 'GPU', reason: 'crashed', exitCode: 101457950, serviceName: 'GPU' }本文要说清楚的是：这个 exitCode 101457950（即 0x060C201E）到底意味着什么，为什么毫不相干的会话也会被一起拖下水，以及现实中哪些办法能用、哪些用不了。
⚠️ 本文的可信度标签：✅ 已确认＝公开的 issue 里有记录，或笔者在自己的机器上实测过／🟡 据报告＝有多方报告，但没有官方确认／🔴 未确定＝无法断定。Anthropic 没有就这一症状发布任何官方的原因说明或修复公告（截至 2026 年 8 月 15 日所确认的范围）。
一个标签页，把所有会话一起拖下水
—— 因为 GPU 进程是整个应用只有一个的共享资源
1. 结论——出问题的不是 Claude Code，而是装着它的那个容器
先做切分。就算你感觉是“Claude Code 崩了”，崩掉的其实并不是 Claude Code（CLI）。崩掉的是承载它的桌面应用（Electron）的 GPU 进程。
✅ 已确认：判断方法很简单，看 %APPDATA%\Claude\logs\main.log 的末尾就行。如果重启前的那一行是 GPU process gone，那就是本文说的这件事。日志在那里戛然而止，下一行变成 Starting app。
而且要紧的一点是：丢掉的是进程，不是数据。对话记录和 transcript 都已经写到磁盘上，重启之后重新打开会话就能接着读。不过正在执行中的工作是另一回事，这一点放到§6 再说。
2. 症状——不是“崩溃退出”，而是“卡死”
这个故障最难缠的地方在于，应用不会消失，而是无响应地留在那里。既不弹崩溃对话框，也不会自己重启。在用户察觉并强制退出之前，它就那么僵着。
在笔者的机器上（Windows 11 / RTX 2080 Ti / 内存 32GB），2026 年 8 月 14 日观测到的 3 次里，从 GPU 进程死亡到强制退出，最长的一次约 30 分钟。在那期间，开着的 8 个会话全都停着不动。
三种辨别方法
- 不是单个，而是全军覆没——只有一个会话停了，那是别的原因。如果同一分钟里有多个会话重启，那就是应用本体崩了
- 日志中途断掉——正常退出的话，后面还会有退出处理的行。本文这件事是在
GPU process gone之后连写入本身都停了 - 没有转储文件——如果
%APPDATA%\Claude\Crashpad\下的转储没有增加，那就不是 CLI 那边的原生崩溃
3. 为什么毫不相干的会话也会被一起拖下水
这里是这个故障的本质，也是它不是靠改设置就能解决的问题的原因。
Electron（Chromium）把渲染处理集中到一个叫 GPU 进程的专用进程里。而这个进程，每个应用只有一个。所有窗口、所有标签页、所有会话都共享着它。
也就是说，只要应用内浏览器里打开的某一个页面把 GPU 进程弄死，跟那个页面八竿子打不着的会话就会同时遭殃。它并没有按标签页、按会话做隔离。✅ 已确认：这是 Chromium 的进程模型在设计上就这样，用户没法靠设置把它们隔离开。
一个 GPU 进程，被全部共享
4. 触发因素——应用内浏览器最常见，但不是唯一
✅ 已确认：在公开的 issue 里，最常见的触发因素是应用内浏览器（浏览器面板）。#80444 记录了这样的过程：在浏览器标签页里打开的页面跑了 WebGL/WebGPU 的能力检测，15～36 秒之后 GPU 进程死掉，而且四次都是同一个 0x060C201E。
#82967 更具体，把触发点定位到了浏览器工具的预览截图抓取（capturePreviewScreenshotIfChanged）。#83478 则报告说，“一直开着不断刷新的预览”就能复现。
🟡 据报告：不过浏览器并不是唯一的触发因素。#68049 报告在 ARM64 环境下启动时就以同样的 exitCode 崩掉，全程没有任何浏览器操作。#83028 称在 Intel 的集成显卡上能复现。“只要不用浏览器就绝对不会发生”这话是说不出口的。
💡 笔者机器上的实测（不能一般化）：在调研 AI 工具的过程中，做在应用内浏览器里以 1～2 秒的间隔连着打开 4 个页面这个操作，同一天做了约 18 次，其中 3 次 GPU 进程死掉了。并不是每次都崩，只有在几个很重的页面正好凑到一起的时候才崩。这是在一台机器上的观测，所以频率本身没法套用到别的环境。
5. 用日志来确认
别停留在猜测上，看三个文件就能确定。另外要注意，~/.claude/logs 这个目录并不存在。
| 看什么 | 路径 | 判断 |
|---|---|---|
| 应用本体 | %APPDATA%\Claude\logs\main.log | 重启前面那一行是 GPU process gone 就是本文这件事 |
| 浏览器窗口 | %APPDATA%\Claude\logs\unknown-window.log | 同一时刻有 CONTEXT_LOST_WEBGL，说明从渲染这一侧看 GPU 也确实掉了 |
| 原生崩溃 | %APPDATA%\Claude\Crashpad\ | 转储没有增加，就不是 CLI 那边的故障 |
⚠️ 同一份日志里出现的 requestAdapter 警告，不是罪魁祸首。“The powerPreference option is currently ignored when calling requestAdapter() on Windows.”这一行并不是崩溃的征兆，而是 Chromium 用来告知“在 Windows 上 powerPreference 不起作用”的常规消息（Chrome for Developers／Chromium issue 40268366）。只要打开用了 WebGPU 的页面，即使不崩它也会出现。不要把“出现了这一行”本身当作依据。
可以用 exitCode 把正常退出区分出来。 同样是“退出”，含义并不相同，我们只想去追该追的那一个。
| exitCode | 十六进制 | 含义 |
|---|---|---|
101457950 | 0x060C201E | 本文这件事的特征码。该追的就是它 |
-1073741205 | 0xC000026B | 注销／关机时出现。正常 |
1073807364 | 0x40010004 | 有意为之的退出。正常 |
6. 恢复——“修复”能救回来的情况，和救不回来的情况
强制退出再重启，多数时候就能照常用下去。麻烦的是想重启却发现应用起不来了这种情况。
✅ 已确认：GPU 崩溃之后，Windows 有时会判定 MSIX 包“已被更改”，进而拒绝启动。#80444 把这一点记录为 appxState=2（Modified），并报告说通过 设置 → 应用 → Claude → 高级选项 → “修复”，每次都能恢复。#81836 同样称用“修复”就能救回来。
接下来这部分，我认为是本文最实用的地方。也存在“修复”不管用的报告。#82967 报告说包的状态已经走到 Modified, NeedsRemediation，“修复”总是失败，只有彻底卸载并重新安装才救得回来。
起不来的时候，按这个顺序来
- 先结束常驻进程——只要它还占着文件，“修复”就会以“正在运行”为由被拒
- “修复”——设置 → 应用 → 已安装的应用 → Claude → 高级选项。数据会保留
- 还是不行就卸载重装（需要重新登录）
详细步骤，以及对话记录和会话到底会不会没，都整理在“无法打开这个应用”的修复步骤里。
关于数据。transcript 留在磁盘上，重启之后可以重新读。不过 #81698 报告说“正在执行中的工作整个丢了。并行跑着的子代理的结果也全没了”。已保存的东西留得住，正在跑的东西回不来——这两者要分开理解。
7. 能做的，和做不了的
遗憾的是没有根治的办法。能做的只是让触发更不容易发生，而且其中还混着“有报告说不管用”的招数，所以这里分开写。
- 别在应用内浏览器里打开很重的页面。挪到真正的浏览器里去
- 别一口气开好几个页面。把间隔拉开
- 别让预览一直开着（#83478 的复现条件）
- 把浏览器功能本身关掉——#82967 提出的规避办法。但能挡住的只是浏览器引起的那一部分，对启动时就崩的那一类（#68049）没用
- 别把长活儿都堆在一个会话里。恢复后重新读起来会轻松些
--disable-gpu用不了——MSIX 版会以“拒绝访问”被挡回来（#82967）- 更新应用治不好——笔者的机器上，更新后的版本照样复发
- 把 GPU 进程隔离开——结构上做不到（§3）
- 改 GPU 调度或驱动设置——#82967 试了好几种，报告说没有效果
🟡 据报告：如果你用的是混合显卡（在集成显卡和独立显卡之间切换的配置），那么在 Windows 的 设置 → 系统 → 显示 → 显卡 里给 Claude 固定 GPU 的优先级值得一试。依据在 Chromium 那边：在 Windows 上，通过 powerPreference 指定 GPU 是不起作用的——因为 Chrome 还做不到同时用两块 GPU 分工合成，这件事作为 Chromium issue 40268366 在跟踪。也就是说应用这一侧没法固定用哪块 GPU 来绘制，想固定就只能靠操作系统的设置。不过，并没有找到说这招对本文这件事有效的报告，所以别抱太大期望。
8. 容易混淆的另一种现象——应用商店更新导致的强制退出
Microsoft Store（MSIX）版把应用自身的自动更新关掉了。取而代之的是，商店会强制退出正在运行的应用再换掉它。因为应用会在工作过程中突然消失，很容易和 GPU 崩溃搞混。
用日志能清楚地区分开。 商店更新的时候会留下 Windows session ending (close-app) 这一行，而且不会出现 GPU process gone。下次启动时版本号变了，就可以确定了。
这一种躲不掉，所以唯一的缓解办法是在开始长时间的工作之前先把更新做完。
总结
- 真身：不是 Claude Code 的故障，而是桌面应用的 GPU 进程崩溃（
exitCode 101457950/0x060C201E） - 全军覆没的原因：GPU 进程是每个应用只有一个的共享资源。一个标签页就能把所有会话一起拖下水。设置里没法隔离
- 触发因素：应用内浏览器最多。但也有启动时崩溃的报告，它不是唯一
- 确认步骤：看
main.log里重启前的那一行。是GPU process gone就是本文这件事 - 恢复：强制退出→重启。起不来了就用“修复”。也有报告说会走到“修复”不管用的地步
- 数据：已保存的留得住，正在执行中的工作回不来
- 官方没有发布修复公告（截至 2026 年 8 月 15 日）
常见问题
Q. 对话记录会没吗？
A. 不会。transcript 已经写到磁盘上，重启之后重新打开就能读。不过崩溃那一瞬间正在跑的工作会丢——有报告说连并行跑着的子代理的结果也一起没了（#81698）。
Q. 更新应用就能修好吗？
A. 不一定。 在笔者的机器上，更新后的版本也以同样的特征码复发了。不过 #80444 是作为从某个特定版本开始的回归（regression）来报告的，所以不同版本的发生难易程度有可能不一样。
Q. 更新显卡驱动能修好吗？
A. 这一招很弱。 如果原因出在驱动这一层，Windows 的系统日志里会记录 TDR（事件 ID 4101），但笔者的机器上 30 天里一条都没有出现。#68049 也报告说，更新驱动并做了干净的重装之后，问题照样复发。
Q. 会不会是内存不够，或者 transcript 太大了？
A. 在笔者的机器上这两点都被否掉了。崩溃时 Electron 全部进程加起来约 1.7GB，可用内存是 31.9GB 中的 14.8GB。也有会话的 transcript 长到了 98.5MB，但和崩溃的时刻并没有相关性。
Q. 只有一个会话停了，也是同一回事吗？
A. 不是。本文这件事是应用本体卡死，所以必然是全军覆没型的。 只停了一个的话，请怀疑别的原因。如果只是回答写到一半被切断，那属于 Connection closed mid-response 或 response stalled mid-stream 那一类。
相关文章
- Claude Desktop“无法打开这个应用”——用“修复”解决的步骤（本文问题的善后）
- “另一个程序正在使用此文件”(0x80070020)（更新后起不来的另一个问题）
- Claude Code 错误总览
