Windows desktop installer rejects every install directory (INSTALLER_PATH_INVALID) on a machine with redirected AppData

[aitu0414]

中文摘要：Windows 11 上，0.2.1-rc.5 和 0.2.2-rc.1 的桌面版安装器对任何安装路径都弹「请选择本地磁盘上的完整文件夹路径…」，
包括默认路径、D:\DeepSeekHarness、预先建好的空目录；普通权限/管理员权限、图形/静默安装全部失败（退出码 2）。
安装包签名与 SHA-512 均正确，从安装包中解出 app-64.7z 直接运行则完全正常，因此问题定位在安装器的路径校验阶段。
机器特点是用户已知文件夹被拆分到两个盘（Roaming 在 F:、Local 在 C:），ProgramW6432=F:\Program Files。

Summary

On this Windows 11 x64 machine, the DeepSeek Harness desktop installer cannot install to any directory.
Validation always fails with the INSTALLER_PATH_INVALID message from
apps/desktop/installer/path.nsh,
even though the directory satisfies every documented rule (absolute local fixed-disk path, < 180 chars,
no special characters, empty or non-existent target, no reparse points).

Both the dsh-latest download and the newest nightly build behave identically, in GUI and silent mode,
with and without elevation.

Environment

• OS: Microsoft Windows 11, build 10.0.22631, AMD64 (D:\/C:\ both NTFS, GetDriveTypeW == 3)
• Installer language: zh_CN (UI text is the Simplified Chinese one)
• Security software: Kaspersky Standard 21.26 running
• User shell folders are split across two volumes:
  • USERPROFILE = C:\Users\<user>
  • AppData\Roaming (redirected) = F:\Users\Ayin\AppData\Roaming
  • Local AppData = C:\Users\<user>\AppData\Local
  • Desktop = F:\Users\Ayin\桌面
  • ProgramW6432 = F:\Program Files (Program Files was moved to F:)
• TEMP = C:\Users\<user>\AppData\Local\Temp

Builds tested

Build	URL	Size	SHA-512 (base64)
0.2.1-rc.5 (dsh-latest)	https://download.deepseek.com/desktop/dsh-latest-windows-x64.exe	289,408,544	gu2dH+aTr678c0P8DGAH/h4B1GaWfQIjpsPrLjl/ukLrQIh6DLVq/MhX4FZvJ8o1GCMocOhix6XbLa6KmtjXXg==
0.2.2-rc.1 (nightly)	https://download.deepseek.com/dsh-desk/bin/win-x64/deepseek-harness-0.2.2-rc.1-win-x64.exe	293,425,336	swcK0J6ofGkaAWLRpOes2ca7CWO8vuM5Vp0FRnQ/DG3q+Z+OhvsgLz3hIiSYpRUETY+fEz+Ww86fNa0jiVIifw==

The 0.2.2-rc.1 SHA-512 matches the official feed
https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml exactly.

Both files carry a valid Authenticode signature:
CN="Hangzhou DeepSeek Artificial Intelligence Co., Ltd.", issued by
GlobalSign GCC R45 EV CodeSigning CA 2020, timestamped. So this is not a corrupted or tampered download.

Steps to reproduce

1. Download either build above and run it (per-user install, no UAC prompt on a normal launch).
2. The custom welcome page appears with the default path
   C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness.
3. Click 立即安装.

Result: a message box appears immediately:

请选择本地磁盘上的完整文件夹路径，不能使用磁盘根目录、系统目录、链接目录或包含特殊字符的路径。

which is INSTALLER_PATH_INVALID from
locales/zh_CN.json.
No file is written; the installer stays on the welcome page.

Variants that all fail the same way

Variant	Result
Default C:\Users\<user>\AppData\Local\Programs\DeepSeek Harness	INSTALLER_PATH_INVALID
C:\Users\<user>\AppData\Local\Programs\DeepSeekHarness (no space in name)	same
D:\DeepSeekHarness (does not exist, 300+ GB free, same local NTFS disk)	same
Pre-create the target directory (empty, ordinary directory) then install	same
Silent: DeepSeek-Harness-…-win-x64.exe /S	exit code 2, nothing installed
Silent with explicit dir: /S /D=D:\DSHApp	exit code 2, nothing installed
Elevated (Start-Process -Verb RunAs, UAC accepted)	same dialog
Launch through Task Scheduler (clean environment, interactive)	NSIS temp error, see below

Note: customInit in
scripts/installer.nsh
also runs InstallerPreflight in silent mode, which is why /S exits with 2 without showing anything.

Second symptom: temp extraction

If the installer is started with the normal user TEMP
(C:\Users\<user>\AppData\Local\Temp, which is writeable by the user and has a normal ACL),
the NSIS stub fails before showing the welcome page:

NSIS Error
Error writing temporary file. Make sure your temp folder is valid.

Starting the same executable with TEMP/TMP pointing to a directory on another volume reaches the UI,
so the UI itself and the extraction of the plugin DLLs work. (The user TEMP directory has
NT AUTHORITY\SYSTEM: FullControl, BUILTIN\Administrators: FullControl, aitu\14647: FullControl.)

What I verified about the candidate paths (not the cause, as far as I can tell)

Checked from both 32-bit (SysWOW64 PowerShell) and 64-bit processes, on the same machine:

