[Bug][Desktop/Windows] 应用内更新：安装器已启动但重命名安装目录失败（MoveFileExW error 32），失败后静默退出、不提示、不重启

[qi984624209-dotcom]

环境
DSH Desktop 0.2.2-rc.1 → 0.2.2-rc.2（nightly feed，win-x64）
Electron 44.7.0（安装目录 version 文件）
Windows 11 Home China，10.0.26300 x64
安装方式：electron-builder NSIS per-user，路径 %LOCALAPPDATA%\Programs\DeepSeek Harness
无 UAC 提权，isAdminRightsRequired: false
复现步骤
应用内出现 0.2.2-rc.2 更新提示，点「安装」；
应用退出，安装器启动（静默，无界面）；
约 30–60 秒内无任何提示，应用也没有重新打开；
手动启动应用，版本仍是 0.2.2-rc.1，更新提示再次出现；
重复 3 次（20:10:10 / 20:11:12 / 20:12:55），全部失败。
预期 / 实际
预期：安装完成并自动重启到新版本；至少失败时要有明确提示。
实际：安装器在「替换旧安装目录」阶段失败，静默退出；UI 无反馈；应用不重启。
证据
%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\ 下三次各生成一份 directory-failure-*.log，内容一致：

Operation: MoveFileExW
Windows error: 32 (The process cannot access the file because it is being used by another process.)
Source: C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness
Destination: C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness.old-{B00E0A71-4971-4A8B-BE4E-2E691B36B480}
Restoration error: 0
Time: 2026-11-11 20:10:10
Windows: 10.0.26300
Attempts:
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32
backup: Windows error: 32

Restoration error: 0 且磁盘上没有产生任何 .old-* 目录 → 替换没有发生，属于干净失败，不是半更新。
安装包本身可证清白：deepseek-harness-0.2.2-rc.2-win-x64.exe，299,659,528 字节，与 update-info.json 的 sha512 一致，Authenticode Valid（CN=Hangzhou DeepSeek Artificial Intelligence Co., Ltd.）。
附件中的日志已做两处中性化：系统账户目录名替换为 <user>；系统错误消息原文为中文（另一个程序正在使用此文件，进程无法访问。），附件里改用英文等价句，其余逐字未改。
时间线（2026-11-11）
时间 事件
20:08:12–20:08:25 下载完成（pending\...exe + update-info.json）
20:10:10 第 1 次安装失败（error 32）
20:11:12 第 2 次安装失败
20:12:55 第 3 次安装失败
20:49:57 先 taskkill /F /T /IM "DeepSeek Harness.exe" 结束全部进程，再运行同一个安装包
20:50:41 安装成功，自动启动，版本变为 0.2.2-rc.2
同一安装包、同一台机器，唯一变量是「安装目录里是否还有残留进程」——根因可确认。
根因分析
NSIS 更新流程第一步是把旧安装目录 MoveFileExW 改名为 .old-{GUID}；目录内只要有任一文件句柄未释放，Windows 即返回 32（ERROR_SHARING_VIOLATION）。
DSH 桌面端用同一个 DeepSeek Harness.exe 以 ELECTRON_RUN_AS_NODE=1 运行 dsh 运行时（见 resources\runtime\bin\node.cmd、runtime\bin\node）。这类子进程不随主进程退出而结束，句柄仍留在安装目录内。
quitAndInstall() 只等主进程退出，不等待整棵进程树；安装器随后改名，必然撞上 32。
安装器的 10 次重试是快速重试（数秒内完成），等不到句柄释放，最终静默退出；应用没有把安装器退出码或 installer-logs 回传 UI，也没有重新拉起应用。
附带问题
安装成功后 updater 缓存没有清理：@deepseek-aidsh-desktop-updater 下遗留 572 MB（installer.exe 与 pending\ 各约 300 MB）。
连续失败 3 次后再点应用内「安装」，安装器不再启动，直接弹错误（此时没有新的 installer-logs），疑似 pending 状态与缓存不一致；用户只能自己结束进程。
建议修复
quitAndInstall 前结束并等待整棵进程树（含 ELECTRON_RUN_AS_NODE 子进程）退出，并设置超时；
超时或安装器非 0 退出时：明确提示 + 自动重启旧版本，不要静默；
安装成功后清理 updater 缓存与 pending 状态；
目录仍被占用时，可改为「解压到临时目录 + 下次启动替换」，或交给独立 helper 在应用退出后执行替换。
变通做法（已验证有效）
托盘退出，并在任务管理器结束所有 DeepSeek Harness.exe（会有多个，node 子进程同名）；
直接双击 %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe；
安装完成后版本变为 0.2.2-rc.2。
相关讨论
#9963 Windows desktop: GUI update always fails — Host never exits（安装器从未启动）
#3959 Windows 桌面更新需等待后端退出再替换 node.exe
#11032 0.2.1-rc.3 仍会在 Host 完成收尾确认后拒绝应用内更新
本报告是第三种情形：安装器已启动，但死在目录替换阶段，与上述三条互补。
English summary
On Windows the in-app update does launch the NSIS installer, but it fails at the "rename old install directory" step with MoveFileEx error 32 (sharing violation) ten times and then exits silently: no UI error, no relaunch, version unchanged. The same installer succeeds immediately if every DeepSeek Harness.exe process (including ELECTRON_RUN_AS_NODE children) is killed first. Additionally, the updater cache retains ~572 MB after a successful install, and after three failed attempts the in-app install button fails without launching the installer at all.
directory-failure-20261111-201010.log
directory-failure-20261111-201112.log
directory-failure-20261111-201255.log
update-fix.log

