官网安装的客户端，首次启动就报错，求各位帮忙看看，感谢！

[ZVIP7679]

情况描述：
DeepSeekHarness，官网下载的deepseek-harness-0.2.2-rc.3-win-x64.exe，首次安装后，第一次启动就提示报错，无法运行。
电脑环境：win11家庭版，半个月前重装过win11系统，这是目前为止自己安装的第一个软件。

弹窗内容：
应用无法启动或已意外停止。
fetch failed
诊断报告：
C：\uers......log
如果应用文件缺失或损坏，请关闭应用并重新安装。任务数据存储在独立位置。

以下是log里面

crash-2026-11-15T05-26-56-820Z-main.log
给的报告：
time: 2026-11-15T05:26:56.820Z
source: main
phase: running
app: @deepseek-ai/dsh-desktop 0.2.2-rc.3
platform: win32 x64
electron: 44.7.0
node: 24.21.0
locale: zh-CN
shell pid: 9180

--- error ---
[TypeError: fetch failed] {
[cause]: Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20) {
errno: -4077,
code: 'ECONNRESET',
syscall: 'read'
}
}

--- renderer console (error level, oldest first) ---
(no error-level renderer console output was captured)

--- auxiliary diagnostics ---
Operation history is best effort. Without its completion marker below, it is unavailable or incomplete.
Recent operations are context only. Missing records do not establish that no changes occurred.

--- recent plugin operations (context, not proof of cause) ---
{"journal":null,"bytesRead":0,"filesRead":0,"truncated":false,"invalidRecords":0,"unavailableFiles":0,"cancelled":false,"outputRecordsOmitted":0,"records":[]}
--- operation history collection complete; consult omission counters above ---

[ZVIP7679]

期间有几次是进入过的，还安装过插件。
后续启动又报这个一样的错误。也测过用手机热点，进去过软件界面一次。

[ZVIP7679]

全网搜索过，似乎没人出现过我这个错误。实在没办法了

[ZVIP7679]

求帮助 实在没办法了

[ZVIP7679]

这个是最后一个的log文件。
crash-2026-11-15T06-56-09-655Z-main.log

[ZVIP7679]

看了下全部的异常启动的日志，都是这个核心错误：

--- error ---
[TypeError: fetch failed] {
[cause]: Error: read ECONNRESET
at TCP.onStreamRead (node:internal/stream_base_commons:216:20) {
errno: -4077,
code: 'ECONNRESET',
syscall: 'read'
}
}

问了DS网页端，说是官方的bug

[ZVIP7679]

尝试了各种方法，还是没法解决。
找不到根源点，根据ds和dsh的回复，疑似软件问题导致。

[ZVIP7679]

目前的解决办法就是多次启动，大概5次左右能够进去一次。

[ZVIP7679]

DeepSeek Harness 桌面版启动崩溃分析与反馈材料

适用版本：@deepseek-ai/dsh-desktop 0.2.2-rc.3（Electron 44.7.0 / Node 24.21.0 / win32 x64 / zh-CN）
机器：Windows 11 家庭版，2026-10 底重装系统，DSH 为重装后第一个安装的软件

一、现象

• 全新安装后首次启动即出现"应用无法启动或已意外停止 / fetch failed"，随后经常复现；中间偶尔能成功启动，进入工作区后运行稳定。
• 2026-11-15 13:26–14:56（本地时间）共保存 11 份崩溃日志，内容逐字相同，仅时间、pid 不同。
• 与第三方插件无关：首次启动时是默认 profile（只有内置 bundle），本机也尚未安装任何插件。

二、日志内容（每份一致）

source: main
phase: running
app: @deepseek-ai/dsh-desktop 0.2.2-rc.3
platform: win32 x64
electron: 44.7.0
node: 24.21.0
locale: zh-CN

--- error ---
[TypeError: fetch failed] {
  [cause]: Error: read ECONNRESET
      at TCP.onStreamRead (node:internal/stream_base_commons:216:20) {
    errno: -4077, code: 'ECONNRESET', syscall: 'read'
  }
}

• 没有 --- host diagnostic --- 段 → Host（子进程）没有上报致命错误；
• 没有渲染进程 error 级输出 → 窗口/页面尚未跑起来；
• recent plugin operations 为空。

三、代码走读结论（app.asar/lib/main.js）

1. 主进程里的 Node fetch() 只有四处：
   • clipboardImageRead（粘贴远程图片时才用）；
   • authenticateWebHost()：GET Host 的 authenticatedUrl，期望 303 + Set-Cookie；
   • forwardWebRequest()：把 dsh-app://app 的 /api/* 转发给 Host；
   • welcome-backend 的 RPC invoke。
     除剪贴板外，全部指向本机 127.0.0.1 上的 Host。
