Windows: in-app self-update downloads fine but the NSIS installer aborts after ~10.5 s without writing a single file

[Yuhanbravo]

Windows: in-app self-update downloads fine but the NSIS installer aborts after ~10.5 s without writing a single file

Summary

On Windows, the desktop in-app update downloads the new package and reaches the "install and
restart" step, the app quits, the NSIS installer process starts — and then it silently gives up
about 10.5 seconds later, before writing anything into the install directory. The app comes
back on the old version, the update is offered again, and the cycle repeats.

The update download is fine, the app-side update journal is clean (it ends at quit-requested
with no error state), and this is not a permission/UAC problem. The failure is in the handoff
between quitAndInstall() and the NSIS installer.

• Installed: 0.2.1-rc.3 (manual NSIS install of the same package type)
• Offered / downloaded: 0.2.1-rc.5 (nightly channel)
• App never updates; %TEMP%\ns*.tmp ($PLUGINSDIR) leftovers and an untouched install directory
  prove the installer never got past initialization.

Environment

OS	Windows 11 25H2, build 10.0.26200.8894 (x64)
App	@deepseek-ai/dsh-desktop 0.2.1-rc.3 (Electron 44.7.0, Node 24.21.0)
Update channel	nightly, feed https://download.deepseek.com/dsh-desk/feeds/win-x64/
Install	per-user, %LOCALAPPDATA%\Programs\DeepSeek Harness (HKCU uninstall entry, ... /currentuser)
Updater cache	%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater
Target	0.2.1-rc.5, pending\deepseek-harness-0.2.1-rc.5-win-x64.exe (289,408,544 bytes, EV signature Valid)

Steps to reproduce

1. Start the desktop app (0.2.1-rc.3) on a machine where a newer nightly build exists.
2. Click the update indicator (bottom-left "新版本") and let the update download.
3. Click 安装并重启 / Install and Restart.
4. Wait ~15 s, then start the app again.

Expected

The installer replaces the installation with 0.2.1-rc.5 and the app restarts on the new version.

Actual

• The app closes its windows and requests quit (the journal records quit-requested).
• The NSIS installer runs for ~10.5 s and exits without installing anything.
• Restarting the app yields 0.2.1-rc.3 again; the update is offered again.
• No error is shown to the user — the update state goes back to "available" on next launch.

Evidence

1. Update journal (DSH_DESKTOP_UPDATE_JOURNAL_DIR)

Captured attempt on 2026-11-02 (UTC; local time = UTC+8). The flow completes correctly on the app
side and ends at quit-requested; there is no error state:

{"sequence":0,"time":"2026-11-02T06:33:43.837Z","version":"0.2.1-rc.3","event":"started"}
{"sequence":1,"time":"2026-11-02T06:33:44.036Z","version":"0.2.1-rc.3","event":"state","phase":"available","targetVersion":"0.2.1-rc.5"}
{"sequence":2,"time":"2026-11-02T06:33:45.623Z","version":"0.2.1-rc.3","event":"workspace-ready"}
{"sequence":3,"time":"2026-11-02T06:33:54.617Z","version":"0.2.1-rc.3","event":"download-requested"}
{"sequence":4,"time":"2026-11-02T06:33:54.622Z","version":"0.2.1-rc.3","event":"state","phase":"downloading","targetVersion":"0.2.1-rc.5","percent":0}
{"sequence":5,"time":"2026-11-02T06:33:54.968Z","version":"0.2.1-rc.3","event":"state","phase":"ready","targetVersion":"0.2.1-rc.5"}
{"sequence":6,"time":"2026-11-02T06:33:54.971Z","version":"0.2.1-rc.3","event":"state","phase":"installing","targetVersion":"0.2.1-rc.5"}
{"sequence":7,"time":"2026-11-02T06:33:56.909Z","version":"0.2.1-rc.3","event":"install-confirmed"}
{"sequence":8,"time":"2026-11-02T06:33:56.919Z","version":"0.2.1-rc.3","event":"quit-requested"}

Next launch (30 min later) still reports 0.2.1-rc.3:

{"sequence":0,"time":"2026-11-02T07:04:11.624Z","version":"0.2.1-rc.3","event":"started"}
{"sequence":1,"time":"2026-11-02T07:04:11.816Z","version":"0.2.1-rc.3","event":"state","phase":"available","targetVersion":"0.2.1-rc.5"}
{"sequence":2,"time":"2026-11-02T07:04:13.482Z","version":"0.2.1-rc.3","event":"workspace-ready"}

Note the download completed in ~346 ms because the package was already cached from a previous
attempt — this is not a re-download problem.

2. The NSIS installer starts, then aborts during initialization

