[Bug] 0.2.1-rc.3 桌面端：零第三方插件下 host/renderer 循环崩溃（crypto_context.cc:884 / absl raw_hash_map::at / renderer 静默退出）

[lanchesis]

## TL;DR

DSH Desktop `0.2.1-rc.3`（nightly，Electron 44.7.0 / Node 24.21.0，Windows 11 25H2 build 26200.9711）在**不加载任何第三方插件**时仍循环崩溃，三类失败交替出现：

1. `node::crypto::InitializeBundledRootCertificates()` @ `crypto_context.cc:884` → `Assertion failed: (x509) != nullptr`（宿主启动期、插件操作子进程各复现）
2. `absl::container_internal::raw_hash_map<>::at` → `NOTREACHED hit`（壳进程，有完整 dump）
3. renderer 反复 `Desktop renderer exited: crashed`，**无 console、无 WER、无 dump**

安装包与安装结果均已逐字节校验，排除文件损坏。

## 环境

- DSH Desktop `0.2.1-rc.3`（channel: nightly，2026-10-27 00:39 更新落地，覆盖 rc.2）
- Electron 44.7.0 / Node 24.21.0 / win32 x64
- Windows 11 25H2 (build 26200.9711)，Intel Core i9-14900，BIOS microcode 0x12B
- 触发时 `dsh.profile.bundles` 仅含 `@deepseek-ai/dsh-base`、`@deepseek-ai/dsh-web-app`（第三方插件全部停用）

## 复现

1. 冷启动应用，约 1/3 概率在启动后 1 分钟内出现上述断言或 renderer 崩溃；
2. 在插件管理里安装/卸载任意插件（会拉起 `DeepSeek Harness.exe` 的 node 模式子进程），子进程有较大概率以同一 crypto 断言 abort，UI 显示「卸载失败」，重试通常成功；
3. renderer 崩溃后应用自动重启，随后再次崩溃，形成循环。

## 证据（详见附件）

### 1) 宿主启动期 crypto 断言

Error: dsh desktop host exited with 134:
DeepSeek Harness.exe[23928]: std::vector<X509 *> __cdecl
node::crypto::InitializeBundledRootCertificates(void)
at ....\third_party\electron_node\src\crypto\crypto_context.cc:884
Assertion failed: (x509) != nullptr

发生在 Node 环境初始化（`phase: startup`），插件代码尚未加载。

### 2) 插件操作子进程，同一函数同一行

DeepSeek Harness.exe[13280]: ... crypto_context.cc:884
Assertion failed: (x509) != nullptr
---- Native stack trace ----
1: node::SetAbortHandler+54
2: v8::SharedArrayBuffer::ByteLength+2976
3: uv_exepath+218701
4: uv_exepath+216047
5: node::loader::ModuleWrap::SetInitializeImportMetaObjectCallback+24783
6: llhttp_execute+133739
7: uv_cond_signal+286655
8: BaseThreadInitThunk+23
9: RtlUserThreadStart+44

### 3) 壳进程 absl NOTREACHED（有完整 dump）

`dumps/DeepSeek Harness.exe.24360.dmp` 解析：PID 24360，启动即崩（创建时间 = 崩溃时间 20:43:57），22 线程含 4 × `V8Worker`，崩溃线程 `V8Worker`（tid 24184），异常 `0x80000003` @ `exe+0x7356e49`，栈上保留：

[24360:1027/204357.553:FATAL:throw_delegate.cc:107] NOTREACHED hit.
absl::container_internal::raw_hash_map<>::at

模块表 39 项：仅 exe + 38 个 `C:\Windows\System32\*.dll`，无第三方 DLL。

### 4) 宿主无断言退出，退出码 `4294930435`

Error: dsh desktop host exited with 4294930435:
[llm-deepseek-api-key] model listing ... loaded 2 model(s) ...
[1027/215622.075:ERROR:crashpad_client_win.cc:867] not connected

`4294930435 = 0xFFFF7003 = -36861`，非标准 NTSTATUS。同一码也出现在 `subprocess-local: Windows Job runner exited with exit code 4294930435 before proving its managed range empty`。怀疑与 `dsh-subprocess-local` 的 Job Object（`JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`）生命周期/退出码有关。

### 5) renderer 静默退出

多次 `Desktop renderer exited: crashed`，`renderer console` 为空，事件日志无 Application Error，已开启 `LocalDumps DumpType=2` 仍无 dump。更像被结束（Job/`TerminateProcess`）而非页错误。

## 已排除