2. phase 取值是 backendReady ? "running" : "startup"；Host 进程一发出 ready 就置为 running，此时窗口还没显示。所以日志里的 running 并不表示"已经正常运行"，实际仍在启动阶段。
3. reconcileBackend() 的 catch 会调用 reportFatal(error, "main")；它覆盖了 backend.start() 里的 authenticateWebHost() 和随后的 openInitialWindow() → readWelcomeState() 这两次本地请求。
4. Host 端（dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js）的逻辑是：await application（整个 profile 启动完成）之后才 process.send({ type: "ready", url: ctx.connection.authenticatedUrl(...) })；外壳收到 ready 后立刻 GET 该 URL。

推论：启动流程中，外壳对本机 Host 的本地 HTTP 请求被对端重置（RST），外壳把这一次性的本地连接错误当成致命错误，直接进入恢复界面。由于崩溃报告不含调用栈，无法区分被重置的是首次鉴权（authenticateWebHost）还是随后读取欢迎状态（readWelcomeState），但两者属于同一类：启动期、本机回环、单次请求。窗口因此永远不会出现；重试有时能过，正说明这是启动期的时序竞态。

四、本机实测（2026-11-15 18:05–18:07）

用 probe-host-startup.mjs 按桌面外壳同样的方式拉起 @deepseek-ai/dsh-desktop-host，计时到它发出 ready 消息（脚本在工作区，可重复运行）：

• Host 进程启动 → ready：4.2 s / 4.9 s / 3.9 s（连续三次）；
• 同机参照：Electron-as-Node 冷启动 98 ms；app.asar（199 MB）顺序读 69 ms（≈2.9 GB/s）；D:\DSH 下 7,883 个文件枚举 505 ms；
• 从 auto-maximize.log 看，插件挂载到窗口出现约 8.5–11.8 s，也就是 Host 就绪之后，外壳与渲染首屏还要约 4–7 s。

结论：Host 自身启动 ≈4 秒，对"8 个 bundle 的 Node 宿主"属于正常偏慢；整机到窗口 8–10 秒慢于普通桌面应用（通常 2–5 秒），但慢在软件启动链路，不在硬件（32 GB 内存、NVMe 顺序读约 2.9 GB/s、Electron 冷启动 98 ms）。

五、对产品的建议

1. 本地握手失败可重试：authenticateWebHost / welcome 读状态这类本机请求遇到 ECONNRESET 时应退避重试若干次，而不是直接 reportFatal 进入恢复界面。
2. 崩溃报告带上 JS 调用栈：目前 boundedErrorSection 用 inspect(error) 渲染，只有 message 和 cause 链，没有 error.stack，无法定位具体调用点。
3. 若 Host 在启动后存在监听器重启/端口变更，应避免在 ready 之后关闭已建立的连接，或重新宣告 URL。

六、用户可用的临时办法

• 崩溃后点「重启」重试（通常一两次能过）；进入工作区后是稳定的。
• 用 Web 版过渡：dsh web / 终端里的 dsh，功能一致，只是没有桌面外壳这层启动握手。
• 升级到修复后的版本（0.2.2-rc.3 为预发布版）。
• 缩短启动时间可提高成功率：给 D:\DSH、%APPDATA%\@deepseek-ai\dsh-desktop、%USERPROFILE%\.dsh 加 Windows Defender 排除项。
• 不要重装：安装文件完好，重装不会改变该行为；会话数据也在独立位置。

[ZVIP7679]

以下是DSH验证后给出的最终结论：
是官方软件自身的问题
准确说：是 DSH 桌面版 0.2.2-rc.3 的 Electron 外壳在启动时的缺陷。 启动过程中，外壳对本机 Host 的一次 HTTP 请求被重置（ECONNRESET），外壳把这一次性错误当成了致命错误，直接弹出“应用无法启动或已意外停止”，窗口因此永远出不来。和你的电脑、网络、安装文件、第三方插件都没有关系。

一句话版本
这不是你的电脑或安装出了问题，而是 DSH 桌面版 0.2.2-rc.3 的已知类缺陷：启动握手失败一次就被判死刑，缺少重试。等官方下一个夜间构建，或直接用 Web 版；在那之前，崩溃就重启。

[ZVIP7679]

DSH桌面版启动崩溃分析.md
附件如上，希望官方能帮忙修一下，谢谢。

[tcguangda]

哈哈，现在官方也蒙，个个都是ai分析的结果。我升级没问题，不过就是有的插件要用ai折腾一下就好了。