本文章由deepseek-v4.1 Flash1017生成。
## 1. 事故是怎么开始的
时间线（2026-10-26 ~ 10-28，Windows 11 25H2）：
| 时间 | 事件 |
|---|---|
| 10-26 18:20 | 首次异常：沙箱模式下启动的命令行进程直接以 `0xC0000142`（DLL 初始化失败）退出；切到“完全权限”后可正常执行 |
| 10-26 18:57 | 顺手清理了 `F:\rjz\matlab\help`（3.34 GB 文档），与本次事故无关，但后来成了“嫌疑人” |
| 10-26 晚 | 关闭 DSH 后，DSH 再也打不开；FL Studio 双击崩溃；代理软件、PyCharm、万达云陆续“需要管理员” |
| 10-27 白天 | 用户尝试自救：装 Windows 更新（25H2）、查杀毒、重装 VC++、装 Windows SDK、装 Node.js、反复重启 |
| 10-27 晚 | 开始系统排查（本文第 3 节），最后定位到完整性标签 |
| 10-27 19:53–22:30 | 另一条会话线排查 `DeepSeek Messages transport failed`，最终锁定 `session-log-deepseek` 插件 |
| 10-27 23:26 | 修复完成：181,594 个文件恢复 Medium，PyCharm / FL Studio 普通权限直接启动 |
关键点：**触发动作发生在 10-26 的那次沙箱会话**——工作区被设成了 `F:\rjz`，而那是用户的“程序目录”，里面装着 PyCharm、FL Studio、万达云、DSH 本体等一堆可执行文件。
---
## 2. 现象：一套完全不讲道理的“组合拳”
同一个根因，表现成至少八种毫不相干的样子：
| 场景 | 表现 |
|---|---|
| 工作区里的 exe | 双击弹「打开文件 - 安全警告：无法验证发布者。你确定要运行此软件吗？」，或「来自 Internet 的文件可能对你有所帮助，但此文件类型可能危害你的计算机。你想要运行此文件吗？」 |
| PyCharm | 双击无反应，进程退出码 3，日志里 `AccessDeniedException: ...\JetBrains\PyCharmCE2022.3\port.lock` |
| FL Studio | 双击崩溃，事件日志 `0xC0000005`，故障模块 `ntdll.dll`；右键“以管理员身份运行”却正常 |
| DSH 自己 | 启动即退出，崩溃日志只有一句 `Desktop renderer exited: launch-failed` |
| 网络代理软件 / 万达云 | 必须管理员才能启动 |
| 浏览器类程序 | 普通权限各种异常，管理员正常 |
| 文件属性 | 权限看起来完全正常（ACL 里当前用户有 FullControl），也能读写 |
| 系统层面 | `chkdsk` 无错误、`DISM` 无损坏、磁盘 SMART 正常、无病毒告警 |
最误导人的一点：**右键“以管理员身份运行”几乎都能打开**。这让人本能地往“UAC / 权限 / 杀毒软件拦截”方向查，而那全是错的方向。
---
## 3. 排查：走过的弯路（这才是本文的重点）
### 3.1 先排除系统级破坏
```powershell
chkdsk F: /scan # 文件系统无问题，0 坏扇区
DISM /Online /Cleanup-Image /RestoreHealth # 退出码 0
Get-PhysicalDisk | Get-StorageReliabilityCounter # 无读写错误
Get-WinEvent -FilterHashtable @{LogName='System'; Id=7,51,129,153} # 无磁盘错误
```
### 3.2 排除“全局注入”类问题
```powershell
# AppInit_DLLs 为空、LoadAppInit_DLLs=0
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows'
# IFEO 无异常 Debugger
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options'
# 无 WDAC/AppLocker 拦截、Smart App Control 关闭、SmartScreen 关闭
# PATH 里没有被劫持的 system32 DLL
```
### 3.3 排除 Mark-of-the-Web
```powershell
Get-Item 'F:\rjz\FL_Studio\FL64.exe' -Stream * # 只有 :$DATA，没有 Zone.Identifier
```
结论：文件没有 MOTW 标记，但 `IInternetSecurityManager::MapUrlToZone` 仍把这些文件判成 **zone 3（Internet 区）**：
```powershell
# 实测：C:\Windows 下的文件 = zone 0，F:\rjz 下的 = zone 3，F:\rjz2 下的 = zone 0
```
### 3.4 最大的弯路：把它当成“Internet 区域”问题
在 `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults` 里发现 `file = 3`（正常应为 0）。改成 0 之后……**没有任何变化**，重启也没用。
后来又怀疑：
- 是不是 `file=3` 的 32 位视图残留？（`WOW6432Node` 下确实也是 3）
- 是不是注册表权限被锁？（该键属于 `TrustedInstaller`，管理员只读；是否要为此调整系统键权限属于高风险操作，本文不建议）
- 是不是目录 ACL 异常？（对 `S-1-4-***` 这种陌生 SID 做了各种猜测）
全部否掉。**`file=3` 只是“结果”的一种表现形式，不是原因**——真正的判定输入是文件自带的完整性标签，`MapUrlToZone` 只是把 Low 文件也归到 zone 3 而已。
### 3.5 决定性实验：同权限下，PowerShell 能写、Java 不能
这是整个排查的转折点。用“计划任务 + Limited 令牌”模拟普通双击（中完整性），对同一个目录做写入测试：
```text
PowerShell 写 C:\Users\...\AppData\Roaming\JetBrains\PyCharmCE2022.3\_probe.txt → ✅ 成功
jbr\bin\java.exe 写同一目录 _javatest.txt → ❌ AccessDeniedException
```
进一步让 Java 写 5 个位置：
```text
%TEMP% ❌ AccessDeniedException
%USERPROFILE% ❌
%LOCALAPPDATA% ❌
%APPDATA% ❌
%APPDATA%\JetBrains ❌
```
**Java 连 `%TEMP%` 都写不了**——这就不可能是目录 ACL 或某个软件拦截了，只能是**进程本身没有权限**。
于是让 Java 打印自己的令牌：
```java
Runtime.getRuntime().exec(new String[]{"whoami","/groups"})
```
输出：
```text
Mandatory Label\Low Mandatory Level 标签 S-1-16-4096
```
**Low 完整性**。而同权限的 PowerShell 是 Medium。谜底在这里。
### 3.6 回头看文件：标签就在那
```powershell
icacls "F:\rjz\PyCharm\<版本>\jbr\bin\java.exe"
# Mandatory Label\Low Mandatory Level:(I)(NW)
icacls "F:\rjz\FL_Studio\FL64.exe"
# Mandatory Label\Low Mandatory Level:(I)(NW)
icacls "F:\rjz2\t.txt"
# （无 Mandatory Label 行 = Medium）
icacls "C:\Windows\System32\notepad.exe"
# （无 Mandatory Label 行 = Medium）
```
`(I)` 表示继承，`(NW)` 是 no-write-up。也就是说：**标签打在 `F:\rjz` 上，靠 `(OI)(CI)` 继承到整棵树**，包括后来新建的文件。
---
## 4. 根因：一行 SACL 如何让整台电脑“失灵”
机制拆开是三步：
1. **写入**：沙箱连接工作区时，对工作区根目录写入一条可继承的 Low 完整性 ACE（`S-1-16-4096`，带 `SUB_CONTAINERS_AND_OBJECTS_INHERIT` 和 `NO_WRITE_UP`）。
2. **继承**：`(OI)(CI)` 让它传播到所有子目录和文件；新建文件同样继承。
3. **生效**：Windows 启动进程时，**用镜像文件（exe）上的标签决定进程完整性级别**。从 Low 文件启动 → 进程 Low → 不能写 Medium 对象：
- 写 `%TEMP%` / `%APPDATA%` → `AccessDenied`
- 创建 `\BaseNamedObjects` 命名对象 → 失败（Electron/Chromium 的 IPC 依赖它）
- `IInternetSecurityManager::MapUrlToZone` → 判成 zone 3 → “无法验证发布者”弹窗
- 全局钩子、跨进程拖放、`WH_KEYBOARD_LL` 等按完整性分级的功能全部降级
这也解释了为什么“以管理员身份运行”能绕过：High 令牌不受 no-write-up 限制。
还有一个坑：**切回“完全权限”、删掉工作区、甚至重启 DSH，都不会撤销这个标签**。它在磁盘上，属于跨会话的持久修改。
---
## 5. 修复
（哦对了，这个是我的dsh自己运行的）
一条命令，递归把整棵树设回 Medium：
```powershell
icacls "F:\rjz" /setintegritylevel (OI)(CI)Medium /T /C /Q
```
本次实际执行结果：
```text
Successfully processed 181594 files; Failed processing 0 files
耗时 222 秒
```
注意几个坑：
- **`icacls /reset` 没用**：它只重建 DACL，清不掉 SACL 里的标签。
- **必须带 `(OI)(CI)` 和 `/T`**：否则只改目录本身，子项不跟随。
- 大目录会跑几分钟，属正常。
---
## 6. 验证
```text
icacls "F:\rjz\...\java.exe" → Mandatory Label\Medium Mandatory Level:(I)(NW)
icacls "F:\rjz\FL_Studio\FL64.exe" → Medium
Java 写 5 个位置 → 全部 ✅ OK
PyCharm（普通权限） → ALIVE
FL Studio（普通权限） → ALIVE
MapUrlToZone(FL64.exe) → zone 0（修复前是 3）
```
---
## 7. 收尾
- 移除了之前为 FL Studio 临时加的“以管理员身份运行”兼容层（`HKCU\...\AppCompatFlags\Layers`），它本来也不需要。
- 把 Internet 区域“加载应用程序和不安全文件”恢复为默认的“提示”。
- 删除临时创建的 `HKCU\...\ZoneMap\ProtocolDefaults`。
- 清理所有测试文件。
---
## 8. 为什么这个坑特别难查（给后来人的路标）
1. **症状指向错误方向**：所有程序都要管理员 → 直觉是 UAC/杀软/系统损坏。
2. **权限检查全部“正常”**：`Get-Acl` 显示当前用户 FullControl，`File.Exists` 为真，读也没问题。
3. **报错千奇百怪**：`0xC0000142`、`0xC0000005`、`0x80000003`、退出码 3、`AccessDeniedException`、“无法验证发布者”……其实是同一个原因。
4. **重启、切权限、重装软件都无效**：因为改的是磁盘上的 SACL，不是运行时状态。
5. **唯一有效的入口**：`icacls "<路径>"` 输出里有没有 `Mandatory Label` 这一行。
---
## 9. 预防
1. **别把程序安装目录、用户主目录、盘符根目录当工作区**。给沙箱工具一个专用目录（例如 `F:\dshWork`），把需要“可信”的目录排除在外。
2. **别把 DSH 自己的安装目录当工作区**：标签落到 `DeepSeek Harness.exe` 上，应用自己就起不来。
3. **构建产物移出工作区**（`CARGO_TARGET_DIR`、`outDir`、虚拟环境目录等），否则产物继承 Low，拿到外面跑也起不来。
4. **用沙箱后，随手体检一句**：
```powershell
icacls "<工作区>" | Select-String "Mandatory Label"
```
5. **出事后先备份/快照**，再动权限类命令。
---
## 10. DeepSeek Messages transport failed：DSH 模型请求反复失败的真实原因
`--no-sandbox` 让 DSH 能打开了，但紧接着出现另一个问题：**每条消息都反复失败，提示 `DeepSeek Messages transport failed`**。这一个问题单独耗掉了将近 3 小时（19:53–22:30），值得单列一节。
### 10.1 症状
会话事件里能直接看到失败原因：
```json
{"type":"assistant/attempt","data":{"stream":[{"chunk":{"type":"finish",
"reason":{"kind":"error","failure":{"message":"DeepSeek Messages transport failed","code":"TRANSPORT"}}}}]}}
```
表现是：几乎每个 step 都要重试，重试有时 1–2 秒就失败，有时要等 13–40 秒；同一个会话里前后累计 76 次失败。
### 10.2 逐个排除
| 怀疑对象 | 实测 | 结论 |
|---|---|---|
| 网络链路 | 网卡错误 0；网关 ping 30/30；API 节点 30/30、23.7ms | 排除 |
| DNS 污染/轮换 | 200 次解析全部同一地址，连通 29ms | 排除 |
| 连接池空闲失效 | 同连接「请求→空闲 75s→复用」×4 轮，8/8 成功 | 排除 |
| 代理/环境变量 | 无代理变量，WinHTTP/WinINET 直连 | 排除 |
| **请求体里的会话日志载荷** | 关闭后失败归零 | **根因** |
排查的起点其实是网页版给的三条方向：代理配置（`NODE_USE_ENV_PROXY`）、冲突插件（点名 `dshmarket`）、损坏的会话/附件。三条全部试过，均无效——这才有了上面这张逐项排除表。
### 10.3 真凶：`session-log-deepseek` 插件
这个插件会把**尚未被服务端确认的整段会话事件**塞进**每一个**请求体（`dsh_session_log` 字段，上限 8 MiB）。而当时的轮次里全是几万字的工具输出，于是每个 step 的首个请求都带着不断膨胀的载荷发出去，被上游直接掐断 → `TRANSPORT`。
两个反直觉的细节解释了失败耗时的差异：
- 服务端其实已经收下并推进了水位，**重试时载荷归零**，请求体骤减，于是立刻成功；
- 超大载荷表现为 13–40 秒的上传超时，临界大小则表现为秒级 RST。
### 10.4 修复（热生效，无需重启）
`C:\Users\<用户名>\.dsh\profiles\desktop\cordis.patch.yml`：
```yaml
- id: session-log-deepseek
name: "@deepseek-ai/dsh-session-log-deepseek"
config:
enabled: false # ← 真正的修复项
- id: llm-deepseek
name: "@deepseek-ai/dsh-llm-deepseek-api-key"
config:
retryPolicy:
mode: normal
maxRetries: 12 # 默认 5
backoff: { initialDelayMs: 150, maxDelayMs: 3000, jitterRatio: 0.1 }
```
原文件备份为 `cordis.patch.yml.bak-20261027-2145`。想恢复会话日志功能，把 `enabled` 改回 `true` 即可——但按现有证据，那会重新引入故障。
### 10.5 效果
```text
修复前：76 次失败，几乎每个 step 一次
修复后：13 个 step、14 条消息、0 次失败
旁证：delivery-accepted 事件降为 0，确认插件确实被关掉了
```
---
## 11. 平行线：网页版那条“差点重装系统”的路
在 DSH 打不开的那两天，还有一条独立的排查线（和网页版对话完成的）。回头看，这条线几乎集齐了所有“看起来像证据、其实是噪音”的东西，最后差点导向重装系统。
### 11.1 被当成真凶的三类“证据”
| 现象 | 当时的判断 | 实际 |
|---|---|---|
| `RegOpenKey` 对 `HKLM\SYSTEM\CurrentControlSet\Services\WinSock2` 报 `ACCESS DENIED` | 系统权限被破坏，要夺回注册表所有权 | 该键本来就有系统级保护，ProcMon 里出现拒绝访问是常见噪音 |
| `QuerySecurityFile` 对 `C:\Windows\System32\msvcp_win.dll` 报 `BUFFER OVERFLOW` | 系统 DLL 损坏 | ProcMon 的已知噪音，与故障无关 |
| 大量 `NAME NOT FOUND` | 文件被删 | 加载器按路径逐个试探的正常过程 |
于是这条线一路走到了：用 PsExec 以 SYSTEM 运行 regedit、用 AdvancedRun 以 TrustedInstaller 身份夺权、勾选“替换子对象权限”……再往后就是“重置此电脑（保留我的文件）”“用 Windows 更新修复问题”“ISO 覆盖安装能不能保留软件注册表”。
### 11.2 两个被忽略的正确线索
1. **“我并没有看到『解除锁定』复选框”** —— 文件属性里没有“解除锁定”，说明它**没有 Mark-of-the-Web**。这恰好排除了“从网上下载被标记”的方向。当时没人顺着这条线走。
2. **“安全里多了一个未知账户”** —— 那其实是 SACL 里的 `S-1-4-***` 条目（完整性标签相关），不是被入侵。它已经非常接近真相，但被当成了“中毒/被改”的证据。
### 11.3 转折点
网页版从 GitHub 讨论（#332）里搜到 `--no-sandbox`（对应 GPU 子进程 `0x80000003` 崩溃），建议加到快捷方式里。用户试了，**DSH 终于能打开**。
**这一步的真正意义**：它把“系统权限被拦截”和“应用自身启动失败”切成了两件事。虽然当时还不知道根因是磁盘上的完整性标签，但至少不再往“重装系统”走了。
### 11.4 紧接着的第二个误判
`--no-sandbox` 之后遇到 `DeepSeek Messages transport failed`，网页版给的方向是：**代理配置（`NODE_USE_ENV_PROXY`）→ 冲突插件（还点名了 `dshmarket`）→ 损坏的会话/附件**。这三条全部试过，全都没有效果。
真正的原因在第 10 节：`session-log-deepseek` 把整段未确认会话塞进请求体。**两个问题在时间上紧挨着、现象都像“DSH 坏了”，但根因毫无关系**——这是整场事故里最容易把人带偏的地方。
---
## 12. 两个常见疑问（修订版）
**Q1：`--no-sandbox` 为什么能救 DSH？**
Chromium 的沙箱需要在低权限下创建窗口站、命名对象和子进程；Low 令牌下这些操作被拒，渲染进程创建失败（`render-process-gone: launch-failed`）。`--no-sandbox` 跳过这套机制，所以能启动——但这是**绕路**。标签修好后，理论上不再需要这个参数。
**Q2：被禁用的 DSH 插件，是不是受了无妄之灾？**
**要分两个插件看，结论相反：**
| 插件 | 是否被冤枉 | 说明 |
|---|---|---|
| `dsh-win32` | **是，被冤枉** | 它是环境诊断/修复类插件，被当成“启动失败嫌疑人”清理掉了。真正原因是 Low 完整性标签，与它无关。 |
| `session-log-deepseek` | **否，确实是元凶** | 它把未确认会话事件塞进请求体导致 `TRANSPORT`，禁用后失败归零。它不是“坏插件”，但在这个场景下确实该关。 |
所以准确的说法是：**启动失败这条线里，插件是被冤枉的；消息传输失败这条线里，插件是真凶。** 两件事时间上挨着、现象都像“DSH 坏了”，但根因完全无关——这也是这次事故最容易被误判的地方。
---
## 参考
- [DeepSeek Harness Low integrity label: white icons, crashes](https://dsh-plugin.org/tutorials/fix-windows-sandbox-low-integrity-label)
- GitHub Discussions（同一根因的多个报告）：
- [#9819](https://github.com/deepseek-ai/deepseek-harness/discussions/9819)（机制与命令）
- [#9569](https://github.com/deepseek-ai/deepseek-harness/discussions/9569)（主目录被标签 → 快捷方式图标空白）
- [#9560](https://github.com/deepseek-ai/deepseek-harness/discussions/9560)（安装目录被标签 → DSH 自己起不来）
- [#9062](https://github.com/deepseek-ai/deepseek-harness/discussions/9062) / [#9666](https://github.com/deepseek-ai/deepseek-harness/discussions/9666)（Electron 崩溃）
- [#9314](https://github.com/deepseek-ai/deepseek-harness/discussions/9314)（构建产物继承标签）
- [#9416](https://github.com/deepseek-ai/deepseek-harness/discussions/9416) / [#9559](https://github.com/deepseek-ai/deepseek-harness/discussions/9559)（旧子目录不可写）
---
*本文基于 2026-10-26 至 10-28 的真实排查过程整理。文中路径、文件名、命令与输出均来自现场记录。*
