【BUG】Windows 启动崩溃/静默失败：安装目录继承孤立 AppContainer SID 但缺少 ALL APPLICATION PACKAGES 授权

[superlovelace]

---

标题：Windows 启动崩溃/静默失败：安装目录继承孤立 AppContainer SID 但缺少 ALL APPLICATION PACKAGES 授权

环境

• DSH Desktop：0.2.0-rc.2（卸载重装最新版同样复现）
• Electron：44.0.0
• 系统：Windows x64，安装路径 D:\Application\DeepSeek Harness（非 Program Files）
• 另一台正常机器：同版本、同路径层级 D:\Application\DeepSeekHarnes，直接安装无错误

现象
启动时渲染进程崩溃，日志为 Error: Desktop renderer exited: crashed。卸载重装最新版后变为完全静默无响应、无日志、不启动。添加 --no-sandbox 可启动；--disable-gpu 和 --disable-gpu-sandbox 均无效。

根因定位（两台机器 icacls 对比确证）

故障机器 D:\Application 的 ACL 包含孤立 AppContainer SID（S-1-15-3-1024-3635283841-...）和包 SID（S-1-15-2-1971753839-...），但缺少 ALL APPLICATION PACKAGES（S-1-15-2-1）和 ALL RESTRICTED APPLICATION PACKAGES（S-1-15-2-2）的读取/执行授权。DSH 安装目录继承该 ACL 后，Chromium 沙箱受限令牌因 DACL 中存在 AppContainer ACE 而触发访问检查，却找不到允许自己通过的 ACE，导致沙箱子进程无法读取安装目录（如 icudtl.dat），启动即崩溃。

正常机器 D:\Application 的 ACL 不含任何 AppContainer SID，DSH 安装目录继承的是普通 DACL，沙箱不触发 AppContainer 访问检查，因此正常工作。

复现与修复
对故障机器 DSH 安装目录执行以下命令后恢复正常，无需任何启动参数：

icacls "D:\Application\DeepSeek Harness" /grant "*S-1-15-2-2:(OI)(CI)(RX)" "*S-1-15-2-1:(OI)(CI)(RX)"

建议
在 Windows 安装器（NSIS 或其他打包方式）的安装/更新流程中，主动为 $INSTDIR 授予 ALL RESTRICTED APPLICATION PACKAGES（SID S-1-15-2-2）的可继承读取执行权限，并检查 icacls 退出码，失败时报错而非静默继续。参考 NSIS 写法：

nsExec::ExecToLog '"$SYSDIR\icacls.exe" "$INSTDIR" /grant "*S-1-15-2-2:(OI)(CI)(RX)"'

Electron 生态已有多个项目采用此方案修复同类启动崩溃。

附：两台机器 icacls 输出对比

故障机器（MECHREVO）D:\Application（关键行：含 S-1-15-3-1024-... 和 S-1-15-2-1971753839-...，无 ALL APPLICATION PACKAGES）：

Windows PowerShell
版权所有（C） Microsoft Corporation。保留所有权利。

安装最新的 PowerShell，了解新功能和改进！https://aka.ms/PSWindows

加载个人及系统配置文件用了 1660 毫秒。
(base) PS C:\Users\MECHREVO> icacls "D:\Application"
D:\Application BUILTIN\Administrators:(F)
               BUILTIN\Administrators:(OI)(CI)(IO)(F)
               S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(RX)
               S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(OI)(CI)(IO)(GR,GE)
               NT AUTHORITY\SYSTEM:(F)
               NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
               NT AUTHORITY\RESTRICTED:(OI)(CI)(RX)
               BUILTIN\Users:(OI)(CI)(Rc,S,RD,REA,X,RA)
               S-1-15-2-1971753839-1985501901-1946445253-3157732598-1006331824-429121982-2148429426:(OI)(CI)(RX)
               BUILTIN\Users:(OI)(CI)(R)
               BUILTIN\Administrators:(I)(F)
               BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
               NT AUTHORITY\SYSTEM:(I)(F)
               NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
               NT AUTHORITY\Authenticated Users:(I)(M)
               NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
               BUILTIN\Users:(I)(RX)
               BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

已成功处理 1 个文件; 处理 0 个文件时失败
(base) PS C:\Users\MECHREVO>

