[BUG] dsh桌面版下面无害命令(pwsh/cmd echo在内)都报错 0xC0000142(STATUS_DLL_INIT_FAILED)

[banxian]

Windows ACL 沙箱：桌面版下所有受限控制台命令都以 0xC0000142（STATUS_DLL_INIT_FAILED）退出

Summary

桌面版 Windows 上，windows-acl 沙箱（Windows 上唯一的沙箱后端）完全不可用：任何跑在它下面的命令都在真正执行之前就以 3221225794（0xC0000142，STATUS_DLL_INIT_FAILED）退出，且没有任何输出。cmd、PowerShell 7（pwsh）、Windows PowerShell 5.1、Python 一律如此，read-only 与 workspace-write 两种模式都一样；不受限的 danger-full-access 则一切正常，所以最初的表现像是"沙箱随机把 pwsh 干掉"——它和 pwsh 版本无关，也和解释器无关。文件类工具（read/write/edit/glob/grep）不受影响。我搜过讨论列表中有2起类似bug报告, 仓库也有看起来针对它的修复, 但更新到0.20rc1依然如此. 所以报告上来, 可能之前的fix覆盖不全.

受影响的代码（都在本仓库内）

包	路径	作用
@deepseek-ai/dsh-sandbox-local	packages/sandbox/sandbox-local	windowsAclRunnerInvocation() 用 process.execPath 托管 runner —— 一行修复就在此处
@deepseek-ai/dsh-sandbox-windows-acl	packages/sandbox/sandbox-windows-acl	其受限令牌无法创建控制台的后端；它的 README 里已经记录了由此产生的 STATUS_DLL_INIT_FAILED
@deepseek-ai/dsh-win32-process	packages/subprocess/win32-process	createRestrictedProcess() —— 所有受限子进程创建的唯一收口，可移植修复落在这里

并非 PowerShell 层的问题：@deepseek-ai/dsh-pwsh-sandbox（packages/shell/pwsh-sandbox）只是把这个失败报出来而已。受限的 cmd 和 python 死法完全一样，所以缺陷在 pwsh 接缝之下，pwsh 相关包不需要改动。

Reproduction

在桌面版应用内（用户可见的症状）：保持默认的 read-only 或 workspace-write 沙箱，让 agent 执行任意控制台命令——例如 pwsh -Command '"hi"'。每次都以 3221225794 失败且无输出；把同一条命令切到 danger-full-access 就立刻成功。0.17rc2和0.20rc1均有此现象.

最小复现（原版 Node + 随包发布的 runner，完全不需要 Electron）：

spawnSync(process.execPath, [runner, ...])，其中 runner 是 @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js：

// repro.mjs
// node repro.mjs <runner.js> <workspace> <tempRoot-existing-dir>
const { spawnSync } = require('node:child_process')
const [runner, workspace, tempRoot] = process.argv.slice(2)
const base = ['--workspace', workspace, '--temp', tempRoot, '--mode', 'workspace-write', '--', 'cmd', '/c', 'exit']

const show = (label, r) => console.log(label, r.status, '0x' + (r.status >>> 0).toString(16).toUpperCase())

show('attached:', spawnSync(process.execPath, [runner, ...base], { stdio: ['ignore', 'pipe', 'pipe'] }))
show('detached:', spawnSync(process.execPath, [runner, ...base], { stdio: ['ignore', 'pipe', 'pipe'], detached: true }))

实测输出：

attached: 0     0x0
detached: 3221225794  0xC0000142

detached: true（DETACHED_PROCESS）在这里并不是什么偏门配置——它恰恰是 GUI 子系统父进程免费提供的东西，而桌面版正是用 GUI 子系统二进制来托管 runner 的：

