Windows 自动更新必定失败：更新器拉起安装器未设 cwd，导致备份目录 MoveFileExW 报 error 32

[loxoxl]

Windows 桌面端自动更新必定失败：更新器拉起安装器时未设置 cwd，安装器继承"安装目录"导致备份改名 MoveFileExW 返回 ERROR_SHARING_VIOLATION(32)

环境

项	值
OS	Windows 11 专业版 10.0.26200 build 26200 (AMD64)
DSH Desktop	0.2.2-rc.1 → 目标 0.2.2-rc.2
渠道	nightly
更新源	https://download.deepseek.com/dsh-desk/feeds/win-x64/
Electron	44.7.0
安装目录	<install-dir>（示例中写作 E:\DeepseekHarness，非系统盘、普通 NTFS 目录、剩余空间充足）
启动方式	桌面/开始菜单快捷方式，快捷方式「起始位置」= 安装目录

现象

1. 应用内检查更新能找到 0.2.2-rc.2，安装包完整下载并校验通过（%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe + update-info.json）。
2. 点击安装后应用退出，安装器启动，随后安装失败，应用被 --force-run 重新拉起。
3. 用户侧没有任何错误提示，只是版本号没变（仍在 rc.1），只有在安装器日志里能看到原因。
4. 行为确定性复现：连续 4 次更新尝试全部以同一错误失败。

证据

%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\directory-failure-20261112-171407.log（4 份日志内容一致，仅 Time/GUID 不同）：

Operation: MoveFileExW
Windows error: 32 (另一个程序正在使用此文件，进程无法访问。)
Source: E:\DeepseekHarness
Destination: E:\DeepseekHarness.old-{C65184FA-1EDF-44C5-BA2C-3F2CA76BC59E}
Restoration error: 0
Time: 2026-11-12 17:14:07
Windows: 10.0.26200
Attempts:
backup: Windows error: 32
backup: Windows error: 32
... (共 10 次，全部 32)

即：安装器要把旧安装目录整体改名为 .old-{GUID} 作为回滚备份，MoveFileExW 返回 32（共享冲突/占用），重试 10 次后放弃；Restoration error: 0 说明目录本身没被破坏，应用仍能回退到旧版本运行。

补充实测：

• 安装目录不是 reparse point（不是软链/junction），也没有被 Explorer、杀软、同步盘占用。
• 错误是 32（占用）而不是 5（拒绝访问），update-info.json 里 isAdminRightsRequired: false，排除权限/管理员问题。
• 用 Python ctypes 读运行中进程的 PEB 得到 ProcessParameters.CurrentDirectory：快捷方式「起始位置」= 安装目录时，主进程 cwd 就是 E:\DeepseekHarness\。

根因

更新链路（Electron + electron-updater + NSIS）：

1. 主进程由快捷方式启动 → 主进程 cwd = 快捷方式「起始位置」= 安装目录。
2. NsisUpdater.doInstall 组装 ["--updated", "/S", "--force-run", "/D=<installDirectory>", "--package-file=<pending exe>"]，随后走 BaseUpdater.spawnLog(cmd, args)：
   child_process.spawn(cmd, args, { stdio: "ignore", env: undefined, detached: true }) —— 未指定 cwd，子进程继承父进程的当前目录。
3. 应用主进程在整个生命周期内没有任何 process.chdir，所以安装器进程的 cwd 同样是安装目录。
4. 安装器第一步要 MoveFileExW(installDir → installDir.old-{GUID})；Windows 不允许重命名任何进程的当前工作目录（哪怕该目录里没有打开的文件句柄），于是必然返回 32，且重试无意义（cwd 不会自己变）。

关键点：应用此时已经退出，所以"应用占用安装目录"并不是原因——是安装器自己继承了以安装目录为 cwd 的当前目录，属于自锁。这也解释了为什么"关掉所有 DSH 进程""换时间重试""管理员运行"都无效。

验证

把两个快捷方式（桌面 + 开始菜单）的「起始位置」从安装目录改为中性目录（如 C:\Users\<user>），其余字段（目标、参数、图标）不动，重新从快捷方式启动应用后点更新：

• 更新一次成功，注册表 DisplayVersion 变为 0.2.2-rc.2；
• 运行中主进程 cwd 全部变为 C:\Users\<user>；
• installer-logs 不再产生新的 directory-failure-*.log。

反证：在此之前，每次更新都以同一 error 32 失败。

建议修法

1. 更新器侧（推荐，改动最小）：spawnLog 显式给安装器一个中性的 cwd，例如

   spawn(cmd, args, { stdio: "ignore", detached: true, cwd: os.tmpdir() })

   或 app.getPath("temp")。这同时修掉"安装器 cwd 落在安装目录"的一切副作用。
