DSH桌面端dsh-v0.2.2-rc.2更新失败

[HuoGu-Hub]

咋桌面端dsh-v0.2.2-rc.1升dsh-v0.2.2-rc.2的时候更新失败了，说是更新完了会自动启动，但是实际上更新完直接就退出了，重新打开发现并没有更新，也用管理员权限试过了，现在是怎么个事，就我有这种情况吗

[zhovy]

+1 我也是 存在同样的问题 更新之后进程就没了 然后重启还是提示更新

[user-Mrz]

这个原因是DSH Desktop 0.2.2-rc.1在运行过程中安装新版本目录会自动回滚到旧版本。可以结束进程手动安装。

[Zzx9898]

可以参考下#13025

[zhovy]

#13012
原来不是新bug了 参考这个灰度发布的bug

[jietian10]

+1

[mr-tan4]

一、问题概述
平台：Windows x64，DeepSeek Harness Desktop（nightly 通道，当前安装 0.2.2-rc.1，升级目标 0.2.2-rc.2）
现象：应用内检查更新 → 下载成功 → 点击「安装并重启」后，应用退出，安装器运行约 28 秒后静默退出，没有任何错误提示；旧版本保留，应用不会自动重启，手动打开应用仍是旧版本。
影响：在「默认快捷方式启动 + 应用内升级」这一正常路径下，升级 100% 失败；只能手动运行下载好的安装包完成升级。
复现概率：可稳定复现（详见第三节）；手动运行安装包则 100% 成功。
二、 环境
操作系统 | Windows 10.0.26200 (x64)
三、复现步骤

1. 按默认方式安装 DSH Desktop，并通过开始菜单 / 桌面快捷方式启动应用（快捷方式“起始位置/WorkingDirectory”= 安装目录）。
2. 应用内「检查更新」→ 下载 nightly 新版本（如 0.2.2-rc.2）→ 点击「安装并重启」。
3. 应用正常退出；等待约 30 秒：没有安装进度/错误提示，应用也不会自动重启；手动启动后版本仍是旧版。
4. 查看安装器日志目录：%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\，会生成 directory-failure-*.log。
   文件：%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\directory-failure-20261112-163038.log

Operation: MoveFileExW
Windows error: 32 (另一个程序正在使用此文件，进程无法访问。)
Source:      D:\Users\16573\AppData\Local\Programs\DeepSeek Harness
Destination: D:\Users\16573\AppData\Local\Programs\DeepSeek Harness.old-{7F66B9DB-29CC-4A58-AB63-34A9C61D00E6}
Restoration error: 0
Time: 2026-11-12 16:30:38
Windows: 10.0.26200
Attempts:
backup: Windows error: 32    ×10

安装器 16:30:10 启动，对旧安装目录连续尝试改名 10 次（约 28 秒）全部失败，16:30:38 放弃并回滚。
四、根因分析

1. 安装器升级策略：先把旧安装目录整体改名为 DeepSeek Harness.old-{GUID} 作为备份，然后解压新版本，失败则恢复。
2. 应用内升级时，安装器由运行中的应用进程拉起（electron-updater NsisUpdater.doInstall → child_process.spawn），没有显式设置 cwd，因此继承应用进程的工作目录。
3. 应用从默认快捷方式启动，快捷方式「起始位置」= 安装目录，因此应用的 cwd = 安装目录；安装器继承后，安装器自身的 cwd 也是安装目录。
4. Windows 不允许重命名“仍是某个进程当前工作目录”的目录：MoveFileExW 返回 ERROR_SHARING_VIOLATION (32)。此时重试没有意义，10 次重试必然全部失败。
5. 安装器据此回滚旧版本、静默退出；由于安装失败，--force-run 未执行，所以应用不会自动重启。整个过程 /S 静默，无用户可见提示。
   验证证据（本机实测）

• 从运行中 3 个 DeepSeek Harness.exe 进程的 PEB 读取当前工作目录，均为安装目录 D:\Users\16573\AppData\Local\Programs\DeepSeek Harness\。
• 开始菜单与桌面快捷方式的「起始位置」均为该安装目录。
• 对照实验：让一个进程的 cwd 位于测试目录内，再从外部重命名该目录 → 立即失败 HResult=0x80070020（即 Windows 错误 32）；结束该进程后重命名立即成功。
• 手动运行同一个安装包（从资源管理器/%TEMP% 启动，cwd ≠ 安装目录）→ 升级成功（16:44:35 启动，16:45:03 以 0.2.2-rc.2 重启）。

结论：应用 spawn 安装器时 cwd 继承自应用（=安装目录），而安装器在备份步骤需要重命名该目录，二者叠加导致必然失败；属于安装器/升级链路的缺陷，与网络、磁盘、权限、杀毒软件无关。
五、临时规避（已验证）