故障机器 DSH 安装目录（补授权后出现 ALL APPLICATION PACKAGES）：

(base) PS C:\Users\MECHREVO> icacls "D:\Application\DeepSeek Harness"
D:\Application\DeepSeek Harness APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(OI)(CI)(RX)
                                APPLICATION PACKAGE AUTHORITY\所有受限制的应用程序包:(OI)(CI)(RX)
                                BUILTIN\Administrators:(I)(F)
                                BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                                S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(I)(RX)
                                S-1-15-3-1024-3635283841-2530182609-996808640-1887759898-3848208603-3313616867-983405619-2501854204:(I)(OI)(CI)(IO)(GR,GE)
                                NT AUTHORITY\SYSTEM:(I)(F)
                                NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                                NT AUTHORITY\RESTRICTED:(I)(OI)(CI)(RX)
                                BUILTIN\Users:(I)(OI)(CI)(Rc,S,RD,REA,X,RA)
                                S-1-15-2-1971753839-1985501901-1946445253-3157732598-1006331824-429121982-2148429426:(I)(OI)(CI)(RX)
                                BUILTIN\Users:(I)(OI)(CI)(R)
                                NT AUTHORITY\Authenticated Users:(I)(M)
                                NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
                                BUILTIN\Users:(I)(RX)
                                BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

正常机器（REDMI）D:\Application（无任何 AppContainer SID）：

C:\Users\REDMI>icacls "D:\Application"
D:\Application BUILTIN\Administrators:(I)(F)
               BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
               NT AUTHORITY\SYSTEM:(I)(F)
               NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
               NT AUTHORITY\Authenticated Users:(I)(M)
               NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
               BUILTIN\Users:(I)(RX)
               BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

已成功处理 1 个文件; 处理 0 个文件时失败

C:\Users\REDMI>icacls "D:\Application\DeepSeekHarnes"
D:\Application\DeepSeekHarnes BUILTIN\Administrators:(I)(F)
                              BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                              NT AUTHORITY\SYSTEM:(I)(F)
                              NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                              NT AUTHORITY\Authenticated Users:(I)(M)
                              NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
                              BUILTIN\Users:(I)(RX)
                              BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

已成功处理 1 个文件; 处理 0 个文件时失败

C:\Users\REDMI>

正常机器 DSH 安装目录继承同样干净的 ACL，无 AppContainer 条目。

---

[PerryLink]

This is Electron's check, not DSH's sandbox. The repair is to remove the stray package entry.

The FATAL text you quoted ("its ACL has an entry for an AppContainer package SID but none for ALL APPLICATION PACKAGES") is Chromium's install-directory access check: when an installation directory carries a package SID ACE without the ALL APPLICATION PACKAGES (S-1-15-2-1) counterpart, its sandboxed renderers cannot read the install tree and the browser process exits. DSH cannot add that ACE for you; what it can do is take the stray package entry away, which makes the check moot.

That is exactly what the bundled diagnose-windows-sandbox-acl does (packages/sandbox/sandbox-windows-acl/README.md:78-80): it removes explicit AppContainer package allow ACEs (S-1-15-2-*, excluding the well-known groups ending in 1 or 2) at their source, ancestor first, and repairs missing WRITE_DAC / WRITE_OWNER on the same chain. One unconfined run, with the install directory as both path and bound:

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<install-dir>' -AllowRoot '<install-dir>' -Out '<recovery-dir>'

Every changed DACL is backed up, re-read to verify, and paired with a rollback command. Expect it to refuse "managed application trees" — if the install directory counts as one, it will say so instead of touching it, and you will need the same edit by hand (icacls), after exporting the ACL.

Note the Windows uninstaller does not repair this: it removes app data, not a volume or parent-directory ACL, and an in-place update inherits the ACL it finds. That is why reinstalling did not clear it.

I checked that the asset exists at the rc.3 tag (1f81c047) and read the skill and script sources; I did not run them.

[superlovelace]

我之前已经对安装目录手动执行了 icacls /grant "*S-1-15-2-1:(OI)(CI)(RX)" "*S-1-15-2-2:(OI)(CI)(RX)"，现在能正常启动。如果之后用 diagnose-windows-sandbox-acl 清掉孤立条目，之前手动补的授权需要撤销吗，还是保留也没关系？