• dsh-sandbox-local/lib/index.js —— windowsAclRunnerInvocation() 返回 [process.execPath, builtEntry]；紧邻的注释还写着 "The prefix stays [node, runner, ...]"，也就是说这段代码默认 process.execPath 就是一个 Node 可执行文件。
• 桌面版里运行时跑在 Electron 主进程内，所以 process.execPath 是 Electron 二进制（…\DeepSeek Harness.exe）而不是 node.exe。而且同一个构建是故意把它当 Node 宿主用的：dsh-desktop-host 启动包管理器子进程时用的就是 command: process.execPath、env: { ELECTRON_RUN_AS_NODE: "1", DSH_DESKTOP_NODE_EXECUTABLE: process.execPath, … }。

于是 ACL runner 实际以 DeepSeek Harness.exe <runner.js> … 的身份运行 —— 一个永远不可能拥有控制台的 GUI 子系统进程。

Current behavior

任何受限控制台命令都返回 3221225794 / 0xC0000142，stdout 与 stderr 均为空。

runner 自身可以证明是活着的、也无责：给它一个不存在的 --temp，它照样会打印 windows-acl-run: --temp is not an existing directory: … 并以 127 退出 —— attached 和 detached 两种情况下都是如此。挂在那个受限孙进程上的是子进程，不是 runner 自己的启动。

同一个 runner、同一套 argv、同一个 workspace/temp、同一个令牌、同一台机器，只有宿主二进制 / spawn 标志在变：

runner 宿主	spawn 选项	受限 cmd /c exit	受限 pwsh -c exit	受限 GUI 子系统目标
node.exe	—	0	0	0
node.exe	windowsHide: true（CREATE_NO_WINDOW）	0	—	—
node.exe	detached: true（DETACHED_PROCESS）	0xC0000142	0xC0000142	0
DeepSeek Harness.exe（GUI 子系统）	以上任意一种	0xC0000142	0xC0000142	0

用到的 GUI 子系统目标是 DeepSeek Harness.exe -e "process.exit(0)"（各种配置下都退出 0）和 wscript.exe //B（退出 1 —— 一个真实的应用程序退出码，说明它初始化并跑完了）。

由此可以读出三条：

• 控制台子系统目标死，GUI 子系统目标没事。 故障发生在控制台的获取环节，而不是令牌或加载器本身。
• 自己拥有控制台的 runner（普通启动，或 CREATE_NO_WINDOW —— 后者仍会创建一个无窗口控制台）能把控制台传下去；没有控制台的 runner（DETACHED_PROCESS，或任何 GUI 子系统宿主）不能。
• 只改子进程的标志是不够的 —— 必须让 runner 手里有控制台可传。

这与该后端自己 README 里记录的已知限制一致（原文："console isolation is unavailable — children share the host console (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED)"）：在受限令牌下，任何控制台的创建都会失败，而桌面版恰好为每一条受限控制台命令都强制走了"创建控制台"这条路。README 那句"子进程共享宿主控制台"的假设，只在宿主确实有控制台时成立 —— GUI 子系统的 Electron 宿主永远没有。这一点已在内核层面确认（见附录 A）：失败时 conhost.exe 是被受限子进程自己创建出来的，带的是受限令牌，并以 STATUS_ACCESS_DENIED 结束。

Expected behavior

受限命令应当和不受限时一样正常执行并返回输出，只是多一层写限制。具体地说：

• cmd /c exit → 退出码 0
• pwsh -c "Write-Output …" → 退出码 0，文本出现在 stdout
• PowerShell 5.1、Python 以及其他任何控制台子系统目标同理
• 受限的 GUI 子系统目标保持现有行为（它们本来就能用）

附录 C 里的两个 runner 侧修复，都是在故障配置（无控制台 runner）下实测达到上述结果的，且不丢输出。

Environment

DSH	@deepseek-ai/dsh-desktop 0.2.0-rc.1（与 npm next 一致）
操作系统	Windows 10 21H2，build 19044.4529，运行于移动云电脑（China Mobile cloud desktop / Ecloud VDI）客户机内
命令目标	cmd.exe、pwsh 7.6.5、powershell 5.1、CPython
对比的宿主二进制	D:\Apps\Node22\node.exe v22.23.2 对比随包发行的 DeepSeek Harness.exe（Electron；其内嵌 Node 自报 v24.18.1，且 process.execPath 就是该二进制）
修复所用的 node.exe	%USERPROFILE%\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\node\bin\node.exe —— v24.21.0，本桌面版已经随包发行的运行时