1. 在应用内完成新版本下载（或直接使用 pending\ 下已下载的安装包）。

2. 完全退出应用（托盘右键退出，确认任务管理器中没有 DeepSeek Harness.exe 进程）。

3. 从非安装目录的位置启动安装包：资源管理器打开 %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\ 后双击 exe；或先 cd /d %TEMP%，再 start "" "<安装包完整路径>"。

4. 按安装器 UI 完成安装，应用会以新版本重启。本机已用此法从 0.2.2-rc.1 成功升级到 0.2.2-rc.2。
   六、建议修复

5. 安装器侧（主修复）：执行备份重命名之前先 SetCurrentDirectory 到 %TEMP%（或 $PLUGINSDIR），并确认无其他进程以安装目录为 cwd；对这类 ERROR_SHARING_VIOLATION 应先检测并给出明确提示，而不是无意义重试后静默回滚。

6. 应用侧（防御）：spawn 安装器时显式传入 cwd（如 os.tmpdir() / app.getPath('userData')），不要继承应用 cwd。

7. 可观测性：nightly 默认持久化 updater/installer 日志（或默认开启 DSH_DESKTOP_UPDATE_JOURNAL_DIR），并在更新失败时在 UI 展示失败原因；当前安装器侧失败完全不进入应用的失败提示（showUpdateFailure 仅覆盖 spawn 之前/协调器侧错误）。
   directory-failure-20261112-163038.log

[JimmyHanks0216]

这个怎么解决啊？

[CosMoss114]

补充一个更精确的定位，解释为什么 0.2.2-rc.2 这一版开始变成必现（本机 4/4 失败，手动安装 1/1 成功）：

• 环境：Windows 10.0.26200 x64，0.2.2-rc.1 → rc.2，自定盘安装 D:\Program\Deepseek\Deepseek_Harness，从桌面/开始菜单快捷方式启动（起始位置 = 安装目录）。
• 现象、日志与 @mr-tan4 一致：MoveFileExW → Windows error: 32，Source = 安装目录，backup 重试 10 次（约 11–28 秒，Windows/机器不同）后回滚、静默退出，--force-run 不执行。
• 对照：完全退出应用后，从非安装目录 cwd 手动运行同一安装包 → 成功。

但“持锁者是谁”还可以更精确一步：

1. 安装器会在 customInit 里先启动 rc.2 新增的“安装状态窗口”：
   apps/desktop/scripts/installer.nsh → ShowRestartBanner → window-frame.dll::InstallerStartRestartStatus。
   其中 restart-status.h 用
   CreateProcessW(..., nullptr /* lpCurrentDirectory */, ...)
   启动 rundll32.exe，继承了安装器进程的 CWD（= 应用从快捷方式继承的安装目录），
   并且被放进 KILL_ON_JOB_CLOSE 的 Job，安装结束前一直存活。
2. 之后安装器才解压到 $INSTDIR.new-{GUID}，进入 dshPromoteDirectories：
   函数开头会 SetOutPath $PLUGINSDIR（这一步会切走安装器自己的 CWD），
   然后才 MoveFileExW($INSTDIR → $INSTDIR.old-{GUID})。
   但横幅 rundll32.exe 仍以 $INSTDIR 为 CWD，于是 10 次重试全部 ERROR_SHARING_VIOLATION (32)。
3. 本机实测（PEB 读 CWD）：
   • 以 electron-updater 相同参数（--updated /S --force-run）从安装目录 cwd 启动安装器：安装器 CWD = 安装目录；它启动的 rundll32 CWD = 安装目录；窗口可见（文案“正在安装更新…”）。
   • MoveFileExW 语义对照：子进程 CWD 在目标目录 → error 32；子进程仅在目录内打开文件 → error 5。与日志完全吻合。

这也解释了为什么 #13025 的 -WorkingDirectory $env:TEMP 绕过有效：它让安装器和横幅都继承 %TEMP%，没人再占着安装目录。但绕行不是修复；建议：

1. 应用侧（防御，改动最小）：electron-updater spawn 安装器时显式传 cwd（如 os.tmpdir()），不要继承应用 cwd。
   （NsisUpdater.doInstall 里 spawn(installerPath, args, { detached, stdio }) 目前没有 cwd。）
2. 安装器侧（根因）：restart-status.h 的 CreateProcessW 显式传 lpCurrentDirectory = $PLUGINSDIR / %TEMP%；或在 customInit 一开始就 SetOutPath "$PLUGINSDIR"，
   保证之后任何子进程都不继承 $INSTDIR。
3. 可观测性：/S 失败目前完全无提示，只有 installer-logs\directory-failure-*.log；建议失败时写持久标记或在 UI 展示。