2. 安装器侧（防御性）：NSIS 脚本在备份前主动离开安装目录，例如
   System::Call 'kernel32::SetCurrentDirectory(t "$EXEDIR")'（或 $TEMP），这样即使宿主没设 cwd 也不会自锁。
3. 启动侧：应用启动时把 cwd 切到中性目录（process.chdir(app.getPath("userData"))），避免快捷方式「起始位置」影响后续子进程。
4. 可观测性：MoveFileExW 备份失败时，把 installer-logs 里的原因回传给主进程并在 UI 上提示（当前静默失败，用户只能看到"版本没变"），同时建议排查 cwd/句柄。

临时绕过（用户可用）

任选其一：

• 把快捷方式「起始位置」改成中性目录后，从快捷方式启动再更新（本 issue 已验证有效）。
• 完全退出 DSH（含托盘），然后从中性目录手动运行已下载的安装包：

  Start-Process "$env:LOCALAPPDATA\@deepseek-aidsh-desktop-updater\installer.exe" `
    -ArgumentList '--updated','/S','--force-run' -WorkingDirectory 'C:\'

⚠️ 绕过方案要求之后始终从快捷方式启动；直接双击安装目录里的 DeepSeek Harness.exe 会让 cwd 回到安装目录，bug 复发。

备注

• 已存在相似反馈（安装器备份目录报 Win32 32）：Discussion DSH Desktop 自动升级失败：安装器备份安装目录报 Win32 32（进程占用 D:\deepseekDSH） #11535（D:\dee...，0.2.1-rc.5）。本报告补充的是机制层面的根因（更新器 spawn 未设 cwd → 安装器 cwd = 安装目录 → 自锁）以及可复现的绕过方式，可直接用于定位修复。
• 报告中路径/用户名已脱敏。

[github-yousen]

补充一条已实测验证的根因证据，并附上可直接落地的最小修复（rc.1 → rc.2 升级场景实测）。

1. 库侧：安装器被拉起时确实没有 cwd

本地 app.asar 内 node_modules/electron-updater/out/NsisUpdater.js 的 doInstall()：

this.spawnLog(installerPath, args).catch((e) => { ... })

NsisUpdater.js 与 BaseUpdater.js 全文里 cwd 出现 0 次，因此安装器子进程继承父进程（Electron 主进程）的工作目录。

2. 应用侧：主进程的 cwd 就是安装目录

读取运行中各进程 PEB 的 RTL_USER_PROCESS_PARAMETERS.CurrentDirectory（安装目录 D:\app\dsh）：

PID=16028  cwd='D:\app\dsh\'                          <- 主进程
PID=29876  cwd='D:\app\dsh\'
PID=37044  cwd='D:\app\dsh\'
PID=46864  cwd='D:\app\dsh\'
PID=50992  cwd='C:\Users\<user>\.dsh\profiles\desktop\'

Windows 不允许重命名「仍被某进程作为当前目录」的目录。因此安装器一旦从安装目录内启动，MoveFileExW(D:\app\dsh → D:\app\dsh.old-{GUID}) 必然返回 32，而且重试 10 次也不会改变（cwd 恒定）——这解释了 10/10 全部失败。

3. 对照实验：只换 cwd 就成功

同一份 pending 安装包、同一安装目录、同样先结束全部 DSH 进程，唯一差别是启动安装器时的 cwd（d:\code\gmmp\temp-scripts，位于安装目录之外）：

deepseek-harness-0.2.2-rc.2-win-x64.exe /S /D=D:\app\dsh

结果：安装成功，注册表 DisplayVersion 由 0.2.2-rc.1 变为 0.2.2-rc.2，InstallLocation 仍为 D:\app\dsh，退出码 0，无 dsh.old-* 残留。

4. 建议修复（apps/desktop/src/update-coordinator.ts，2 处改动）

在 install() 交接给安装器之前，把 cwd 移出安装目录：

         this.release = { kind: 'handed-off', version }
+        this.leaveInstallDirectory()
         this.updater.quitAndInstall(true, true)

  /**
   * electron-updater spawns the NSIS installer with no `cwd` option, so the installer inherits this
   * process's working directory. Windows refuses to rename a directory that is some process's current
   * directory, so an installer started inside the install directory can never rename it to
   * `<install>.old-<GUID>`: MoveFileExW fails with error 32 and every retry fails the same way.
   */
  private leaveInstallDirectory(): void {
    try {
      const cwd = process.cwd()
      const install = dirname(process.execPath)
      if (cwd === install || cwd.startsWith(install.endsWith(sep) ? install : install + sep)) {
        process.chdir(app.getPath('temp'))
      }
    } catch {
      // Best effort: a failed chdir must not block the installation handoff.
    }
  }

（需要把 import { join } from 'node:path' 改为 import { dirname, join, sep } from 'node:path'。）

5. 兜底建议

• 安装失败时把 installer-logs/directory-failure-*.log 的 Windows error 透出到 UI，而不是静默失败、不提示、不重启；
• 或在 install() 中一并检查 cwd / 目录句柄占用者，给出可读提示（「安装目录被占用，请完全退出后重试」）。

[skoenng]

补充一份同一问题的现场记录（DSH Desktop 0.2.2-rc.1 → 0.2.2-rc.2，Windows 10.0.19045 x64，nightly 通道，安装在 E:\DSH-智能体，Electron 44.7.0）。

与本帖结论一致的部分：2026-11-12 17:24:57（本地时间），安装器在备份重命名阶段失败，10 次重试全部返回 Windows error 32（另一个程序正在使用此文件），Restoration error: 0，即安装目录未被改动，版本仍是 rc.1。日志原文：

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

本贴之外的一个次生现象：安装失败后，17:26:03–17:27:44 连续 8 次启动都在启动阶段崩溃，错误完全一致：

phase: startup
app: @deepseek-ai/dsh-desktop 0.2.2-rc.1
Error: desktop welcome: Web authentication failed
    at connectDesktopWelcome (lib/main.js:16856:31)
    at async Object.start (lib/main.js:20386:22)

connectDesktopWelcome 是启动时对 Host 的 ready.url 做 net.fetch(..., {credentials:'include'})，响应非 2xx 就抛这个错（main.js:16854–16856）。这些崩溃报告的 renderer console 段为空、host diagnostic 段缺失，看不出具体状态码；约 100 秒后（17:28:45）再次启动又恢复正常。怀疑与中断安装留下的 Host 子进程 / 端口 / 会话 cookie 状态有关（Desktop Host 是以 process.execPath 即 DeepSeek Harness.exe 启动的常驻子进程，见 main.js:9979），但仅凭日志无法坐实。

已验证的手动恢复路径（供其他用户参考）：

1. 完全退出 DSH（托盘 → 退出），任务管理器确认没有 DeepSeek Harness 进程；
2. 确认安装目录已解锁（能独占打开安装目录里的 exe 即可）；
3. 直接运行更新器已下载好的安装包（无需重新下载，其 sha512 与 update-info.json 一致）：
   %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe /S --updated /D=<安装目录>
   实测 37 秒完成，退出码 0，旧目录自动清理；
4. 复核 resources/app.asar 内 package.json 版本变为 0.2.2-rc.2，注册表 DisplayVersion 同步为 0.2.2-rc.2，重启后无新的 crash 日志。

建议：

• 安装前显式结束 Host 子进程，并在 rename 前校验安装目录可写；失败时把占用进程（Restart Manager）打出来；
• error 32 的提示改成可读文案（“DSH 或其它程序仍占用安装目录”）；
• welcome 认证对 Host URL 的 fetch 增加有限重试与状态码上报，避免一次残留导致连续启动崩溃；
• crash report 在 startup 阶段补 host diagnostic（本次为空）。

[xymdcyy]

补充一份独立现场，并提醒一个与「安装器继承 cwd 自锁」解释存在冲突的源码细节：本机（Windows 11 10.0.26300、按用户安装到 D:\DSH、0.2.2-rc.1 → rc.2）连续两次确定性失败，日志同为本 error 32（10/10），详见 #13098。

需要确认的点：apps/desktop/scripts/installer-directories.nsh:174-175 在备份改名之前先执行 SetOutPath $PLUGINSDIR，而 NSIS 的 SetOutPath 运行时就是 SetCurrentDirectory(buf)（EW_CREATEDIR with parm1=1，见 NSIS Source/exehead/exec.c）。也就是说安装器自身在改名瞬间的 cwd 已是 $PLUGINSDIR，不是安装目录。若真实持锁者是改名瞬间仍存活的父/子进程（或未释放的目录句柄），只加 leaveInstallDirectory() 未必能修好。建议一并加 Restart Manager（RmGetList）诊断，把占用 $INSTDIR 的进程/文件名打进 directory-failure 日志，一次复现即可定死。

[CosMoss114]

@xymdcyy 提到的矛盾是对的，@github-yousen 的修复方向也成立；但持锁者还可以再精确一步——不是安装器自身，而是 0.2.2-rc.2 新增的“安装状态窗口”（release notes 里的 installation-status window）。它解释了为什么 rc.2 这一版是 100% 必现，也解释了为什么只改 spawn cwd 就能绕过。

链路（tag dsh-v0.2.2-rc.2）：

1. apps/desktop/scripts/installer.nsh → customInit：静默更新（/S --updated --force-run）时先 !insertmacro ShowRestartBanner，此时安装器还没有任何 SetOutPath，CWD 仍是从应用继承的安装目录。
2. apps/desktop/scripts/restart-banner.nsh → ShowRestartBanner → window-frame.dll::InstallerStartRestartStatus。
3. apps/desktop/installer/restart-status.h → restart_status::LaunchWorker：
   CreateProcessW(rundll32.exe, ..., nullptr /* lpCurrentDirectory */, ...)，rundll32 继承安装器 CWD；并被放进 KILL_ON_JOB_CLOSE 的 Job，句柄保存在 $RestartStatusJob，只在成功路径的 customInstall 里关闭——失败路径下横幅会一直活到安装器退出。
4. 之后 dshPromoteDirectories 才 SetOutPath $PLUGINSDIR（释放安装器自身 CWD），再 MoveFileExW($INSTDIR → $INSTDIR.old-{GUID})；但 rundll32 仍以 $INSTDIR 为 CWD → 10 次重试全部 ERROR_SHARING_VIOLATION (32)。

本机实测（PEB 读 32/64 位进程的 ProcessParameters.CurrentDirectory）：

• 以 electron-updater 相同参数（--updated /S --force-run）、从安装目录 cwd 启动 rc.2 安装器：安装器 CWD = 安装目录；它启动的 rundll32 CWD = 安装目录；窗口可见（文案“正在安装更新，更新完成后将自动重启应用。”），生命周期与安装器绑定。
• MoveFileExW 语义对照：子进程 CWD 在目标目录 → error 32；仅打开目录内文件 → error 5；与 directory-failure-*.log 完全吻合。
• 本机 rc.1→rc.2 应用内更新 4/4 失败；完全退出后从非安装目录手动运行同一安装包 1/1 成功。

因此修法建议“双保险”：

• 应用侧（防御，github-yousen 的补丁可行）：electron-updater spawn 时显式 cwd: os.tmpdir()，或在 quitAndInstall 前 process.chdir(app.getPath('temp'))；这样安装器和横幅都继承中性 cwd。
• 安装器侧（根因）：restart-status.h 给 CreateProcessW 传 lpCurrentDirectory = $PLUGINSDIR（或 %TEMP%）；或在 customInit 一开始就 SetOutPath "$PLUGINSDIR"，保证之后任何子进程都不继承 $INSTDIR。
• 诊断：赞同 xymdcyy 的 Restart Manager 建议——rename 失败时 RmGetList 枚举占用 $INSTDIR 的进程写入日志，一次复现应该能看到 rundll32.exe；顺带把 error 32 透出到 UI，不要在 /S 下静默。

临时绕过就是 #13025/#13098 已验证的：完全退出 DSH 后，从中性 cwd 运行
%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer.exe --updated /S --force-run。

历史对照：#11535 也是 error 32 + 10 次重试，但发生在安装状态窗口上线之前（0.2.1-rc.5），持锁来源是残留子进程；#9995/#10851 同一步骤但错误码是 5。因此本条可视为 rc.2 引入的确定性新回归。

[skoenng]

再补一条同机自然实验，用于把「安装器继承 cwd 自锁」与其它持锁者区分开（Windows 10.0.19045，装在 E:\DSH-智能体，0.2.2-rc.1 → rc.2）：

• 失败：应用内更新（/S --updated --force-run，cwd = 安装目录）→ MoveFileExW error 32 ×10，见 directory-failure-20261112-172457.log。
• 成功：完全退出 DSH 后，由 cwd 在工作区外（E:\新项目）的进程启动同一枚安装包：deepseek-harness-0.2.2-rc.2-win-x64.exe /S --updated /D=E:\DSH-智能体（未带 --force-run）→ 退出码 0，37 秒完成，.old-{GUID} 自动清理，app.asar 版本变为 rc.2。

按 @CosMoss114 的链路核对了源码（tag dsh-v0.2.2-rc.2）：

• apps/desktop/scripts/installer.nsh 第 70–74 行：${Silent} + ${isUpdated} + ${isForceRun} 时先 !insertmacro ShowRestartBanner，此时还没有任何 SetOutPath；
• apps/desktop/scripts/restart-banner.nsh：调 $PLUGINSDIR\window-frame.dll::InstallerStartRestartStatus；
• apps/desktop/installer/restart-status.h 第 30 行：CreateProcessW(..., nullptr /* lpCurrentDirectory */, ...)，rundll32 继承安装器 cwd；第 18 行 JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE。

因此 @xymdcyy 的观察与持锁者并不矛盾：改名瞬间安装器自身 cwd 确实已是 $PLUGINSDIR，但锁来自更早创建、仍在运行的 rundll32 子进程（它才是继承了安装目录 cwd 的那个）。两条可行修法：给 spawn/ CreateProcess 显式指定 cwd（或保证子进程 cwd 不在安装目录），或不把这类常驻子进程放进 rename 前的路径。这也是我们这次手动安装能绕过去的原因。