- **第三方插件（全部）**：卸载 dshmarket 后仍崩；`bundles` 仅 base + web-app 时仍连续崩溃（22:03:33 / 22:03:54）。
- **安装包/安装结果损坏**：安装包 SHA-512 与 `update-info.json` 一致；外层 NSIS 与内层 `app-64.7z` 完整性测试通过（7,811 文件 / 1.09 GB）；`app.asar` 16,603 块 / 177.7 MB 全部匹配；安装目录与官方 payload 逐文件 SHA-256 比对 7,811/7,811 一致。
- **内存**：系统内压测 8 GiB × 3 轮、24 次回读校验，0 不一致。
- **联想电脑管家 minifilter**（本机历史蓝屏原因）：已彻底移除，之后无新蓝屏。

## 附件

`dsh-crash-report-20261027-redacted.zip`（已脱敏：用户名/主机名/机型替换为占位符；dump 用等长占位符替换，结构与偏移不变，可正常加载）

内容：12 次崩溃日志、壳进程 dump、插件操作子进程断言日志、更新器记录（含两次解压 CRC 失败）、profile 快照、系统事件与应用崩溃记录、完整分析报告 `README.md`。
[dsh-crash-report-20261027-redacted.zip](https://github.com/user-attachments/files/34023660/dsh-crash-report-20261027-redacted.zip)

[lanchesis]

追加一条（提交反馈过程中再次复现，间隔不到 10 分钟）：

• 时间：2026-10-27 22:11:05（本地 +08:00），0.2.1-rc.3 / Electron 44.7.0 / Node 24.21.0
• 场景：正在浏览器里编辑这条反馈，应用处于空闲/输入状态；没有安装或卸载插件，也没有打开插件市场
• 现象：Desktop renderer exited: crashed，renderer console 为空，无 WER 事件、无 dump
• 配置：dsh.profile.bundles 仅 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app（第三方插件全部停用）
• 累计：本次会话已记录 13 次崩溃事件（12 份 crash-*.log + 1 次仅有 WER dump 的壳进程崩溃），其中 4 次在零插件配置下

补充：这说明触发条件不限于"插件操作"或"市场页面渲染"，空闲输入时同样会崩，更像运行时层面的随机/定时触发，而不是某个用户操作路径。

附件：crash-2026-10-27T14-11-05-152Z-renderer.log（已确认不含用户名/主机名，可直接公开）:

time: 2026-10-27T14:11:05.152Z
source: renderer
phase: running
app: @deepseek-ai/dsh-desktop 0.2.1-rc.3
platform: win32 x64
electron: 44.7.0
node: 24.21.0
locale: zh-CN
shell pid: 596

--- error ---
Error: Desktop renderer exited: crashed
at WebContents. (file:///D:/DeepSeek%20Harness/resources/app.asar/lib/main.js:12933:107)
at WebContents.emit (node:events:526:24)

--- renderer console (error level, oldest first) ---
(no error-level renderer console output was captured)
crash-2026-10-27T14-11-05-152Z-renderer.log

[lanchesis]

补充：定位到一个具体的数据问题，可能与部分崩溃相关。

会话 session-8d4bb24f-...（8.5 MB）报：
corrupt Zstandard session log: frame at byte 5030568 failed validation

但用标准 zstd 逐帧解码该文件：7,612 帧全部可解、12,538 行 JSON 全部合法、0 坏帧；
5,030,568 正好是第 4,224 帧的起点。截断到该帧之前的副本可以正常加载，
应用随后把投影缓存从 2.1 MB 重建为 12 KB，会话恢复。

疑似 session reader 的帧校验与标准 zstd 不一致（或与投影缓存的一致性检查有关），
不是磁盘损坏。原文件样本可提供。

[lanchesis]

补充 2：定位到一个可复现的渲染崩溃。

会话 session-8d4bb24f-...：6,991 个事件 / 16.8 MB 解码文本（811 条 assistant、
1,109 条 tool/result）。每次点开该会话，renderer 立即 crashed，无 console、
无 WER、无 dump；其它 2 MB 级会话正常。

截断到 59%（5 MB）后仍然崩，说明与单个坏帧无关，而是全量渲染 7k 事件时渲染进程被压垮
（疑似 OOM 被杀）。建议为大会话检查是否有虚拟滚动 / 分页加载。

[lanchesis]

补充 3：对前两条补充的更正（离线逐帧验证后）

先给结论：补充 1 里「session reader 的帧校验与标准 zstd 不一致」这个定性不准确，需要更正。 该会话文件的数据没有损坏，被拒绝的那一帧本身也完全合法。

1) 被拒的那一帧可以完整解剖

对原始样本（8,533,307 字节）逐帧扫描后，字节 5,030,568 的位置：

• 是索引 4,224（0-based）的帧起点，帧长 657 字节
• 帧头、block 边界、last_block 标记、content checksum 全部符合 zstd 规范
• 单独解压成功，输出 900 字节，是合法 JSON
• 内容是一条正常事件：agent/inbox/spliced，seq 6989，time 2026-10-24 19:07:56
• 前一事件 seq 6988，连续无跳号；下一帧起点 5,031,225 = 5,030,568 + 657，完全吻合

也就是说，frame at byte 5030568 failed validation 不可能是 zstd 结构层面的结论——这一帧从帧头到 checksum 都符合规范。

2) 全文件审计：零坏帧