历史对照：#11535 也是 MoveFileExW error 32 + 10 次重试，但发生在安装状态窗口上线之前（0.2.1-rc.5），持锁来源是残留子进程；#9995 / #10851 同一步骤但错误码是 5。所以这一条可以单独视为 rc.2 的新回归。
如果需要，我可以提供本机的 4 份 directory-failure-*.log、PEB/CWD 探测脚本和完整调查报告。

[wqj11a]

本机 4/4 失败、手动 1/1 成功，与 @mr-tan4 @CosMoss114 的现象一致。补充三条实证，以及一件需要官方确认的事。

环境：Windows build 22631.6199（注册表 ProductName 报 Windows 10 Pro），DSH Desktop 0.2.2-rc.1 → rc.2，安装目录 F:\DeepSeek Harness，从桌面快捷方式启动。

一、失败点确认在「整目录改名」，不是文件覆盖

Operation: MoveFileExW
Windows error: 32 (另一个程序正在使用此文件，进程无法访问。)
Source:      F:\DeepSeek Harness
Destination: F:\DeepSeek Harness.old-{5494554F-B712-4E88-B577-F784D01CA7A9}
Restoration error: 0
Attempts:
backup: Windows error: 32   ×10

日志位于 %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\directory-failure-*.log，本机四条：17:03:36 / 17:06:48 / 17:08:03 / 17:16:16。第 4 次是在应用与托盘完全退出、安装器以 /S --force-run 静默运行的情况下，仍然 10 次重试全败 —— 说明不是"退出不干净"那么简单。

二、「第三方常驻进程占用」可以排除（至少不是必要条件）

用 Sysinternals handle64.exe（5.0，Authenticode 签名 Microsoft）在应用完全退出、无安装进程时检索安装目录，三种检索串都是零命中：

检索串	结果
F:\DeepSeek Harness	No matching handles found
DeepSeek Harness（设备路径子串）	0
卷 GUID \\?\Volume{02bbe401-...}\	0

同时 Win32_Service.PathName、Get-ScheduledTask.Actions.Execute、三条 Run 注册表项均无 DeepSeek 相关条目。

所以锁并非来自某个常驻第三方（对比 #12489 那例是 SogouCloud.exe），而是安装器启动那一刻仍存在的句柄或工作目录；这类锁在静态扫描里根本看不到。

补充一个基线：应用运行中时，主进程本身持有 415 个相关句柄，其中包含安装根目录的目录句柄本身：

DeepSeek Harness.exe  pid: 27680  type: File  4C: F:\DeepSeek Harness

三、可用的绕过方式（本机实测成功）

不点「立即更新」，直接用已下载并通过校验的包，并把工作目录挪出安装目录：

$inst = "$env:LOCALAPPDATA\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe"
Start-Process -FilePath $inst -ArgumentList "/S" -WorkingDirectory "C:\Windows\Temp"

• 全程 3 分 11 秒：19:04:25 启动 → 19:06:31 FileVersion 翻转 → 19:07:36 安装器退出
• 没有新增 directory-failure 日志
• F:\ 下无 .old-{GUID} 残留 → 这条路径是就地覆盖，根本没有执行那一步目录改名
• 版本核验：exe FileVersion=0.2.2-rc.2、注册表 DisplayVersion=0.2.2-rc.2、app.asar 时间戳与 rc.2 构建时间一致
• 用户数据（~/.dsh）未受影响

四、需要官方确认：rc.2 是否已从 nightly 通道撤下

手动升级完成、应用启动后，它自己的更新器输出：

Checking for update
Staging percentage: 1, percentage: 0.9270444428378354, user id: 6d1d0c63-…
Update for version 0.2.2-rc.2 is not available (latest version: 0.2.2-rc.1, downgrade is disallowed).

回查 https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml（19:11 实测）：

字段	17:01 时	19:11 实测
version	0.2.2-rc.2	0.2.2-rc.1
size	299,659,528	293,425,336
sha512	5rRAkVru…NcJA==	swcK0J6o…ifw==

latest.yml、stable.yml 均 404（只有 nightly 一个通道）。app-update.yml 为 provider: generic / channel: nightly / updaterCacheDirName: @deepseek-aidsh-desktop-updater。

也就是说 rc.2 在 17:01 之后、19:11 之前被从 nightly 通道撤下，于是已经手动升到 rc.2 的机器会停在"源站没有这个版本"的状态：不再收到更新提示（downgrade is disallowed），也不会自动回退。

如果这是有意回滚（与今天集中爆发的更新失败有关，未证实因果），建议公告里说明两件事：

1. 已升到 rc.2 的用户是否需要回退到 rc.1，以及推荐的回退方式；
2. 后续修复版本发布时，更新器的目录改名逻辑是否会改成不依赖"整目录改名"（例如先装到新目录再切换），否则同样的问题会在下次更新重演。