DSH 桌面版崩溃反馈：workspace 与安装目录同树时，沙箱完整性标签导致启动失败且重装无效

[Lyxnb1]

Uploading DSH-崩溃反馈-完整性标签与沙箱自伤.md…

---

DSH 桌面版崩溃反馈：workspace 与安装目录同树时，沙箱完整性标签导致启动失败且重装无效

项	内容
产品	@deepseek-ai/dsh-desktop 0.2.1-rc.2（Electron 44.7.0 / Node 24.21.0）
平台	Windows x64（win32 x64，zh-CN）
会话策略	workspace-write；workspace 根 = E:\AI-Agent\Deepseek
安装位置	E:\AI-Agent\Deepseek\Harness（位于 workspace 根之下）
严重度	P1：应用完全无法启动；卸载重装无法恢复；用户需管理员权限改目录安全元数据才能自救
复现率	该目录布局下 100%（多轮、含重装与换数据目录）；恢复完整性级别后 1/1 正常

修订记录

• v2（2026-10-17）：修正 §8。用户在普通 Windows PowerShell 5.1 会话中实测 Get-Acl C:\ 正常（返回 NT SERVICE\TrustedInstaller），且 PSModulePath 包含 C:\Windows\system32\WindowsPowerShell\v1.0\Modules；因此「本机 5.1 缺该模块」不成立，故障范围收窄为 DSH 派生的预检子进程环境。
• v3（2026-10-17）：补入决定性判定实验——同一脚本以相同标志在普通 PS 5.1 中执行输出 ready / EXIT=0，确认脚本与机器正常；缺陷定性为「预检所需权限被预检所在沙箱剥夺」的自举循环，并附内部排查线索（dsh-pwsh-sandbox、@dsh-ops/*-win32-x64、S-1-4-* 授权）。
• v4（2026-10-17）：新增附录 A，内嵌相关日志与命令输出原文（渲染进程崩溃日志、host 退出日志、DSH 内 shell 报错、用户侧判定输出、相关源码行），并标注未保留项与退出码换算。

1. 摘要

把 DSH 安装目录放在 workspace-write 的 workspace 根之下后，DSH 沙箱对 workspace 根设置的完整性标签/安全元数据随目录继承覆盖了应用安装树，并继续覆盖后续重装产物。结果：应用启动即崩（渲染进程 launch-failed、退出码 0x80000003），且无法写入自身 AppData 状态目录。卸载重装、更换 DSH_HOME/APPDATA 均无效；只有管理员把安装树的完整性级别改回 Medium 后应用才恢复。

2. 现象（可观察）

1. 双击桌面快捷方式 → 无窗口，进程 0.3–1 s 内退出。
2. 显式启动退出码 0x80000003（STATUS_BREAKPOINT，Chromium 致命断言）；--no-sandbox 后不再崩于该点。
3. 渲染进程日志：Error: Desktop renderer exited: launch-failed（logs\crash-2026-10-17T11-41-14-202Z-renderer.log:12）。
4. 应用无法在 %APPDATA%\@deepseek-ai\dsh-desktop 创建单实例锁与 GPU 缓存，ACCESS_DENIED (0x5)；随后主进程以 process.exit 结束。
5. 同一机器上把该树中同一可执行文件复制到普通目录运行，完整性级别为 Medium；留在该树中则为 Low（外部排查会话的对照实验）。
6. 将安装树的完整性级别恢复 Medium 后，应用正常开窗。

3. 最小复现（供厂商验证）

# 1) 造一个"安装目录在 workspace 内"的布局
New-Item -ItemType Directory -Force E:\repro | Out-Null
# 2) 把 DSH 装到 E:\repro\Harness，并以 workspace-write 打开 E:\repro
# 3) 触发一次 shell 工具（会走 workspace 预检 prepare-workspace.ps1）
# 4) 检查标签：安装树/根目录是否出现 Low
icacls E:\repro | findstr /i "Mandatory Label"
icacls "E:\repro\Harness\DeepSeek Harness.exe" | findstr /i "Mandatory Label"
# 5) 退出后重新双击启动，观察 0.3 s 闪退 + renderer launch-failed

若第 3 步预检被跳过（例如策略非 workspace-write），可直接用 icacls E:\repro /setintegritylevel "(OI)(CI)Low" /t 后重装一次，复现"重装仍坏"。

4. 关键证据

• 崩溃现场：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-17T11-41-14-202Z-renderer.log（launch-failed）；同目录 crash-2026-10-16T03-11-10-331Z-host.log:12 记录 host 退出 1073807364（0x40010004）。
• 沙箱会写完整性标签（DSH 自身代码）：dsh-ops/bin/prepare-workspace.ps1:17 注释原文 WRITE_OWNER, needed to set the sandbox integrity label；dsh-ops/lib/workspace-preparation.js:34 用 Windows PowerShell 5.1 执行该预检，且仅在 mode === 'workspace-write' 时触发。
• ACL 足迹确属 DSH 沙箱：DSH 自带技能 diagnose-windows-sandbox-acl 明确写明「DSH 的 S-1-4-* 授权与 Everyone 的 DeleteSubdirectoriesAndFiles 拒绝是预期状态，不是冲突」；这两个条目恰好出现在被标记的 workspace 根上，说明该目录确被 DSH 沙箱改写过。
• 布局耦合：workspace 根 ⊃ 安装目录；标签带 (OI)(CI) 继承 ⇒ 重装写入的新文件继续继承 Low。
• 恢复验证：管理员执行 icacls <安装树> /setintegritylevel "(OI)(CI)Medium" /t 后，--version 与正常启动均恢复正常。

5. 我对机制的判断（含不确定项，请勿直接采信为定论）

• 已确证：故障与"安装树位于 workspace 根之下 + workspace 预检写安全元数据"这一组合强相关；恢复 Medium 后故障消失；重装无效是因为缺陷在目录级元数据而非文件。
• 存疑（建议厂商用自身实现确认）：Windows 的进程完整性级别来自访问令牌，并不直接来自镜像文件上的标签；因此"文件被打 Low ⇒ 进程必以 Low 运行"不成立。更可能的真实链路是：Electron 主进程/受限 host 的令牌上下文 + 被改写的 AppData 目录 ACL/标签，使单实例锁与 GPU 缓存创建失败，进而触发 Chromium 致命断言与 launch-failed。外部排查中的"同文件换目录 → IL 变化"对照，可能混入了排查工具自身沙箱令牌的影响（该实验同时改动了多个变量）。
• 未验证：把安装目录迁到 workspace 之外是否 100% 稳定（本轮未做迁移验证）。

6. 影响与成本

1. 用户侧：应用彻底不可用；重装是常识性自救手段，但恰好无效，会显著拉长故障周期。
2. 支持侧：现象是"闪退无窗口"，日志里只有 launch-failed，缺少完整性级别等关键上下文，用户与客服都难以定位。
3. 误操作风险：DSH 文档/技能提示"清理残留 ACE"，而 S-1-4-* 与 Everyone 删除拒绝恰恰是沙箱正常足迹；用户若按字面清理，可能破坏沙箱授权。

7. 建议修复（按优先级）

级别	建议
P0	沙箱标签/ACL 的作用域排除安装树：检测到 workspace 根包含安装目录（或反之）时不打标签，或仅对 workspace 内白名单路径生效
P0	预检失败要可诊断、可降级：当前预检异常会让所有 shell 工具在执行前失败，且仅回吐 PowerShell 报错；应区分"环境故障/权限拒绝"，并给出可复制的修复命令
P1	安装器写入后重置继承的完整性级别（或默认装到用户级目录并显式设 Medium）
P1	崩溃日志打印 Integrity Level、workspace 预检结果、AppData 写权限自检结果（现在只能靠外部脚本自测）
P2	文档明确"不要把安装目录放进 workspace"，并在首次以 workspace-write 打开包含安装目录的根时提示

8. 附带发现的独立缺陷：workspace 预检子进程环境导致所有 shell 工具不可用

现象：在本机日常使用中，所有 shell 工具（bash / pwsh）均在执行前失败，且不是权限拒绝：

DSH workspace preparation failed (not a user permission denial):
prepare-workspace.ps1 : 无法加载模块「Microsoft.PowerShell.Security」，找不到 Get-Acl 命令

已排除：普通 Windows PowerShell 5.1 会话中 Get-Acl C:\ 正常（返回 Owner = NT SERVICE\TrustedInstaller），PSModulePath 含 C:\Windows\system32\WindowsPowerShell\v1.0\Modules；Modules\Microsoft.PowerShell.Security\ 仅有 .psd1、实现 DLL 在 GAC（93,696 B）属于该 Windows 版本的正常布局，不是缺 DLL。

判定实验（2026-10-17，决定性）：用与 DSH 完全相同的标志在普通会话执行同一脚本——

powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -File <...>\dsh-ops\bin\prepare-workspace.ps1 -Workspace <workspace-root> -BackupDir <...>\.dsh\dsh-ops\acl-backups
→ 输出：ready
→ EXIT=0

⇒ 脚本、机器、参数组合均正常（且该次未改动任何 ACL，说明 WRITE_OWNER 已具备）。唯一变量是「谁派生这个子进程」。因此缺陷位于 DSH 的派生环境：令牌与 PSModulePath 二者之一或叠加。

内部排查线索（供厂商参考，本机可见）：profile 中存在 @deepseek-ai/dsh-pwsh-sandbox 组件与内置运行时 @dsh-ops/bash-win32-x64、@dsh-ops/pwsh-win32-x64；workspace 根上恰有 DSH 自己写入的 S-1-4-* 受限 SID 授权（见 §4）。这与「shell 侧使用受限令牌」一致；若该令牌被沿用到预检子进程，则 Get-Acl 所在的模块装载与 GAC 访问会被访问检查拒绝，而预检又必须在该 workspace 根上取 WRITE_OWNER——这是一个自举循环：预检需要的权限，正好被预检所在的沙箱剥夺。

因此故障范围：仅在 DSH 以 spawn(..., ['-NoProfile','-NonInteractive','-File', script, ...]) 派生的那个 PS 5.1 子进程里出现。可能方向（需厂商内部确认）：

1. 宿主进程把 PSModulePath 改写/裁剪后传给子进程（例如只保留 pwsh 7 的模块路径），导致 5.1 自动加载失败；
2. 宿主以受限/低完整性令牌派生该子进程，模块扫描被访问检查拦下；
3. 子进程环境里缺少 PS 5.1 默认模块路径（env 存在但为空时，PowerShell 不一定回填默认值）。

供厂商复现的判定命令（在普通 PS 5.1 中直接跑预检脚本，绕开 DSH）：

powershell -NoProfile -NonInteractive -File "$env:USERPROFILE\.dsh\profiles\desktop\node_modules\dsh-ops\bin\prepare-workspace.ps1" -Workspace "<workspace-root>" -BackupDir "$env:USERPROFILE\.dsh\dsh-ops\acl-backups"

• 若输出 ready / prepared 且退出码 0 ⇒ 脚本与机器正常，缺陷在 DSH 的派生环境（上述 1–3）；
• 若同样报 Get-Acl 找不到 ⇒ 缺陷在脚本内部逻辑/参数。

建议：

• 预检改用 pwsh 7 或直接调用 .NET System.Security.AccessControl API，不再依赖 PS 5.1 的模块自动加载；
• 预检失败应降级为警告并保留 shell 可用，或至少区分“环境故障 / 权限拒绝”并输出子进程的实际 PSVersion 与 PSModulePath。当前形态是：一个用于“准备权限”的辅助步骤一旦失败，整条 bash/pwsh 工具链全部不可用，用户侧表现为“DSH 的命令行彻底坏了”，且 DSH 之外无法自行诊断。

9. 请一并附上的取证命令（便于厂商复现）

# 环境
$PSVersionTable.PSVersion; (Get-CimInstance Win32_OperatingSystem).BuildNumber
# 标签与 ACL（三级都要看）
icacls "<workspace-root>" | findstr /i "Mandatory Label"
icacls "<install-dir>" | findstr /i "Mandatory Label"
icacls "<install-dir>\<app>.exe" | findstr /i "Mandatory Label"
# 启动进程的实际完整性级别
whoami /groups | findstr /i "Mandatory Label"
# 预检是否可用
powershell -NoProfile -Command "Get-Acl C:\ | Select-Object Owner"

10. 附件清单

1. crash-2026-10-17T11-41-14-202Z-renderer.log（renderer launch-failed）
2. crash-2026-10-16T03-11-10-331Z-host.log（host 退出 0x40010004）
3. dsh-ops/bin/prepare-workspace.ps1、dsh-ops/lib/workspace-preparation.js（含行号）
4. 修复前/后的 icacls 输出（安装树根目录、Harness、exe）——该项现场未落盘，需按附录 A.6 补采；第 1–3 项原文已内嵌于附录 A。

---

附录 A：相关日志与命令输出（原文摘录）

编码说明：本机控制台为 GBK，被工具以 UTF-8 捕获时中文会乱码（如 ��ģ�顰Microsoft.PowerShell.Security）。A.3 按语义还原并注明；A.1/A.2 为日志文件原文，未经改写。

A.1 渲染进程启动失败日志（完整，17 行）

文件：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-17T11-41-14-202Z-renderer.log

time: 2026-10-17T11:41:14.202Z
source: renderer
phase: startup
app: @deepseek-ai/dsh-desktop 0.2.1-rc.2
platform: win32 x64
electron: 44.7.0
node: 24.21.0
locale: zh-CN
shell pid: 16812

--- error ---
Error: Desktop renderer exited: launch-failed
    at WebContents.<anonymous> (file:///E:/AI-Agent/Deepseek/Harness/resources/app.asar/lib/main.js:12933:107)
    at WebContents.emit (node:events:526:24)

--- renderer console (error level, oldest first) ---
(no error-level renderer console output was captured)

A.2 host 进程退出日志（完整 33 行；其中 11 行为 rea MCP 工具日志，已明确省略）

文件：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-16T03-11-10-331Z-host.log（版本 0.2.0-rc.2，即更新前）

time: 2026-10-16T03:11:10.331Z
source: host
phase: running
app: @deepseek-ai/dsh-desktop 0.2.0-rc.2
platform: win32 x64
electron: 44.0.0
node: 24.18.1
locale: zh-CN
shell pid: 36516

--- error ---
Error: dsh desktop host exited with 1073807364: (node:32832) [DEP0180] DeprecationWarning: fs.Stats constructor is deprecated.
(Use `DeepSeek Harness --trace-deprecation ...` to show where the warning was created)
…（此处省略 11 行 rea MCP 工具调用 JSON 日志，与本缺陷无关）…
    at ChildProcess.<anonymous> (file:///E:/AI-Agent/Deepseek/Harness/resources/app.asar/lib/main.js:3724:64)
    at Object.onceWrapper (node:events:631:26)
    at ChildProcess.emit (node:events:509:28)
    at maybeClose (node:internal/child_process:1124:16)
    at ChildProcess._handle.onexit (node:internal/child_process:306:5)

--- renderer console (error level, oldest first) ---
dsh-app://app/:0 ResizeObserver loop completed with undelivered notifications.
dsh-app://app/:0 ResizeObserver loop completed with undelivered notifications.

A.3 DSH 内 shell 工具报错（GBK→UTF-8 捕获，语义还原）

DSH 每次执行 bash/pwsh 前的 workspace 预检失败，工具调用直接返回该错误；用户侧表现为“所有命令行工具不可用”：

DSH workspace preparation failed (not a user permission denial): C:\Users\PC\.dsh\profiles\desktop\node_modules\dsh-ops\bin\prepare-workspace.ps1 : 无法加载模块「Microsoft.PowerShell.Security」，找不到 Get-Acl 命令。

（原始捕获片段中的中文为乱码，例如 ��ģ�顰Microsoft.PowerShell.Security，属编码显示问题，不影响语义与判定。）

A.4 用户侧实测输出（普通 Windows PowerShell 5.1）

测试 1：Get-Acl C:\（外层双引号被父 shell 展开，导致模块路径被当命令执行；但末尾 Get-Acl 仍正常返回）

Owner
-----
NT SERVICE\TrustedInstaller

测试 2：以与 DSH 相同标志执行同一预检脚本

PS> & "$env:SystemRoot\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "$env:USERPROFILE\.dsh\profiles\desktop\node_modules\dsh-ops\bin\prepare-workspace.ps1" -Workspace "E:\AI-Agent\Deepseek" -BackupDir "$env:USERPROFILE\.dsh\dsh-ops\acl-backups"; "EXIT=$LASTEXITCODE"
ready
EXIT=0

实测 PSModulePath（三路径，含系统模块目录）：

C:\Users\PC\OneDrive\Dokumen\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules

A.5 相关源码行（DSH 0.2.1 安装包内）

dsh-ops/bin/prepare-workspace.ps1：

13: $acl = Get-Acl -LiteralPath $item.FullName
17: $needed = [Security.AccessControl.FileSystemRights]::TakeOwnership # WRITE_OWNER, needed to set the sandbox integrity label

dsh-ops/lib/workspace-preparation.js：

14:  if (platform !== 'win32' || policy?.mode !== 'workspace-write') return Promise.resolve()
29:  const windows = process.env.SystemRoot ?? 'C:\\Windows'
30:  const executable = path.join(windows, 'System32/WindowsPowerShell/v1.0/powershell.exe')
34:  const child = spawn(executable, ['-NoProfile','-NonInteractive','-File', script, '-Workspace', root, '-BackupDir', backups], { windowsHide: true, stdio: ['ignore','pipe','pipe'] })

A.6 未随本反馈保留的日志（如需请按下列命令补采）

• icacls 修复前/后的原始输出（安装树根、Harness、exe 三级）——现场未落盘。补采：

  foreach ($p in @("<workspace-root>","<install-dir>","<install-dir>\<app>.exe")) { "=== $p ==="; icacls $p }

• Chromium --enable-logging=stderr --v=1 的完整 stderr——排查中曾重定向到 %TEMP%，会话结束清理后未留存；如需复采可在启动命令追加该参数并保留输出。

• 退出码换算：1073807364 = 0x40010004（DBG_TERMINATE_PROCESS）；0x80000003 = STATUS_BREAKPOINT（Chromium 致命断言触发点）。

[5777-wq]

补充：独立复现（非本帖作者）+ 最新版 0.2.2-rc.1 仍未修的证据

环境：Windows 11 家庭中文版 10.0.26200 x64；@deepseek-ai/dsh-desktop 0.2.1-rc.2；workspace 根 = D:\DeepseekHarness，其下同时包含安装树 Desktop\ 与 DSH_HOME=home\。症状与原帖同型：双击无窗口、退出码 0x80000003、renderer launch-failed、在 %APPDATA%\@deepseek-ai\dsh-desktop 上 ACCESS_DENIED (0x5)。

1. 补充证据一：这不是"某次更新引入的"，标签早就落地了

• home\dsh-ops\acl-backups\362c0d7f-….json（mtime 2026-10-27 22:56）内容为 workspace: D:\DeepseekHarness、added: WRITE_OWNER (directory only)。即 10-27 就有 workspace-write 会话以该根跑过 prepare-workspace.ps1，早于 0.2.1-rc.5（10-30）与 11-03 那次自动更新。
• 交叉核对：dsh-v0.2.1-rc.2 与 dsh-v0.2.1-rc.5 的 packages/bundle/base/cordis.patch.yml 逐字节相同（均为 20932 B），两版 mode 默认值都是 workspace-write（:246）、workspaceRoot = process.cwd()（:247）。

⇒ "更新把默认预设改成 workspace-write 才崩"在源码上不成立；而"回退到旧版本仍然崩"正好与"标签早已常驻"一致。

2. 补充证据二：0.2.2-rc.1（当前最新）仍未修

按 dsh-v0.2.2-rc.1 tag 源码核验：

• packages/sandbox/sandbox-windows-acl/src/acl.ts:180-182：addMandatoryAce(..., SUB_CONTAINERS_AND_OBJECTS_INHERIT /* 0x3 = (OI)(CI) */, SYSTEM_MANDATORY_LABEL_NO_WRITE_UP, lowLabelSid) —— 标签天生带整树继承，安装树必然被覆盖。
• grant.ts:25：工作区路径按 STANDING 授予；README.zh.md:130-131 明确写"工作区 ACE、拒绝项与标签按设计常驻（复用缓存，绝不撤销）"、"手工 icacls 清理无法在本平台回收它们（ERROR_NONE_MAPPED 1332）"、标签生命期长于 DSH。
• 全仓未找到"安装目录 / DSH_HOME 落在 workspace 内就拒绝打标签"的守卫；0.2.2-rc.1 变更日志无对应条目；dsh-ops npm 最新版 0.4.4 也不做标签回收。

