[Desktop · Windows] In-app update always fails: installer cannot rename the install directory (ERROR_SHARING_VIOLATION 32) and the app never relaunches

[onezeroyl]

Summary

On Windows, the in-app "update → install and restart" flow always fails when the installer has to swap the existing install directory: MoveFileExW(C:\ProgramFiles\deepseek → C:\ProgramFiles\deepseek.old-{GUID}) returns ERROR_SHARING_VIOLATION (32) ten times, the installer gives up, and nothing is installed. The desktop shell has already called app.quit() by then, so the user sees "the app closed and never came back", gets no error, and the next launch is still the old version with the update prompt again.

Reproduced 3 times, including once right after a clean reboot. Manually killing every DeepSeek Harness.exe and running the already-downloaded installer from a neutral working directory succeeds immediately, so this is not antivirus / third-party software.

Environment

• DeepSeek Harness desktop, nightly channel, @deepseek-ai/dsh-desktop 0.2.2-rc.1 → 0.2.2-rc.2
• Windows 11 (Windows: 10.0.26200), x64
• Install dir: C:\ProgramFiles\deepseek (note: the path has no space — the installer's own default)
• Update source: https://download.deepseek.com/dsh-desk/feeds/win-x64/ (app-update.yml: provider: generic, channel: nightly, updaterCacheDirName: @deepseek-aidsh-desktop-updater)
• Installer: deepseek-harness-0.2.2-rc.2-win-x64.exe (299,659,528 bytes, signature valid — Hangzhou DeepSeek AI), downloaded and sha512-verified by electron-updater

Evidence — installer failure log

Three files produced under %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\installer-logs\directory-failure-*.log (13:43:50, 13:51:45, 14:43:37 local time; all identical):

Operation: MoveFileExW
Windows error: 32 (another program is using this file)
Source: C:\ProgramFiles\deepseek
Destination: C:\ProgramFiles\deepseek.old-{7C44876F-C1E4-430B-AB6B-768287EF7D38}
Restoration error: 0
Time: 2026-11-12 14:43:37
Windows: 10.0.26200
Attempts:
backup: Windows error: 32
backup: Windows error: 32
...(10 attempts, all 32)

Restoration error: 0 means nothing was changed — the old version stays installed.

Reproduction

1. Installed 0.2.2-rc.1, nightly channel, DSH was running with an active session (backend Host alive).
2. Update downloaded; click "install and restart".
3. Desktop shell confirms, stops the backend, calls quitAndInstall(true, true), then quits itself.
4. Installer starts, cannot rename C:\ProgramFiles\deepseek, retries 10 times, aborts silently, does not relaunch the app.
5. Relaunch manually → still rc.1 → prompt appears again → repeat.

Analysis

• Renaming a directory fails with error 32 whenever any process still holds a handle inside it or has that directory as its current working directory (I verified the CWD case separately: same winerror 32, succeeds as soon as the process exits).
• The desktop shell's backend Host is the same executable from the install directory, run as Node (ELECTRON_RUN_AS_NODE=1 via resources\runtime\bin\node.cmd). So the install directory is by design in use by the very process tree that has to be gone before the swap.
• Observed desktop-side behavior (from the 0.2.2-rc.2 asar): update-coordinator.install() → beforeRestart() (idle, task lock, backend.stop() with 10s/5s/5s timeouts, journal drain) → quitAndInstall(true, true); electron-updater's BaseUpdater spawns the installer detached with stdio: "ignore" and never reads its exit code, then setImmediate(() => app.quit()). --force-run is only passed along on the "success" path. So a failed install is inherently silent and never relaunches the app.
• Only the direct child is killed; grandchildren (node shim children, plugin-spawned helpers) are not enumerated, and there is an app.exit(1) path that bypasses the shutdown sequence entirely — either can leave a long-lived handle on the install directory.
• The installer's retry window is short (10 attempts); it does not appear to wait for the old process to exit or poll until the directory is unlocked.

Suggested fixes (priority order)

1. Installer: before the directory swap, wait for the old processes to exit (e.g. parent PID / known image names) and retry until the directory is unlockable, with a much longer budget (30–60 s) and clear diagnostics.
2. Spawn the installer with a neutral cwd (e.g. os.tmpdir()), not inherited from the app — an inherited install-directory CWD makes the rename fail unconditionally.
3. Read the installer's exit code (or a result file) and, on failure, keep/show an error and relaunch the app; the current UI promises an automatic restart that only happens on success.
4. Before quitAndInstall, terminate the whole descendant process tree (Host + node shims + plugin-spawned helpers) and wait for them, not just the direct child.
5. Consider replacing the "rename the whole directory" strategy with a versioned install directory (install into ...\deepseek\<version>, switch a pointer), which removes this class of race entirely.

Workaround (works for users)

:: admin shell
taskkill /f /im "DeepSeek Harness.exe"
timeout /t 3
taskkill /f /im "DeepSeek Harness.exe"
cd /d C:\
start "" "%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe"

This installed rc.2 successfully on the same machine with no other change.

---

中文摘要：Windows 上桌面端应用内更新在“改名旧安装目录”这一步必失败（MoveFileExW → ERROR_SHARING_VIOLATION 32，重试 10 次后放弃，Restoration error 0），而应用此时已自动退出，导致无提示、不重启、重开仍是旧版。安装目录里的 DeepSeek Harness.exe 同时以 ELECTRON_RUN_AS_NODE 方式跑后端 Host，退出流程只 kill 直接子进程、安装器又是 detached 且不读退出码，因此形成稳定复现。建议安装器在目录交换前等待/结束旧进程并延长重试、以中性工作目录启动安装器、失败时回传并重新拉起应用。

[onezeroyl]

Follow-up after reading the public sources (apps/desktop and apps/desktop/installer are in this repo — thanks, that made this much more precise). Two of my initial statements need correcting, and I think I have a concrete lead.

Correction: the installer already waits and retries

• apps/desktop/scripts/installer.nsh:173-202 (customCheckAppRunning) already polls window-frame.dll::InstallerFindProcess($INSTDIR\${APP_EXECUTABLE_FILENAME}) every 250 ms, up to 40 iterations (10 s) when ${isUpdated}.
• apps/desktop/scripts/installer-directories.nsh:17-61 retries the rename up to 10 times with Sleep(attempt × 250 ms) (≈ 11.25 s total) for errors 5/32/33, and :170-216 releases $OUTDIR via SetOutPath $PLUGINSDIR before both renames (good — that rules out the CWD case I had suspected).

So the total budget is roughly 21 s, and all three of my failures exhausted it. My earlier claim "it does not wait for the old process to exit" was wrong; sorry.

The interesting part

customCheckAppRunning quits with error level 2 and shows $(INSTALLER_RUNNING) when the app executable is still present — and in that path no directory-failure-*.log is produced, because the rename is never attempted. In all three of my failures the rename was attempted and logged. That means at rename time InstallerFindProcess("$INSTDIR\DeepSeek Harness.exe") reported clear, while the directory was still locked for the full 11.25 s retry window.

So whatever held C:\ProgramFiles\deepseek did not expose that image path to the check. Candidates that are not the app executable:

• a process whose CWD is the install directory but whose image lives elsewhere (e.g. a node.exe from ~/.dsh/dsh-runtimes/... started by a plugin),
• $INSTDIR handles held by a helper / shell extension / indexer / AV scanner,
• the app's descendants that were spawned through resources\runtime\bin\node.cmd if InstallerFindProcess matches on something narrower than the full path.

Suggestions

1. Log the actual blocker. window-frame.dll is already a C++ helper next to the installer; adding Restart Manager (RmStartSession / RmRegisterResources($INSTDIR) / RmGetList) at the moment dshDirectoryOperation gives up would name the processes that hold the directory, both in directory-failure-*.log and in the interactive report. Restart Manager is exactly the "who is using this file" API for this, and it would make the next report actionable in one line.
2. Use the same Restart Manager list to wait / close instead of an image-path poll: re-check until RmGetList returns nothing (budget 60 s), then either retry the rename or ask the user to close the named processes.
3. Silent failures are invisible. In customInstallerDirectoryFailed the UI is suppressed when ${Silent} (StrCpy $1 0), the shell has already quit via setImmediate(() => app.quit()) in electron-updater's BaseUpdater, and --force-run only applies on success — so the user sees "app vanished". Consider writing a failure marker the next launch surfaces, and/or relaunching the app after a failed install (the restart-status.h / ShowRestartBanner machinery already exists).
4. Shell side (apps/desktop/src/host-process.ts:347-367, stop()): only the direct child is killed by PID (10 s graceful → SIGTERM → SIGKILL). A job object (PROC_THREAD_ATTRIBUTE_JOB_LIST, which restart-status.h already uses for the launcher) or a tree kill would make "no descendants survive the handoff" a property instead of a best effort.

Reproducer environment

Windows 11 10.0.26200, x64, install dir C:\ProgramFiles\deepseek (installer default, no space, per-user install), nightly channel, 0.2.2-rc.1 → 0.2.2-rc.2, a long-lived backend session with plugins was running. Three identical failures (13:43:50, 13:51:45, 14:43:37 local, the last one after a clean reboot). Killing every DeepSeek Harness.exe and running the same downloaded installer from C:\ installed rc.2 on the first try, so the payload/feed/signature are fine.

Happy to attach the three directory-failure-*.log files or run a build with extra logging if that helps.

[Xly5487]

Independent repro on a per-user install (path contains a space) + a datum that reconciles both CWD observations

Same failure on a different install layout, so this is not specific to C:\ProgramFiles\deepseek or to any machine-local permission/AV state. (Paths below have the Windows user name redacted to <user>.)

Environment: @deepseek-ai/dsh-desktop 0.2.2-rc.1 → 0.2.2-rc.2, nightly, Windows 10.0.26300 x64. Install dir %LOCALAPPDATA%\Programs\DeepSeek Harness — per-user, contains a space. Installed 2026-11-04 as rc.1; this was the first in-app update attempt on the machine, and I ran it twice ~9 min apart.

Two identical logs (installer-logs\directory-failure-20261112-18{1526,2436}.log, 636 bytes each):

Operation: MoveFileExW
Windows error: 32 (another program is using this file; the process cannot access it)
Source:      C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness
Destination: C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness.old-{GUID}
Restoration error: 0
Windows: 10.0.26300
Attempts:
backup: Windows error: 32
backup: Windows error: 32
... (10 attempts, all 32)

The package itself was fine: sha512 matches nightly.yml, Authenticode valid (Hangzhou DeepSeek AI), isAdminRightsRequired: false, 405 GB free on the target volume. So: not network, not disk, not elevation, not a corrupt download.

On "is it the CWD?" — I think both observations in this thread are right, and here is the missing piece.

Both the Start-menu and the desktop shortcut carry:

WorkingDirectory = C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness

and at runtime every app process holds a bare-directory handle on the install dir — not a handle to a file inside it, but to the directory itself, i.e. the inherited CWD handle (handle64.exe "Programs\DeepSeek Harness"):

DeepSeek Harness.exe pid: 142796 type: File 58: ...\Programs\DeepSeek Harness
DeepSeek Harness.exe pid: 139392 type: File 9C: ...\Programs\DeepSeek Harness
DeepSeek Harness.exe pid: 142204 type: File 5C: ...\Programs\DeepSeek Harness
DeepSeek Harness.exe pid: 144084 type: File 9C: ...\Programs\DeepSeek Harness

So SetOutPath $PLUGINSDIR does release the installer's own CWD — your correction stands — but it cannot release the CWD handles held by the app tree: main process, renderers, and the Host, which is started through resources\runtime\bin\node.cmd from that same $INSTDIR and therefore inherits the very same CWD. customCheckAppRunning only polls $INSTDIR\DeepSeek Harness.exe, so any surviving descendant whose image is not that exact path keeps the directory un-renamable while the check reports clear. That is exactly the "check says clear, rename still fails for the whole 11.25 s window" combination you observed.

Workaround that worked here (no admin shell, no taskkill-all)

1. Tray → Quit; confirm Get-Process "DeepSeek Harness" returns nothing.
2. Double-click %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.2-win-x64.exe from Explorer (cwd ≠ $INSTDIR).
3. It installs and relaunches; verified 0.2.2-rc.2 in both the exe FileVersion and HKCU\...\Uninstall\DeepSeek Harness → DisplayVersion.

Two smaller notes

• After a manual install the updater cache is not cleaned: installer.exe + pending\<installer>.exe = 572 MB still on disk.
• The failure is fully silent by construction: the shell has already quit, the installer runs /S, --force-run only applies on success — so the user sees "the app vanished" and nothing else.

Cheapest fixes (either one unblocks the swap): spawn the Host and the installer with an explicit neutral cwd (e.g. os.tmpdir()), and/or enumerate and terminate the whole descendant tree before quitAndInstall; and when dshDirectoryOperation gives up, log the Restart Manager owners (RmRegisterResources($INSTDIR) → RmGetList) so the next report names the blocking processes in one line.

中文摘要：在每用户安装目录（路径含空格）、Windows 10.0.26300 上独立复现同一条错误（MoveFileExW → 错误 32 ×10，两次，Restoration error: 0）。补充判定：两个快捷方式的「起始位置」都是安装目录，且 handle64 显示每个 app 进程都对安装目录本身持有 File 句柄（= cwd 句柄）⇒ 安装器的 SetOutPath 只释放自己的 cwd，释放不了应用进程树（含经 resources\runtime\bin\node.cmd 启动、继承同一 cwd 的 Host）；customCheckAppRunning 只匹配 $INSTDIR\DeepSeek Harness.exe，所以「检查通过但目录仍锁」。规避：托盘退出 → 确认无残留 → 从资源管理器双击 pending\ 里的安装包。建议应用侧与安装器都以中性 cwd 启动，失败时用 Restart Manager 列出占用者。

[onezeroyl]

Status update (2026-11-13): fixed upstream in v0.2.2-rc.3

Root cause — consistent with what the other threads found, and it corrects my note above. The lock is not the installer's own CWD (that one is released by SetOutPath $PLUGINSDIR), it is the installation-status banner introduced in rc.2:

• apps/desktop/scripts/installer.nsh → customInit → !insertmacro ShowRestartBanner runs before any SetOutPath, so the installer's CWD is still the one inherited from the app (the shortcut's WorkingDirectory = install directory).
• apps/desktop/installer/restart-status.h then started rundll32.exe with CreateProcessW(..., nullptr /* lpCurrentDirectory */, ...), so the banner inherited that install-directory CWD, in a KILL_ON_JOB_CLOSE job whose handle is only closed on the success path.
• dshPromoteDirectories releases the installer's own CWD, but rundll32 keeps $INSTDIR as CWD → MoveFileExW($INSTDIR → $INSTDIR.old-{GUID}) returns ERROR_SHARING_VIOLATION 10/10.