• GetDriveTypeW("C:\") and GetDriveTypeW("D:\") both return 3 (DRIVE_FIXED).
• GetFileAttributesW of every ancestor of the default path returns 0x00000010 (directory, not
  FILE_ATTRIBUTE_REPARSE_POINT); the final component either does not exist (0xFFFFFFFF) or is an
  ordinary empty directory.
• Path length 54 characters, ASCII only, no :*?"<>|/, no trailing space/dot, no reserved device name.
• C:\Users\<user>, …\AppData, …\Local, …\Programs are all real directories (no junctions/symlinks;
  fsutil reparsepoint query reports "not a reparse point").

So all checks in InstallerValidatePath should pass for these inputs.

Why I believe this is the installer, not the download

I extracted the NSIS payload with 7-Zip from the same signed executable:

7z x deepseek-harness-0.2.2-rc.1-win-x64.exe -o<dir>      # gives $PLUGINSDIR\app-64.7z
7z x app-64.7z -o<app-dir>                                 # gives "DeepSeek Harness.exe" + resources

and the extracted application runs normally: the window opens, the Host binds an OS-assigned local port,
the update check reports 0.2.2-rc.1 as current. So the packaged payload, the runtime and the app itself
are fine on this machine — only the installer's preflight/validation stage fails.

Environment details that may matter

The unusual part of this machine is the relocated shell folders: AppData\Roaming, Desktop,
Documents, Downloads live on F:, while Local AppData stays on C:, and Program Files was moved
to F: (so %ProgramW6432% = F:\Program Files). NSIS derives $APPDATA, $LOCALAPPDATA,
$PROGRAMFILES32/64 and $PROFILE from these locations, and InstallerValidatePath compares ancestors
against them. It would be worth checking whether a reloaded/redirected known folder makes one of those
constants resolve to something that trips the ancestor comparison, or makes System::Call to
GetDriveTypeW fail in the installer process.

Request

1. Please add diagnostics to the path validation: on failure, log (or show) $InstallerPath,
   StrLen, the GetDriveTypeW result and which check returned early. Right now INSTALLER_PATH_INVALID
   covers six different branches and is impossible to debug from the outside.
2. Please document the "redirected known folders / Program Files on another volume" scenario for the
   Windows installer, or relax the validation if it is too strict for it.
3. If a diagnostic build (or an /NCRC-style flag that skips the preflight for testing) is available,
   I am happy to run it and report the exact values.

Workaround used for now

Extract $PLUGINSDIR\app-64.7z from the signed installer and run DeepSeek Harness.exe from the extracted
folder (with desktop/Start Menu shortcuts). Everything works except the uninstall entry and in-app updates
(which would call the same NSIS installer).

Links

• Repository: https://github.com/deepseek-ai/deepseek-harness
• Discussions (feedback channel): https://github.com/deepseek-ai/deepseek-harness/discussions
• Release dsh-v0.2.2-rc.1: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.2-rc.1
• Documentation: https://deepseek-harness.github.io/deepseek-harness/
• Fixed Windows download: https://download.deepseek.com/desktop/dsh-latest-windows-x64.exe
• Windows nightly feed: https://download.deepseek.com/dsh-desk/feeds/win-x64/nightly.yml
• Validation source: https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/desktop/installer/path.nsh
• Preflight callers: https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/desktop/scripts/installer.nsh
• Chinese installer strings: https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/desktop/installer/locales/zh_CN.json
• Installer documentation: https://github.com/deepseek-ai/deepseek-harness/blob/master/apps/desktop/packaging/README.md
• Community FAQ entry about the empty-directory requirement (related, not this bug): https://dsh-ai.com/faq/887/

[FIXUAI]

Adding a sibling failure branch from the same family, in case it helps triage.

On 0.2.2-rc.1 → 0.2.2-rc.2 the path format check passed (the default %LOCALAPPDATA%\Programs\DeepSeek Harness was accepted by InstallerValidatePath), but installation was still refused — this time with INSTALLER_PATH_OWNERSHIP, because InstallerPreflight (apps/desktop/installer/path.nsh:127) compares the target against HKCU\Software\<GUID>\InstallLocation, and that key was absent on my machine. Note that FileExists "$INSTDIR\DeepSeek Harness.exe" does not rescue this case: it is an OrIfNot in the same condition, so a directory that clearly holds the product is still rejected. In silent mode the installer does SetErrorLevel 2 + Quit before writing any file or report, which is why the in-app "Install and restart" fails with zero feedback.

Full timeline, source analysis and the verified workaround: #13041.

Relevant to this thread: the "extract $PLUGINSDIR\app-64.7z and run it in place" workaround (the route considered here) never writes HKCU\Software\<GUID>\InstallLocation, so in-app updates stay permanently broken afterwards — download and SHA-512 verification keep succeeding, the version just never changes. Quick check on an affected machine:

Get-ChildItem HKCU:\Software | ForEach-Object { $v = Get-ItemProperty $_.PSPath -EA 0; if ($v.InstallLocation -like "*DeepSeek*") { "$($_.PSChildName) -> $($v.InstallLocation)" } }

If that prints nothing, running the signed installer once against a renamed (hence empty) target directory is enough to register it — details and evidence in #13041.