除 Windows Defender 外没有第三方 AV/EDR。该客户机会向所有进程注入一个 VDI 钩子 DLL，但已排除（见附录 B）。

这是否只是某一台机器的问题？

应当不是。触发条件是桌面版给每一个安装都固定下来的属性 —— ACL runner 由 GUI 子系统二进制托管，而这种宿主永远不可能拥有控制台 —— 并且该机制与 VDI、注入的钩子 DLL、杀软、解释器统统无关（附录 B）。上面 detached: true 那条复现用的是原版 Node，不需要上述任何环境，所以机制本身在任何机器上都可复现；桌面版的症状也应当在该构建的任何 Windows 安装上复现。

但要说明：本文所有测量都是在移动云电脑（China Mobile cloud desktop / Ecloud VDI）客户机内完成的。如果桌面版症状在普通工作站上复现不出来，请到这类云电脑环境里再试 —— 那是本报告确认问题的环境 —— 同时始终保留 detached: true 那条 runner 用例，作为与机器无关的机制判据。

---

附录 A — 根本原因与内核级证据

Process Monitor抓取了桌面版发出的两组用例；两组里的受限目标都是同一个唯一命名的 cmd.exe 副本（dsh_conhost_probe.exe），因此这些事件不可能与系统噪音混淆。过滤器：Process Create / Process Exit。

用例 1 —— runner 由 node.exe 托管（runner 拥有控制台）：受限子进程退出码 0

12:36:44.8684867  node.exe (41512, the ACL runner)  Process Create  ...\dsh_conhost_probe.exe         PID: 43548
12:36:44.9049091  dsh_conhost_probe.exe (43548)     Process Exit    Exit Status: 0

整条链里没有出现任何 conhost.exe：受限子进程继承了 runner 已经拥有的那个控制台。

用例 2 —— 同一个 runner、同一套 argv，但以 DETACHED_PROCESS 启动（runner 没有控制台）：受限子进程死亡

12:36:49.3578601  node.exe (42368, the ACL runner)  Process Create  ...\dsh_conhost_probe.exe         PID: 3312
12:36:49.3678602  dsh_conhost_probe.exe (3312)      Process Create  C:\Windows\System32\Conhost.exe    PID: 39400
12:36:49.3682486  dsh_conhost_probe.exe (3312)      Process Exit    Exit Status: -1073741502  (0xC0000142 STATUS_DLL_INIT_FAILED)
12:36:49.3684230  Conhost.exe (39400)               Process Exit    Exit Status: -1073741790  (0xC0000022 STATUS_ACCESS_DENIED)

按顺序读下来，这就是整个缺陷：

1. 受限子进程没有可继承的控制台，于是它在自己的进程初始化阶段就申请一个控制台 —— 这也正是 conhost.exe 的 Process Create 事件归属于受限子进程自身的原因。
2. 因此这个控制台宿主是代表受限子进程、也就是带着受限令牌被创建的（低完整性、写受限），并在约 6 毫秒后以 STATUS_ACCESS_DENIED 死亡。
3. 它的客户端随后以 STATUS_DLL_INIT_FAILED 死亡 —— 也就是桌面版里每条受限命令看到的 0xC0000142。

所以这既不是令牌派生的问题，也不是加载器或目标自身 DLL 的问题：是控制台宿主在受限令牌下被拒绝，而桌面版把每一条受限控制台命令都送上了这条路。

同一次抓取里还有对照，可以排除"这台机器上控制台创建本身就是坏的"：harness 自己那条不受限的 pwsh.exe（由 dsh-subprocess-local 的 runner 拉起）用同样的方式申请控制台 ——

