[Desktop][Windows] 0.2.0-rc.2 host repeatedly crashes with C0000409/C0000005 and broken Crashpad reporting

[Y-Niuniu]

Summary

DeepSeek Harness Desktop's host process crashes repeatedly on Windows 11.

• DeepSeek Harness: 0.2.0-rc.2
• Electron: 44.0.0
• Node.js: 24.18.1
• OS: Windows 11 x64, build 26200
• Installation: per-user installation
• Frequency: 10+ host exits within approximately 48 hours, across multiple sessions
• EXE SHA-256: DF4E91FD91F6BEE19A1990B0E167BFE06ABF8353279D82BBB8E60EDB6BA0D

After the host exits, the UI shows follow-up errors such as Failed to fetch.

Observed failures

The following exit codes have been observed:

• 0xC0000409
• 0xC0000005
• 0xFFFF7003

One full-memory dump captured a 0xC0000409 failure with:

• ExceptionInformation[0] = 0x2
• Faulting address inside DeepSeek Harness.exe
• Dump size: approximately 693 MiB

The 0xFFFF7003 events are accompanied by Crashpad messages such as:

crashpad_client_win.cc:867 not connected

Startup logs also contain:

registration_protocol_win.cc:108 CreateFile: The system cannot find the file specified

I suspect the 0xFFFF7003 events may be a Crashpad handler/diagnostic failure rather than the original memory-corruption exception.

Reproduction

There is currently no single deterministic trigger.
The crashes occur during a mixture of:

• Normal chat generation
• Tool and file operations
• Idle periods
• Different application sessions

The host can also become unresponsive before exiting.

Diagnostics

Crash logs are stored under:
%APPDATA%\@deepseek-ai\dsh-desktop\logs\

Attached Recent Crash Logs

• crash-2026-10-01T18-03-09-670Z-host.log
• crash-2026-10-01T19-53-15-828Z-host.log
• crash-2026-10-01T19-58-29-822Z-host.log

I have a full-memory dump and can provide it through a private channel. I will not upload it publicly because it may contain prompts, session data, file paths, or credentials.

I am also testing the official recovery path with third-party bundles disabled. That experiment is still in progress, so I am not yet claiming that the root cause is either a third-party plugin or the Electron/runtime itself.

Questions

1. Is this a known regression in Desktop 0.2.0-rc.2?
2. Is there a recommended way to repair or enable Crashpad registration on Windows?
3. Can maintainers provide matching PDB/symbol guidance for this build?
4. Is there a private upload channel for the full dump?
5. Which additional logs, command-line flags, or diagnostic tools should I collect?

[chrishotza]

I went through the exact 0.2.0-rc.2 release tree, the Desktop Host lifecycle, Windows-native code paths, crash-report implementation, Koffi history, and the rc.2 release commit. There are a few points that can be stated more precisely.

1. Is this a known regression in Desktop 0.2.0-rc.2?

I could not find a repository issue, discussion, or commit that identifies these C0000409/C0000005 crashes as a known rc.2 regression with a confirmed root cause.

One important detail is that the rc.2 release commit itself (c1b47e41fcd54d20a0f061df28683bfc29ee24e5) is a release/version bump; it does not contain the Desktop/native code change that would explain the crash by itself.

The reported process architecture is also relevant: the Desktop Web Host runs as a child process using the Electron executable with ELECTRON_RUN_AS_NODE=1. The rc.2 Desktop package uses Electron 44.0.0 and pins Koffi to 3.1.1.

Koffi is a legitimate native area to investigate because it is used by multiple Windows Host-side native components. The repository had explicitly pinned Koffi to 3.1.1 because the newer 3.3.2 resolution failed the packed release/install validation. That makes Koffi worth testing, but it is not evidence that Koffi is the cause of these crashes.

The repository also deliberately moved the Windows native directory picker into a spawned child process so that a native fault in that picker does not terminate the Host. That makes the picker a less direct match for a crash where the faulting process is the Host itself.

2. What does the Crashpad evidence mean, and is there a recommended way to repair it?

I could not find an application-level Crashpad registration/configuration path in this repository:

• no crashReporter.start(...)
• no application-owned Crashpad handler setup
• no MiniDumpWriteDump
• no application-owned Crashpad registration code

The repository's own crash-report system is a JavaScript-level diagnostic mechanism. It writes crash-<time>-<source>.log files with the inspected error, Host diagnostic, runtime facts, and renderer console tail.

That mechanism cannot be relied on for a native process termination. In particular, Windows 0xC0000409 is a fail-fast exception that bypasses normal exception handlers, while 0xC0000005 is an access violation. Therefore a missing JavaScript crash report does not establish that the failure did not occur; it is consistent with the process dying below the JS diagnostic layer.

