本文章由deepseek-v4.1 Flash1017生成。## 1. 事故是怎么开始的时间线2026-10-26 ~ 10-28Windows 11 25H2| 时间 | 事件 ||---|---|| 10-26 18:20 | 首次异常沙箱模式下启动的命令行进程直接以 0xC0000142DLL 初始化失败退出切到“完全权限”后可正常执行 || 10-26 18:57 | 顺手清理了 F:\rjz\matlab\help3.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 个文件恢复 MediumPyCharm / 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 先排除系统级破坏powershellchkdsk F: /scan # 文件系统无问题0 坏扇区DISM /Online /Cleanup-Image /RestoreHealth # 退出码 0Get-PhysicalDisk | Get-StorageReliabilityCounter # 无读写错误Get-WinEvent -FilterHashtable {LogNameSystem; Id7,51,129,153} # 无磁盘错误### 3.2 排除“全局注入”类问题powershell# AppInit_DLLs 为空、LoadAppInit_DLLs0Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows# IFEO 无异常 DebuggerGet-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-WebpowershellGet-Item F:\rjz\FL_Studio\FL64.exe -Stream * # 只有 :$DATA没有 Zone.Identifier结论文件没有 MOTW 标记但 IInternetSecurityManager::MapUrlToZone 仍把这些文件判成 **zone 3Internet 区**powershell# 实测C:\Windows 下的文件 zone 0F:\rjz 下的 zone 3F:\rjz2 下的 zone 0### 3.4 最大的弯路把它当成“Internet 区域”问题在 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\ProtocolDefaults 里发现 file 3正常应为 0。改成 0 之后……**没有任何变化**重启也没用。后来又怀疑- 是不是 file3 的 32 位视图残留WOW6432Node 下确实也是 3- 是不是注册表权限被锁该键属于 TrustedInstaller管理员只读是否要为此调整系统键权限属于高风险操作本文不建议- 是不是目录 ACL 异常对 S-1-4-*** 这种陌生 SID 做了各种猜测全部否掉。**file3 只是“结果”的一种表现形式不是原因**——真正的判定输入是文件自带的完整性标签MapUrlToZone 只是把 Low 文件也归到 zone 3 而已。### 3.5 决定性实验同权限下PowerShell 能写、Java 不能这是整个排查的转折点。用“计划任务 Limited 令牌”模拟普通双击中完整性对同一个目录做写入测试textPowerShell 写 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 打印自己的令牌javaRuntime.getRuntime().exec(new String[]{whoami,/groups})输出textMandatory Label\Low Mandatory Level 标签 S-1-16-4096**Low 完整性**。而同权限的 PowerShell 是 Medium。谜底在这里。### 3.6 回头看文件标签就在那powershellicacls 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 行 Mediumicacls C:\Windows\System32\notepad.exe# 无 Mandatory Label 行 Medium(I) 表示继承(NW) 是 no-write-up。也就是说**标签打在 F:\rjz 上靠 (OI)(CI) 继承到整棵树**包括后来新建的文件。---## 4. 根因一行 SACL 如何让整台电脑“失灵”机制拆开是三步1. **写入**沙箱连接工作区时对工作区根目录写入一条可继承的 Low 完整性 ACES-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自己运行的一条命令递归把整棵树设回 Mediumpowershellicacls F:\rjz /setintegritylevel (OI)(CI)Medium /T /C /Q本次实际执行结果textSuccessfully processed 181594 files; Failed processing 0 files耗时 222 秒注意几个坑- **icacls /reset 没用**它只重建 DACL清不掉 SACL 里的标签。- **必须带 (OI)(CI) 和 /T**否则只改目录本身子项不跟随。- 大目录会跑几分钟属正常。---## 6. 验证texticacls F:\rjz\...\java.exe → Mandatory Label\Medium Mandatory Level:(I)(NW)icacls F:\rjz\FL_Studio\FL64.exe → MediumJava 写 5 个位置 → 全部 ✅ OKPyCharm普通权限 → ALIVEFL Studio普通权限 → ALIVEMapUrlToZone(FL64.exe) → zone 0修复前是 3---## 7. 收尾- 移除了之前为 FL Studio 临时加的“以管理员身份运行”兼容层HKCU\...\AppCompatFlags\Layers它本来也不需要。- 把 Internet 区域“加载应用程序和不安全文件”恢复为默认的“提示”。- 删除临时创建的 HKCU\...\ZoneMap\ProtocolDefaults。- 清理所有测试文件。---## 8. 为什么这个坑特别难查给后来人的路标1. **症状指向错误方向**所有程序都要管理员 → 直觉是 UAC/杀软/系统损坏。2. **权限检查全部“正常”**Get-Acl 显示当前用户 FullControlFile.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. **用沙箱后随手体检一句**powershellicacls 工作区 | Select-String Mandatory Label5. **出事后先备份/快照**再动权限类命令。---## 10. DeepSeek Messages transport failedDSH 模型请求反复失败的真实原因--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/30API 节点 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.ymlyaml- id: session-log-deepseekname: deepseek-ai/dsh-session-log-deepseekconfig:enabled: false # ← 真正的修复项- id: llm-deepseekname: deepseek-ai/dsh-llm-deepseek-api-keyconfig:retryPolicy:mode: normalmaxRetries: 12 # 默认 5backoff: { 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 的真实排查过程整理。文中路径、文件名、命令与输出均来自现场记录。*