12:36:43.3143864  pwsh.exe (39544, unconfined)  Process Create  C:\Windows\System32\Conhost.exe  PID: 37508
12:36:51.5262558  Conhost.exe (37508)           Process Exit    Exit Status: 0

—— 而这个 conhost.exe 退出码是 0。控制台创建对不受限客户端成功、只对受限客户端被拒，这正是一个无法施加到控制台宿主上的写受限低完整性令牌会产生的结果。

抓取记录里还能看到生产环境的 spawn 模式本身，即桌面版确实是用 process.execPath（Electron 二进制）而不是 node 来托管 runner 的：

12:36:42.1341124  DeepSeek Harness.exe (15596)  Process Create  D:\Apps\DeepSeek Harness\DeepSeek Harness.exe   PID: 41252
      Command line: "…\DeepSeek Harness.exe" "…\app.asar\dsh\node_modules\@deepseek-ai\dsh-subprocess-local\lib\runner.js" -- "C:\Program Files\PowerShell\7\pwsh.exe" …
12:36:43.2582556  DeepSeek Harness.exe (41252)  Process Create  C:\Program Files\PowerShell\7\pwsh.exe

（这条是 dsh-subprocess-local 的 runner —— 不受限路径，所以上面那个 conhost.exe 才会成功；dsh-sandbox-local 构造它的 windows-acl 前缀时用的是同一套 process.execPath 写法。）

附录 B — 已排除的嫌疑项

下面这些在可用的（node.exe 宿主）和故障的（DeepSeek Harness.exe 宿主）两种配置下完全一致：

嫌疑项	测量	结论
进程缓解策略	对两个宿主 Get-ProcessMitigation -Id <pid>：无任何差异，全是默认值	排除
令牌	从两个宿主各自派生的子进程里执行 whoami /groups + /priv：完全一致（16 个组、相同 SID 含 S-1-2-0/S-1-2-1/S-1-5-11、Mandatory Label\High Mandatory Level、29 行特权），会话 1	排除
作业对象	两个宿主都报告 IsProcessInJob = true；两者 OpenInputDesktop 都成功（无 JOB_OBJECT_UILIMIT_DESKTOP）	排除
窗口站 / 桌面	两者都是 WinSta0 / Default	排除
环境变量	ELECTRON_RUN_AS_NODE 在两个宿主里都存在（而 node 宿主照样能用）	排除
windowsHide / CREATE_NO_WINDOW、无控制台 runner	见上面的矩阵 —— 各自单独都不足以成事	排除
目标路径解析	换成绝对路径的 pwsh.exe 失败方式相同；换 cmd、python 也相同	排除
目标解释器	cmd 与 pwsh 7、5.1 死法完全一样	排除
第三方 DLL 注入（VDI 钩子）	同样带着这些钩子 DLL 时，低完整性的 cmd.exe 副本运行正常；注入模块在成功的受限运行里同样存在	排除
runner 进程启动失败	传入坏的 --temp 时 runner 会打印自己的错误并以 127 退出，在 Electron 宿主下同样如此	排除
仅低完整性本身	低完整性标记的 cmd.exe 可以运行（LOWPROBE_OK，退出 0）	排除

时间线备注：本机是 Windows 10 19044，而沙箱代码注释里提到的是在 Windows 11 26200 上验证过。该缺陷并不限于任一版本 —— 用原版 Node 加 detached: true 就能复现 —— 但 Windows 10 用户看到的是桌面版的症状。

附录 C — 在故障环境中验证通过的修复方案

C.1 用真正的 node.exe 托管 ACL runner（推荐）

把 runner 宿主解析为一个真正的 Node 可执行文件，而不是 process.execPath。本桌面运行时已经随包带了一个（%USERPROFILE%\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\node\bin\node.exe）。配合生产环境本来就用的 windowsHide: true，控制台子系统的 node.exe 会得到一个属于自己的无窗口控制台，受限子进程再继承它。Node 版本无所谓：上面的矩阵用的是 v22.23.2，下表用的是随包的 v24.21.0 —— 两者都是控制台子系统二进制，都能用：