⇒ 这也解释了为什么重装无效、更换 DSH_HOME 无效：缺陷在目录级常驻元数据，不在文件里。

3. 补充证据三：被打标的一棵树会"次生不可修"

根目录同时被写入 Everyone:(CI)(DENY)(DC)（acl.ts:408：DENY_ACCESS + FILE_DELETE_CHILD + CONTAINER_INHERIT_ACE）。实测带继承标签的 Desktop\ 安装树无法就地 /setintegritylevel（拒绝访问），只能整目录搬走 + 重装，新目录才拿到干净 ACL。所以"重装、换数据目录"这类常识性自救会全部失败，且修复成本极高——原帖未覆盖这一点。

4. 现成的守卫可以照抄

path-boundary.ts:23 已经有 assertTempRootOutsideWorkspace()：当 temp 根落在 workspace 内时在任何授权之前直接抛错，注释给的理由正是 "every child created below it would inherit the standing workspace capability"。安装树与 DSH_HOME 属于同一类风险，只是没接进这条守卫。

最小补丁建议：在 AclWriteGrant.add() 之前，用同一个 containsDirectory() 校验 workspace 根是否包含 process.execPath 所在目录、DSH_HOME、%APPDATA%\@deepseek-ai；命中则 fail-closed 并输出可诊断错误（或退化为 read-only + 明确提示），而不是照常打标签。

