DeepSeek Harness Windows 启动即崩：install_dir_access ACL 排查

7-Zip 退出码 2、事件日志 Exception 0x80000003、双击之后什么都不发生——这三个症状在 Windows 上其实是同一条链：安装目录的 DACL 里有一个 AppContainer 包 SID，却没有 ALL APPLICATION PACKAGES 的对应项，Chromium 的 install_dir_access 检查直接把主进程判死。 社区核对源码后确认这是 Electron/Chromium 的检查，不是 DSH 沙箱本身；修复脚本随包提供，但重装和清 AppData 都不会碰它（#10863、#10983）。

这篇按实验顺序写：先取证，再做三组单变量对照，最后才动手改 ACL。

DeepSeek Harness 实验一：只加 --enable-logging，把结论抓出来

--enable-logging 是唯一不改任何系统状态的取证手段：它只多写一份 stderr，就能告诉你这次崩溃到底是不是 install_dir_access。

1. 完全退出 DSH，包括托盘图标和任务管理器里的残留进程。
2. 从命令行启动："<安装目录>\DeepSeek Harness.exe" --enable-logging。
3. 观察 stderr，找 install_dir_access 这一行。命中的长这样：

FATAL:electron\shell\browser\win\install_dir_access.cc:52]
Sandboxed processes cannot read D:\deepseekherness:
its ACL has an entry for an AppContainer package SID
but none for ALL APPLICATION PACKAGES...

4. 同时看事件查看器 → Windows 日志 → 应用程序，找 Event 1000。社区记录到的形态是 Exception 0x80000003，faulting module 就是 exe 自身。
5. 如果 stderr 里没有 install_dir_access，这篇的结论不适用，停在这里换方向查。

一个前提要记住：提示里说的「packages 不能读」，指的是沙箱里的渲染进程读不到 icudtl.dat 这类安装树文件，不是你的项目目录有问题。

DSH插件 实验二：--no-sandbox 只当信号，不当方案

加 --no-sandbox 能启动，恰恰证明问题在 Chromium 的安装目录访问检查这一段；它是分诊信号，不是修复。

1. 用 --no-sandbox 启动一次，确认窗口能出来。
2. 再试 --disable-gpu、--disable-gpu-sandbox，社区实测这两个都无效——无效反而有价值，说明不是 GPU 相关，基本锁定沙箱的目录访问检查。
3. 修好 ACL 之后，务必把 --no-sandbox 去掉再验一次，别让它留在快捷方式里。

DeepSeek Harness 实验三：换一个可写路径，区分「安装器问题」和「目录问题」

安装阶段就失败时，换路径重装是最干净的单变量实验：装得上说明目标目录那条链的权限有问题，装不上才是安装器或临时目录的问题。

1. 在一个新盘或新建目录里试装，比如 D:\DSH\，确保它是你手动新建的普通目录。
2. 如果原路径是 %LOCALAPPDATA%\Programs 这类继承来的目录，特别值得换——社区遇到的安装日志是 Cannot create folder : 拒绝访问 指向 locales、resources，7-Zip 在解压第一步就停了。
3. 两种路径都失败，再怀疑安装器本身；只有原路径失败，直接去查那条链的 ACL。顺手把 TEMP 也换成另一块盘上的空目录，避免临时目录被打过 Low 完整性标签。

DeepSeek插件 实验四：两台机器 icacls 对比，直接看差异

把故障机与正常机的 icacls 输出并排放，差异一眼可见：故障机的父目录多了 S-1-15-3-1024-* 和包 SID S-1-15-2-<哈希>，却没有任何 ALL APPLICATION PACKAGES 条目。

1. 在故障机上执行 icacls "D:\Application"，把输出存成文件。
2. 在正常机上执行同一条命令，也存下来。
3. 逐行对齐，重点看三类条目：S-1-15-3-*（孤立 AppContainer SID）、S-1-15-2-<哈希>（具体包 SID）、S-1-15-2-1 / S-1-15-2-2（知名组）。
4. 故障机的典型形态是前两类有、后两类没有；正常机通常一条 AppContainer 条目都没有，安装目录继承的是普通 DACL，压根不触发这项检查。

DeepSeek Harness 修复：先跑随包脚本，再考虑手工 icacls

官方包的脚本是首选，因为它按祖先优先顺序删外来包 ACE，并在同一条链上补齐 WRITE_DAC/WRITE_OWNER；每处改动都备份、回读校验、打印回滚命令。

1. 打开一个非受限的 PowerShell 窗口（不要在 DSH 沙箱里的 shell 里跑）。
2. 先判断包 SID 到底写在哪一层：如果 icacls D:\ 里就有，那 -Path 应该是 D:\，而不是安装目录。
3. 执行：

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' `
  -Path '<install-dir-or-volume-root>' `
  -AllowRoot '<same-or-higher-dir>' `
  -Out '<recovery-dir>'

4. 看输出：脚本会删掉显式的 S-1-15-2-* 允许 ACE（结尾是 1 或 2 的知名组除外），并补权限。
5. 如果它拒绝处理（重解析点、受管应用目录），按它打印的回滚命令准备好，再用 icacls <dir> /save 导出 ACL 后手工改。

最小手工修复是把缺失项补上，两个知名组一起给：

icacls "<安装目录>" /grant "*S-1-15-2-1:(OI)(CI)(RX)" "*S-1-15-2-2:(OI)(CI)(RX)" /T

社区在 rc.3 标签（1f81c047）和 master（22ddee3）上都确认脚本存在；报告者按这条命令执行后，不需要任何启动参数就能正常启动。

DSH插件 为什么重装一定无效

ACL 属于目录，不属于程序文件；就地更新会继承它找到的 ACL，卸载器清理的是应用数据而不是父目录 ACL，所以重装一遍等于把同一个坏环境再铺一次。

1. 先确认你已经排除了「文件没写完」这一类：那是另一个问题（runtime 目录为空），症状是 ENOENT 而不是 0x80000003。
2. 不要靠删 %LOCALAPPDATA% 里的应用数据来试，社区明确说卸载器只动这部分。
3. 修完 ACL 后重启，再用 --enable-logging 验一次，stderr 里不再出现 install_dir_access 才算结束。
4. 记录下你改过哪一层，下次更新如果复发，先看更新器有没有重新继承坏 ACL。

注意事项

1. 不要在卷根上大范围 icacls /T。先 icacls /save 导出，改完能回滚再动手。
2. S-1-15-2-1 和 S-1-15-2-2 是两个不同的知名组，社区案例里两个都补才恢复。
3. 脚本拒绝执行不等于脚本有缺陷。它明确拒绝重解析点和受管应用目录，这时按提示手工处理。
4. --no-sandbox 别写进日常快捷方式，它关掉的是整个渲染进程沙箱。
5. 升级后复查。更新器目前不补授 AAP ACE，坏 ACL 会跟着文件一起被继承。

如果你的日志里压根没有 install_dir_access，说明这次崩溃不是 ACL 这一条，回到 0xC0000142 那篇按宿主形态重新分诊。相关排查见 DeepSeek Harness Windows 子进程报 0xC0000142：受限令牌与宿主定位。