runner 宿主	windowsHide	结果
DeepSeek Harness.exe（生产）	false	0xC0000142
DeepSeek Harness.exe（生产）	true	0xC0000142
随包 node.exe	false	0，stdout FIX_OK
随包 node.exe	true（生产选项）	0，stdout FIX_OK

建议改动点：在 dsh-sandbox-local 的 windowsAclRunnerInvocation() 里解析宿主（例如 process.env.DSH_NODE / 随包运行时，回退到 process.execPath）。

C.2 让 runner 自己申请一个控制台（可移植兜底）

如果不想去定位 Node 可执行文件，同样的效果可以落在所有受限子进程创建的唯一收口上（dsh-win32-process 的 createRestrictedProcess）：runner 没有控制台时，在 spawn 之前先申请一个。四个绑定加一个辅助函数：

// bindingContext(): also koffi.load("user32.dll")
allocConsole:     bind(kernel32, "AllocConsole", "int", []),
getConsoleWindow: bind(kernel32, "GetConsoleWindow", PVOID, []),
setStdHandle:     bind(kernel32, "SetStdHandle", "int", ["int", PVOID]),
showWindow:       bind(user32, "ShowWindow", "int", [PVOID, "int"]),

function ensureRunnerConsole(api) {
  const saved = [-12, -11, -10].map((s) => [s, api.getStdHandle(s)]);
  if (api.allocConsole() === 0) return;              // a console already exists -> no-op
  for (const [s, h] of saved) api.setStdHandle(s, h);
  const w = api.getConsoleWindow();
  if (w !== null) api.showWindow(w, 0);
}
function createRestrictedProcess(api, options, commandLine, creationFlags, startupInfo, processInfo) {
  ensureRunnerConsole(api);
  return api.createProcessAsUserW(options.token, null, commandLine, null, null, 1, creationFlags, null, options.cwd, startupInfo, processInfo);
}

在无控制台的 runner（即故障条件）下实测，createRestrictedProcess 其余部分保持不变：

受限目标	修复前	加上 ensureRunnerConsole
cmd /c exit	0xC0000142	0
pwsh -c "Write-Output DETACH_FIX_OK"	0xC0000142	0，stdout "DETACH_FIX_OK\r\n"
cmd /c echo DETACH_CMD_OK	0xC0000142	0，stdout "DETACH_CMD_OK\r\n"
GUI 子系统目标	0	0
同一个 runner 本来就有控制台（对照）	0	0，行为不变 —— AllocConsole 返回 0，分支根本不会进入

这个变体输出保真，而且与宿主无关：不需要定位 node.exe，所以即便将来 runner 宿主因为别的原因改掉，它依然成立。需要权衡的地方：给 dsh-win32-process 增加了 user32 依赖和四个绑定；每个 runner 进程从此都持有一个控制台（一个 runner 一个控制台宿主）；窗口只能在 AllocConsole 返回之后才隐藏，因此理论上有一瞬闪现 —— 而控制台子系统的 node.exe 宿主靠现有的 windowsHide: true 就能免费拿到真正无窗口的控制台。首选 C.1，C.2 作为可移植兜底。

C.3 已实测并否决的方案：给受限子进程加 DETACHED_PROCESS

既然根因是"受限子进程去申请控制台"，那么子进程侧的修法就是让它以 DETACHED_PROCESS 创建、根本不申请。我们把它打进随包的 dsh-win32-process（子进程创建标志在管道路径上是 0，见 lib/index.js:458；在继承 Job 的路径上是 4/CREATE_SUSPENDED，见 lib/index.js:693），并在同一个无控制台 runner 下测量：

受限目标	未打补丁	打上 DETACHED_PROCESS
cmd /c exit	0xC0000142	0
pwsh -c "Write-Output …"	0xC0000142	0，但 stdout 与 stderr 都是 0 字节
cmd /c echo DETACH_CMD_OK	—	0，stdout "DETACH_CMD_OK\r\n"（完好）