[AliceRabbit]

相同的问题

[znlgis]

补充一份独立复现 + 代码侧定位（与 #12974 同一缺陷，2026-11-11 22:04–22:11，另一台机器）。

环境

• DSH Desktop 0.2.2-rc.1 → 0.2.2-rc.2，nightly feed win-x64，Electron 44.7.0，Windows 10.0.26300
• 安装目录 %LOCALAPPDATA%\Programs\DeepSeek Harness（per-user，无 UAC）
• 安装包：299,659,528 B，sha512 与 update-info.json 一致，Authenticode Valid

复现

三次应用内更新（22:04:20 / 22:07:52 / 22:11:36）各生成一份 directory-failure-*.log，内容一致：

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

22:11:56 应用被重新拉起，版本仍是 rc.1。

关键测量：不是“重试太快”，而是重试窗口被耗尽

• installer-directories.nsh 的重试是 10 次，第 n 次失败后 Sleep n*250 ms → 配置等待 250×(1+…+9) = 11.25 s
• 我用同样的循环对一个“有子进程持有 cwd 的目录”做对照实验：10 次全部失败，13.8 s 走完仍不能改名；持有者一退出，同一操作立即成功
• 结论：目录在整个窗口内持续被占用。把窗口从 10 s 提到 60 s 只会推迟失败，不改变结果

代码侧事实

• apps/desktop/scripts/installer-directories.nsh 在 dsh-v0.2.2-rc.1 与 master HEAD（e8f7b93a）之间零差异；rc.1→master 的安装器改动只有 restart banner 与 DWM 圆角 → 升到 rc.2 不会改变这条路径
• apps/desktop/installer/window-frame.cpp:98 的 InstallerFindProcess 只匹配 $INSTDIR\DeepSeek Harness.exe 的完整路径。它证明的是“该 exe 不在运行”，并不能证明“目录可以改名”
• apps/desktop/installer/directory-report.h 的失败报告只记录 operation / error / source / destination / attempts，不记录谁持有目录，所以现场无法定位
• apps/desktop/src/update-coordinator.ts:218 在 beforeRestart() 之后调用 quitAndInstall(true, true)；beforeRestart（main.ts:705 起）只 backend.stop() 等 Host 子进程退出，没有对安装目录做“可改名”确认

建议（按优先级）

1. 应用侧：backend.stop() 之后、quitAndInstall 之前，轮询“安装目录能否改名”（改名到临时名再改回，或 Restart Manager 枚举），超时则中止安装并在 UI 明确报错，而不是把失败留给静默安装器
2. 安装器侧：error 5/32/33 用尽后，用 Restart Manager（RmRegisterResources / RmGetList）把占用进程写进 directory-failure-*.log。纯诊断改动，风险低
3. 安装器侧：以“目录可改名”而非“固定 10 次”作为放行条件
4. 应用侧：把安装器退出码与报告路径回传 UI（[Bug][Desktop/Windows] 应用内更新：安装器已启动但重命名安装目录失败（MoveFileExW error 32），失败后静默退出、不提示、不重启 #12974 已提到失败后无提示、不重启）

变通（已验证）

退出 DSH（托盘退出），最后在任务管理器结束所有 DeepSeek Harness.exe，然后直接运行
%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe
→ 安装成功，版本变为 rc.2。

English summary

Independent reproduction of the same Windows in-app update failure: MoveFileExW error 32 at the directory rename, 10/10 retries failed, rollback reported success, installer exits silently.

Measured: the configured retry window is 11.25 s of sleeps (13.8 s wall clock in a controlled analogue) and is fully exhausted, so this is a sustained directory lock, not a transient one — a longer window only delays the failure.

installer-directories.nsh is unchanged between dsh-v0.2.2-rc.1 and master, so rc.2 cannot fix this path. InstallerFindProcess matches only $INSTDIR\DeepSeek Harness.exe (proves the app exe is gone, not that the directory is free), and the failure report never names the holder. Suggested direction: gate the in-app install on a “directory is renamable” probe, and record Restart Manager holders in the failure report.