<local>\Temp\ns*.tmp is the installer's $PLUGINSDIR; a clean installer run deletes it. Every
failed attempt leaves one behind, containing only the installer UI plugin window-frame.dll —
i.e. the installer was terminated/aborted before extracting any application files:

attempt (local time)	$PLUGINSDIR created	last write	lifetime	contents
2026-10-26 09:13:52	09:13:52.047	09:14:02.731	10.68 s	window-frame.dll
2026-10-26 16:09:24	16:09:24.724	16:09:35.282	10.56 s	window-frame.dll
2026-10-26 16:10:12	16:10:12.496	16:10:23.069	10.57 s	window-frame.dll
2026-10-29 16:46:02	16:46:02.102	16:46:03.486	1.38 s	window-frame.dll
2026-10-29 16:48:28	16:48:28.721	16:48:29.954	1.23 s	window-frame.dll
2026-10-29 17:03:46	17:03:46.051	17:05:14.128	88.08 s	window-frame.dll
2026-11-02 14:05:09	14:05:09.230	14:05:19.801	10.57 s	window-frame.dll
2026-11-02 14:33:57	14:33:57.419	14:34:07.988	10.57 s	window-frame.dll

For the journaled attempt: quit-requested at 14:33:56.919 → installer starts at 14:33:57.419
(+500 ms) → installer dies at 14:34:07.988 (10.57 s).

The ~10.5 s constant looks like the installer's "old app is still running / wait for it to exit"
loop (repeated ~500 ms sleeps), expiring and aborting. But the app had already requested quit
500 ms before the installer even started, so on this machine the old Electron process is either
still alive past the wait window or the check is a false positive.

3. Nothing is written to the install directory

$ Get-ChildItem "$env:LOCALAPPDATA\Programs\DeepSeek Harness" -Recurse -File |
    Where-Object LastWriteTime -gt '2026-10-24'
(no files)

resources\app.asar, DeepSeek Harness.exe and Uninstall DeepSeek Harness.exe are all unchanged
since the last manual install. The update cache's differential baseline installer.exe is still
the 0.2.1-rc.3 installer (2026-10-29), and the HKCU uninstall entry still reports 0.2.1-rc.3.

4. Not a permission / elevation / AV problem

check	result
Install dir owner / ACL	JONSBO-9900X\Yuhan, current user has FullControl
Installer PE manifest	requestedExecutionLevel = asInvoker (no elevation needed)
pending\update-info.json	isAdminRightsRequired: false
Installer signature	Valid, CN="Hangzhou DeepSeek Artificial Intelligence Co., Ltd." (GlobalSign EV)
Read-only files / reparse points / Mark-of-the-Web	none
Free disk space	530 GB on C:
Smart App Control / WDAC / AppLocker	SAC off, no blocking policy events
Defender / AV events during attempts	none

So the update runs with the same privileges it would need for a normal per-user install and still
fails.

Analysis / hypothesis

DesktopUpdateCoordinator.install() calls electron-updater's quitAndInstall(true, true), which
spawns the installer before the app process exits:

installer.exe --updated /S --force-run

For a per-user NSIS install that is the right command line, and the app-side state machine is
correct (journal ends at quit-requested, no error). What fails is the installer's startup guard:
it waits a fixed ~10 s for the previous DeepSeek Harness.exe to disappear, then aborts during
.onInit (leaving $PLUGINSDIR behind and never touching $INSTDIR).

Two plausible causes, both DSH-side:

1. Race: the installer is spawned ~0.5 s after app.quit() is requested; if the Electron main
   process needs longer than the installer's wait window to fully exit (or the process lingers in a
   "no window but still alive" state), the guard always expires. This matches the deterministic
   10.56–10.68 s we see on every attempt.
2. False positive in the running-app check on this machine (e.g. it matches a helper process or
   a stale handle), which would have the same observable effect.

Either way the user gets no feedback: update-downloaded/ready → user confirms → app quits →
installer aborts → next launch offers the same update again.

Suggested direction for a fix

• Do not depend on the installer's wait-for-exit window: after spawning, terminate the main process
  deterministically (e.g. app.exit(0) once the installer is spawned, or spawn a detached helper
  that waits for the current PID to disappear and then runs the installer).
• Alternatively stage the update and install it on the next launch, before the UI starts.
• Surface the installer's outcome: if quitAndInstall() cannot complete, log the installer exit
  code / failure and show "installation failed" instead of silently reverting to available.
• Optional: keep the journal enabled by default for update attempts (it made this diagnosable).

Attachments

• journal-2026-11-02T14-33-43Z-pid33304-install-attempt.jsonl — failed update attempt
• journal-2026-11-02T15-04-11Z-pid3268-relaunch.jsonl — relaunch, still on the old version
• evidence.txt — OS/version/ACL/cache/$PLUGINSDIR dumps referenced above
  dsh-update-evidence.zip