这个补丁反过来确认了机制 —— 去掉控制台申请，崩溃就消失 —— 但不能当作修复方案：在 DETACHED_PROCESS 下，pwsh 7 会静默地完全不产出输出（不是改道到 stderr，是真的被丢弃），那等于把响亮的失败换成最要命的解释器上的哑失败。cmd.exe 的输出完好，说明这是解释器相关的行为。runner 侧的两个方案都保持输出完整 —— 受限 pwsh 的 stdout 被正常捕获为 FIX_OK —— 这才是推荐它们的原因。

附录 D — 建议的回归测试

detached: true 用原版 Node 加随包 runner 就能复现，所以现有的 Windows ACL 测试套件无需 Electron 就能覆盖它：

1. runner 正常托管，受限 cmd /c exit → 0
2. runner 以 detached: true 托管，受限 cmd /c exit → 目前是 0xC0000142；必须变成 0
3. runner 正常托管，对子进程强制 CREATE_NEW_CONSOLE，受限 cmd /c exit → 目前是 STATUS_DLL_INIT_FAILED（已在 README 记录）；等到受限令牌下的控制台创建被修好或绕开之后，应当变成 0

附录 E — 各项测量的取得方式

• 直接使用 runner 调用形式（不经 HLE 包装）：
  <host> <pkg>/lib/runner.js --workspace <ws> --temp <已存在的目录> --mode workspace-write -- <目标 argv>
  （agentless 形式：不带 --write-sid/--temp-write-sid；runner 会自建并清理自己的私有临时子目录。）
• 受限子进程的退出码取自 runner 的退出码 —— runner 会镜像子进程的退出码。
• 控制台状态是在每个宿主内部通过 koffi 调用 kernel32!GetConsoleWindow、GetStdHandle、AllocConsole 读出的。
• 令牌 / 作业 / 桌面相关信息取自各宿主派生的子进程（作业、窗口站与桌面都会被继承，因此子进程报告的就是宿主的值）。

[argszero]