The crashpad_client_win.cc:867 not connected message is emitted by Electron/Crashpad rather than by the repository's own crash-report code. I would not treat that line alone as proof that Crashpad registration is the original fault, nor would I recommend manually changing Crashpad state in the installation based only on that message.

The useful question for maintainers is whether the Electron 44 Crashpad handler for this packaged build was successfully started and registered, and whether the handler process/IPC endpoint was still alive when the Host failed.

3. Matching PDB / symbol guidance

I could not find repository documentation for a public PDB bundle for this exact Desktop build.

The report already contains the two identifiers needed to make a symbol request precise:

Release commit:
c1b47e41fcd54d20a0f061df28683bfc29ee24e5

Reported executable SHA-256:
DF4E91FD91F6BEE19A1990B0E167BFE06ABF8353279D82BBB8E60EDB6BA0D

Please provide the matching private symbols for the exact executable/build and, ideally, the native modules involved in the crashing stack. The important point is that the PDB must actually match the dumped image; the same source revision alone is not sufficient.

For Windows symbol matching, the debugger uses the PDB signature/GUID and age. symchk can be used to verify that a PDB actually matches the executable, and DUMPBIN /PDBPATH:VERBOSE can show the recorded PDB path.

One repository-specific detail: the Desktop runtime packaging policy intentionally removes some debug-symbol artifacts such as node-pty PDB files from the shipped runtime, so the symbols needed for postmortem analysis may exist only on the build side.

4. Is there a private upload channel for the full dump?

I could not find a documented private dump-upload mechanism in this repository.

I agree that the 693 MiB dump should not be posted publicly because it can contain prompts, session data, paths, environment information, or other process memory.

A maintainer-provided private submission path would be useful. The full dump plus the executable SHA-256 and exact rc.2 build identity should be sufficient for deterministic symbol correlation.

5. What should be collected next?

The most useful next artifact is another full user-mode dump from the actual crashing Host process, together with the Windows Error Reporting event for the same PID/time.

For the next crash, please preserve:

• exact Desktop version;
• Electron/Node versions;
• Host executable SHA-256;
• exception code;
• all exception parameters;
• faulting module and fault offset from WER;
• the existing crash-...-host.log, when one exists;
• Windows Event Viewer / WER Application Error data;
• whether the crash happened during generation, file/tool activity, startup, or idle;
• whether third-party bundles were enabled or disabled.

For Windows-side capture, WER supports per-application LocalDumps and can be configured for a full dump (DumpType=2). That is preferable to relying only on the application's JavaScript crash reporter for a native failure.

For analysis in WinDbg, the first useful commands are:

.exr -1
.ecxr
!analyze -v
k
lmvm <faulting-module>

The 0xC0000409 parameter should be preserved exactly rather than interpreted as proof of one specific corruption class: Microsoft documents it as a fail-fast code whose first parameter is an application-defined subcode. 0xC0000005 provides the access type and faulting address in its exception parameters.

At this point I would classify the report as:

• confirmed repeated native Host termination on Windows;
• Crashpad diagnostics are also failing or disconnected;
• no repository evidence currently proves a specific root cause such as Koffi, Electron, or a third-party bundle;
• the full native dump plus matching symbols is the decisive next step.

[Y-Niuniu]

补充说明：DeepSeek Harness Desktop 0.2.0-rc.2 Host 崩溃 Dump 符号化分析

1. 一句话结论
   用 Electron 官方私有符号把崩溃 Dump 解析到函数级后确认：崩溃原因是 V8 结构化克隆反序列化器（ValueDeserializer::ReadJSObject）在处理约 81 KB 的纯 JS 嵌套数据时，发生了原生栈缓冲区越界（/GS 栈 Cookie 损坏，0xC0000409）。 根本缺陷在 Electron 44 自带的 V8 运行时（纯 JS 数据不应导致原生栈越界）。触发入口是插件的轮询接口 GET /api/dsh-usage/overview。

2. 诊断环境与符号化信息
   软件版本：DeepSeek Harness Desktop 0.2.0-rc.2（nightly）
   底层运行时：Electron 44.0.0 / Node.js 24.18.1 / Windows 11 x64（Build 26200）
   调试工具：WinDbg（cdb 10.0.29617）
   调试符号：Electron 官方带类型信息的私有符号 electron.exe.pdb（GUID 58BAC5502BE826284C4C44205044422E，age 1）
   分析样本：2026-09-30 抓取的完整内存 Dump（约 693 MiB），异常码 0xC0000409，ExceptionInformation[0] = 0x2