指标	数值
文件大小	8,533,307 字节
帧总数	7,612
结构完整帧	7,612（100%）
不完整/越界帧	0
解码失败帧	0
事件总数（解压后 JSON 行）	12,538
seq 范围	0 → 12,536，严格单调递增
seq 回退次数	0
重复 seq	0
非 JSON 行	0
末帧	session/end-seed seq 12536（10-26 01:52），正常收尾

不仅在 zstd 层面，在事件流层面（seq 连续性、类型闭合性，step/start 1492 = step/end 1492）也找不到任何损坏迹象。

3) 定性更正

不是「读取器的帧校验与标准 zstd 不一致」。更准确的说法是：

文件在 zstd 结构和事件流层面都合法，读取器仍然在字节 5,030,568 处拒绝它 —— 说明读取器在 zstd 解帧之上还有一层额外的校验，且这层校验的错误信息把「与日志本身无关的不一致」错误地表述为「帧校验失败」。

一条可能相关的线索：投影缓存体积异常。

• 该会话截断后可正常加载，投影缓存从 2.1 MB 重建为 12 KB
• 目前本机 21 个会话的投影缓存体积区间为 4,618 ~ 556,714 字节
• 2.1 MB 超出这个区间数倍

怀疑读取器会把投影缓存里记录的 throughSeq / 字节偏移与会话日志交叉比对，不一致时抛出这条错误。建议检查该路径，并把「投影缓存与日志不一致」与「帧结构损坏」区分为两类错误——目前两者共用同一条文案，会误导排查方向（我本人就被误导了三天）。

4) 需要披露：我原先打算提供的样本已不是原始状态

本地修复脚本在 2026-10-28 00:45:45 向该文件尾部追加了一个 83 字节的 session/end-seed 帧：

{"type":"session/end-seed","seq":6989,"time":1793119545286,"data":{}}

该帧的 time 字段 = 2026-10-28 00:45:45，与文件 mtime 一致。这个帧不是 DSH 写入的，是修复脚本合成的。

因此会话目录里当前那份 5,030,651 字节的文件是「人工缝合」结果（5,030,568 + 83），不能作为原始样本。

请以 8,533,307 字节的原始文件为样本（我这边备份为 session.v4.jsonl.zstd.corrupt-backup），需要时我可以提供。

5) 补充 2 的渲染崩溃假设：需要拆成两件事

补充 2 里「截断到 59% 仍崩」这一步，现在需要区分两种不同的崩溃：

• 加载阶段的校验拒绝（报 failed validation，不进入渲染）
• 加载成功后的渲染崩溃（无 console / 无 WER / 无 dump）

补充 1 已记录：截断后可以正常加载，投影缓存也重建成功。那么补充 2 的崩溃发生在渲染阶段，两者不是同一个问题，建议分开跟踪。要干净地测渲染负载，需要「截断到 N 个事件 + 补一个合法 session/end-seed」再打开，否则事件数量和流结尾两个变量同时在变。

6) 今天（rc.2）的新实例，供参考时序特征

• 21:02:58 新建会话并发出首条 prompt
• 21:03:23 renderer crashed —— 新建会话后 25 秒，无 console、无 WER、无 dump
• 21:03:25 应用自动重启
• 21:05:32 同一会话继续正常发消息
• 21:08:25 / 21:08:35 派生 4 个 subagent 并行工作
• 此后稳定运行 10 分钟以上，未再崩

该会话文件仅约 0.8 MB，与「大会话」无关。崩溃发生在会话创建后的首轮早期，而崩溃后同一会话可以长时间稳定运行——这个形态更像启动/首轮时序问题，而不是内容规模问题。