Thanks — this is the sharpest report in this family so far, and not because of the proposed fix. Two things make it worth more than its predecessors: it supplies a reproduction that needs no desktop (detached: true against a stock node.exe), and its own control columns refute a cause this family has been carrying in published advice. We maintain @argszero/cordis-plugin-sandbox-grant-advisor, the plugin that speaks for this exit code (it reads it from the shell projection's exitCode, because the pipeline records a confined death under isError: false and a diagnostics plugin that reads error results is structurally blind to it). So we re-verified your citations against source and shipped the correction.

Your four code citations verify, verbatim

1. packages/sandbox/sandbox-local/src/index.ts — windowsAclRunnerInvocation() returns [process.execPath, builtEntry], and the doc comment above it really does say "The prefix stays [node, runner, ...]".
2. packages/sandbox/sandbox-windows-acl/README.md:119 — "Console isolation is unavailable — children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED … children share the host console".
3. packages/subprocess/win32-process/src/process.ts — createRestrictedProcess at :176 is the single funnel, and the flag sets are exactly the three you describe: the piped path passes 0 (:243), the inherited-job path CREATE_SUSPENDED (:542), the ordinary path CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT (:567). CREATE_NO_WINDOW is not a constant anywhere in that source.
4. apps/desktop-host/src/index.ts:31-39 — command: process.execPath with env: { ELECTRON_RUN_AS_NODE: '1', DSH_DESKTOP_NODE_EXECUTABLE: process.execPath, … }.

What your report disproves in our own published text

0.6.0 through 0.7.1 told the reader the desktop producer was one of two measurements: (a) a runner that never started, because the Electron binary "begins as an application unless the child's environment carries ELECTRON_RUN_AS_NODE=1, so nothing on the runner path ran"; or (b) a runner that did start and whose child "does not survive the restricted token derived from the Electron process image".

Your appendix B measures that variable present in both hosts — including the one that works — and your production trace shows the runner running. Your token comparison (whoami /groups + /priv identical between the children of a working node.exe host and of the failing Electron host, plus a low-integrity cmd.exe that runs fine) is a direct refutation of (b). We then confirmed at source that (a) is impossible in this build: the desktop starts its harness host child through desktopNodeEnvironment(), which sets ELECTRON_RUN_AS_NODE: '1' (apps/desktop/src/node-environment.ts:15, called from apps/desktop/src/host-process.ts:199).

Both statements were wrong, so 0.8.0 retracts them by name rather than silently rewriting them — a cause we shipped twice earns its sentence when it is withdrawn. Test arms now fail if either sentence comes back.

The mechanism we now ship

The three-line trace from your appendix A is what we adopted: conhost.exe is created by the restricted child, exits 0xC0000022 STATUS_ACCESS_DENIED, and the child then dies with 0xC0000142. The invariant we state is yours: in a restricted token a console can be inherited but not created.

The single strongest piece of evidence in the report is the control you drew yourself in that same capture — under the same GUI-subsystem host, the harness's own unrestricted pwsh.exe allocated a console and that conhost.exe exited 0. Two rows, one variable, and the whole story: an unrestricted client may create a console, a restricted one may not. That is also why the confined path is the only one that breaks under a console-less host, which the token story never explained.

Plugin: 0.8.0

@argszero/cordis-plugin-sandbox-grant-advisor@0.8.0 — npm · repo · commit ef1406a. It mounts into a dsh profile (dsh.bundle.patch), needs no configuration, and attaches a user-role notice to the tool result whose value.exitCode is this status. It never blocks the call and never edits an environment.

The advisory now:

• names the console mechanism, and marks the token explicitly as not the discriminator;
• carries both console-less shapes — (a) GUI-subsystem host image, (b) DETACHED_PROCESS runner under a real node host — with your spawnSync(node, [runner, …], { detached: true }) arm labelled as the check worth running here, because it needs no desktop and no particular machine;
• leads the Electron branch with a real node host (both shipped paths: resources/runtime/primary-runtime/dependencies/node/bin/node.exe, and %USERPROFILE%\.dsh\dsh-runtimes\dsh-primary-runtime\dependencies\node\bin\node.exe) with the condition attached — the runner must be spawned with a console, i.e. not with DETACHED_PROCESS, since your first matrix row shows a real host is not sufficient on its own;
• offers your C.2 shape (AllocConsole + restore the three standard handles, in createRestrictedProcess) as the host-independent fallback, with the cost you named: a user32 binding and one console host per runner process;
• names your C.3 as a non-remedy, with both halves of its measurement (crash gone; pwsh exits 0 with zero bytes on stdout and stderr; cmd.exe intact) — refusing advice like that is the whole reason this plugin exists;
• keeps danger-full-access as a way to confirm the diagnosis and not as a fix, and keeps the #8174 interaction warning.

Evidence for the release: 82/82 suite arms; 28 injected defects, 27 caught / 1 equivalent / 0 silent, none skipped; all five peer-range lines install, build and pass. Your report also caught a factual error of our own that C.3 implies: we had written the flag list as two sets and omitted 0 on the piped path — which is the path a shell call actually takes. Corrected to all three.

Two notes on the fixes as written

• C.1 needs its condition stated as loudly as its host. Your own matrix has the row that matters: node.exe host + detached: true ⇒ 0xC0000142. So the fix is "console-subsystem host and no DETACHED_PROCESS on that spawn" — a rule that keeps holding if the host changes, whereas "use a real node host" alone would silently regress the day someone adds a detached spawn.
• Nothing in this claims the sandbox caused the death. 0xC0000142 also arises from a program that cannot load one of its own DLLs; the plugin says so, and it still does.

Fourth report of this code, after #7876, #7877 and #8193 — and the first one whose measurements corrected us rather than just adding a case.