5. 我们这边的规避（有效，但不是修复）

把 profile 的 permission.defaultPreset 改为 danger-full-access（对不信任目录用 read-only）→ 不再触发 prepare-workspace 与标签写入；再用管理员 icacls <树> /setintegritylevel "(OI)(CI)Medium" /t 恢复标签。这样不会被写回 Low，但代价是放弃沙箱。

6. 复核命令

# 标签：根 / 安装树 / exe
icacls D:\DeepseekHarness
icacls "D:\DeepseekHarness\Desktop\DeepSeek Harness.exe"

# 预检收据：证明"何时、以哪个根"跑过预检
Get-ChildItem D:\DeepseekHarness\home\dsh-ops\acl-backups\*.json |
  ForEach-Object { (Get-Content $_ -Raw | ConvertFrom-Json).workspace }

---

English TL;DR — Independent reproduction (different user, different machine): same layout — install tree and DSH_HOME nested under the workspace root — produces renderer launch-failed, exit 0x80000003, and ACCESS_DENIED (0x5) on %APPDATA%\@deepseek-ai\dsh-desktop. Two additions to the original report: (a) a prepare-workspace receipt dated 2026-10-27 shows the standing edits predate the 0.2.1-rc.5 update, and base/cordis.patch.yml is byte-identical between rc.2 and rc.5, so the version bump is not the trigger; (b) 0.2.2-rc.1 is still affected — acl.ts:180 writes the Low label with SUB_CONTAINERS_AND_OBJECTS_INHERIT, workspace grants stay STANDING forever (README.zh.md:130), and there is no guard for an install dir or DSH_HOME inside the workspace root. Minimal fix: reuse assertTempRootOutsideWorkspace (path-boundary.ts:23) to fail closed when the workspace root contains the install dir or DSH_HOME.