---

结论：数据损坏这条线可以排除了。真正值得查的是两点：① 读取器那层额外校验为什么拒绝一个完全合法的文件，以及它的错误信息为什么指向 zstd 帧；② renderer 在什么条件下无 dump 静默退出。需要原始样本、离线解析脚本或更多崩溃日志，我都可以提供。

[lanchesis]

补充4-转储分析：

后续进展：找到了一份 minidump —— 疑似 absl 哈希表 .at() 取不到 key 触发 NOTREACHED
环境：Windows 11（build 26200），DeepSeek Harness 0.2.1-rc.2 与 rc.3，Electron 44.7.0，Node 24.21.0。
崩溃日志里只有一句 Error: Desktop renderer exited: crashed，没有原因；crashpad 也一直没产生 dump（crashpad_client_win.cc:867 not connected）。不过 WER 的本地转储帮我抓到了一份：
%LOCALAPPDATA%\CrashDumps\DeepSeek Harness.exe.24360.dmp（3.9 MB，本地时间 2026-10-27 20:44:01），对应 crash-2026-10-27T12-44-36-978Z-renderer.log。
用 cdb !analyze -v 分析得到：

ExceptionCode:    80000003 (Break instruction exception)
ExceptionAddress: 00007ff7`b80d6e49 (DeepSeek_Harness+0x0000000007356e49)
Process Uptime:   0 days 0:00:04.000
System Uptime:    0 days 0:03:01.054

也就是说，renderer 是被 INT3（__debugbreak）打死的，崩溃地址落在应用自己的映像里，而进程才启动 4 秒，页面还没渲染出来。
在 dump 内存里搜索诊断字符串，只能搜到一条 FATAL：

FATAL:throw_delegate.cc:107] NOTREACHED hit. absl::container_internal::raw_hash_map<>::at

desktop host 进程里是同一个签名。 2026-10-26 16:33，host 以 3221226505（0xC0000409，__fastfail）退出，抓到的 stderr 是：

[throw_delegate.cc : 107] RAW: absl::container_internal::raw_hash_map<>::at

所以 renderer 和 desktop host 死于同一个故障：用 .at() 去查一个不存在的 key → absl 抛异常 → Chromium 的 throw 代理走 NOTREACHED → __debugbreak() → INT3 → 进程立即结束。既不抛 JS 异常，也走不到任何错误边界，没有恢复机会。
崩溃时的模块清单里没有任何第三方 DLL，只有 DeepSeek_Harness.exe 加上 30 个系统 DLL（kernel32、user32、ntdll、combase、shell32、crypt32、msctf、DWrite 等）。所以既不是杀软注入，也不是第三方原生模块，更不是 GPU / 驱动问题。
另外还有一处不同的原生中止，一并附上。2026-10-27 12:43 host 以 134（SIGABRT）退出：

Assertion failed: (x509) != nullptr
node::crypto::InitializeBundledRootCertificates at ..\..\third_party\electron_node\src\crypto\crypto_context.cc:884

同样发生在 Electron / Node 内部，不在应用层 JS，也发生在启动阶段。

已经排除掉的方向，供参考，以免重复排查：
不是硬件：同一个故障固定落在同一个代码地址上，且 INT3 是软件主动中止，不是访问违例。
不是第三方插件：零第三方 bundle 时同样复现；上述 dump 的模块清单里也只有应用和系统 DLL。
不是安装损坏：安装目录已逐个文件核对过（7,812 个文件全部来自同一构建），并且全新重装后仍能复现。
不是会话文件损坏：会话存储可以完整解析（帧结构完整，事件 seq 严格单调）。
部分 host 日志里出现的 0xFFFF7003 只是「crashpad 连不上崩溃处理程序」，不能用来判断最初的异常原因。

可能有用的一些建议：
在桌面端构建里找一下 absl::flat_hash_map<...>::at(...)（即 absl::container_internal::raw_hash_map<>::at）的调用点，改成能容忍缺失 key 的写法（find() + 兜底），让过期或意外的 key 走降级路径，而不是直接 NOTREACHED。
如果这个查找是按 locale / 资源标识来做的，那么某个 UI 语言或会话状态下缺一个 key，就会让崩溃表现为「取决于内容」而不是「取决于时间」，这也能解释为什么发生时机看起来很随机。
crashpad 目前连不上（not connected），等于每次崩溃都丢掉 dump。单把这一点修好，现场诊断就会容易得多。
如果需要，我可以把完整 minidump 和 cdb 输出上传。