3. 崩溃签名与关键调用链
   主线程（TID 0x5d50）在递归反序列化嵌套对象时，函数返回阶段 MSVC /GS 栈检查失败（__report_gsfailure → int 29h fail-fast）：

electron::NodeMain
→ node::SpinEventLoop
→ uv_run → uv__process_tcp_read_req
→ node::LibuvStreamWrap::OnUvRead
→ node::http_parser::Parser::Execute (llhttp)
→ Parser::on_headers_complete
→ v8::Function::Call (JS HTTP 请求处理，经 3 层 Builtins_CallProxy)
→ node::worker::StructuredClone (全局 structuredClone)
→ node::worker::Message::Deserialize
→ v8::ValueDeserializer::ReadValue
→ ReadObject → ReadDenseJSArray → ReadJSObject
→ ReadJSObjectProperties → ReadObject → ReadDenseJSArray → ...
→ v8::internal::ValueDeserializer::ReadJSObject <-- [0xC0000409: /GS 栈 Cookie 校验失败]
崩溃时，进程内其他 15 个线程（ThreadPool / V8Worker / libuv-worker 等）都在空闲等待，没有并发 GC。 因此跨线程野写或随机硬件故障的可能性很低（单个 Dump 不能完全排除）。

4. 触发条件与关联时间线
   触发请求：从 HTTP Parser 的局部变量中提取，请求为 GET /api/dsh-usage/overview HTTP/1.1（Host: 127.0.0.1:19387）。
   数据特征：被反序列化的载荷约 81,066 字节，是“数组 → 对象 → 数组 → 对象”的嵌套结构，纯 JS 数据，不含 ArrayBuffer、可转移对象（Transferable）、Host Object 或 WASM 模块。
   关联插件：该接口由第三方插件 @linxin666/dsh-usage@0.4.4 提供（属于 @linxin666/dsh-web-all 合集，内部 ID web-ui-usage）。 前端在设置页或页脚卡片可见时，默认每 60 秒轮询一次。这可以解释为什么机器刚开机 69 秒、或桌面端空闲挂机时也会崩溃。
   时间线：0.2.0-rc.2 于 9-29 20:22 安装；该插件合集于 20:38 安装；21:15 首次崩溃（renderer），22:35 首次 host 崩溃，此后频繁崩溃。 也就是说，“rc.2 上线当晚开始崩溃”这一点，对该插件合集同样成立。
5. 推测项与未确定部分
   推测：插件代码本身没有直接调用 structuredClone()。克隆发生在 DSH 核心处理该请求的链路中，例如读取或解析配置时的深拷贝；DSH 核心里有多处 structuredClone，具体是哪一处，从 Dump 中无法确定。
   未确定：崩溃不是每次轮询都发生（平均每 1–3 小时一次），说明触发还依赖数据形状或时序（例如反序列化过程中恰好发生 GC）。这一点需要在开发环境中复现确认。
   以上结论来自一个 Dump。其余几次崩溃没有 Dump，目前只能说与此一致，不能证明同源。
6. 复现与修复建议
   根因归属：根本缺陷属于 Electron 44 / V8 的内存安全问题（纯 JS 序列化数据不应引起原生栈缓冲区越界）。插件的请求只是触发了这条路径。
   规避方向：在 DSH 核心中，对来自插件请求的较大嵌套对象，可以考虑不用 structuredClone 做深拷贝，或者限制拷贝的数据量。
   当前状态：我们从 10-02 起只单独停用 web-ui-usage（其余插件照常启用）来观察稳定性，结果之后补充。
   材料提供：本地保留了完整的 693 MiB Dump（可与上述符号匹配）。如果开发团队需要，可以通过私密渠道单独提供（其中包含本地内存状态，不便公开上传）。
   English Summary (for Upstream / Electron / V8)
   A crash dump (0xC0000409, STATUS_STACK_BUFFER_OVERRUN) from DeepSeek Harness Desktop 0.2.0-rc.2 (Electron 44.0.0 / Node 24.18.1 / Win11 x64) was symbolized with official Electron private symbols. The /GS stack cookie check fails in v8::internal::ValueDeserializer::ReadJSObject on the main thread, while global structuredClone() deserializes a ~81 KB nested plain-JS payload during handling of GET /api/dsh-usage/overview (third-party plugin @linxin666/dsh-usage). All other 15 threads were idle, with no concurrent GC. Pure JS data should never cause a native stack overrun, so this looks like a V8 defect. A 693 MiB full memory dump is available via a private channel on request.