[5777-wq]

复发记录（2026-11-11 晚，0.2.2-rc.1/rc.2 均在场）

1. 标签回归：根目录 Mandatory Label\Low (OI)(CI)(NW) 再次出现——尽管 11-04 已把根重置 Medium 并换装全新安装树。与帖内「STANDING 常驻、复用缓存、绝不撤销」一致：期间多次成功启动（host start() 完成、但 welcome 阶段失败的运行也算）后标签即回归，Desktop\ 下新建文件全部继承 Low。

2. 新症状变体，比 0x80000003 更难诊断：把官方安装包重装进已被 Low 污染的树后，双击零痕迹秒死——无 crash-*.log、无 WER 1000/1001、不写 userData。做了单变量对照：同一 rc.2、同一插件集，仅「文件完整性标签 Medium vs Low」不同 → Low 秒死、Medium 正常。建议启动早期对 process.execPath 所在树做标签自检，命中 Low 时输出可见诊断（当前是纯静默退出）。

3. 自救成本实测更新：icacls /setintegritylevel 根目录可行，子项全部拒绝访问；/reset /t 只重置 DACL、不动 SACL。可行解（无需管理员）：带毒目录整体 mv 改名挪走 → 原地新建空目录（自动继承已为 Medium 的根）→ 官方安装包重装 → 新文件继承 Medium。比原帖的「搬树+管理员改安全元数据」成本更低，但仍是整树重装。

4. 安装器两个副作用顺带记录：每次安装会覆盖 resources\app-update.yml（自定义 feed 屏蔽会被抹掉）；并且会在 updaterCacheDirName 落一份 installer.exe——缓存里留有旧版安装包时，下次启动会被应用，出现「装好的新版本被旧包覆盖回去」的循环，装机后建议清掉该缓存。