That explains why rc.2 was 100 % broken, why retries could never help (the CWD never changes), and why running the same build manually from a neutral CWD worked. So my "the CWD case is ruled out" sentence was wrong — the CWD theory was right, just about the banner rather than the installer.

The fix — commit ac904e11 "fix(desktop): avoid restart status directory lock on release 0.2.2" (PR #8385, merged 2026-11-12T12:42:57Z), touching exactly apps/desktop/installer/restart-status.h (+4/−1) plus its fixture tests and docs:

struct Launch { std::wstring command; std::wstring program; std::wstring directory; HANDLE job; };
...
// An inherited installation directory would prevent its rename while the status window is alive.
launch->directory = system;            // GetSystemDirectoryW(...)
...
CreateProcessW(..., EXTENDED_STARTUPINFO_PRESENT, nullptr, launch->directory.c_str(), &startup.StartupInfo, &process)

i.e. the status process now starts in the Windows system directory, and windows-restart-status.ps1 / restart-status-owner.nsi assert that the install directory is released while the banner is alive.

Ship status: released as dsh-v0.2.2-rc.3 (published 2026-11-13T07:56:55Z); the release notes list "Fix an issue that could cause Windows desktop in-app updates to fail and prevent the app from reopening automatically". nightly.yml currently serves 0.2.2-rc.3 with stagingPercentage: 10, so only a fraction of installs see the prompt yet — the manual path keeps working in the meantime.

Credit where it is due: @Xly5487's bare-directory handle dump in this thread, plus #13086 (@CosMoss114, @skoenng) and #13098 (@xymdcyy) — they had the rundll32 link before I did.

One papercut is still open (not fixed by this ship): the installer still runs detached from BaseUpdater and nobody reads its exit code, so a failed directory swap is still silent and the app is still not relaunched. Worth a separate report if anyone hits a failure mode that survives rc.3.