Windows sandbox troubleshooting index: routing workspace-write failures beyond 0xC0000142

[Bruce-Yii]

Several Windows sandbox reports currently collapse into the same top-level symptom — workspace-write fails, shell tools stop working, or a child exits with 0xC0000142 / STATUS_DLL_INIT_FAILED. After comparing the reports, those are not safe to treat as one bug.

This post is meant to be a routing/index thread, not a new root-cause claim. #8485 already surfaced the need for an overview because individual reports were becoming hard to relate without re-reading the whole history.

Start here: where does the failure happen?

Check	If yes	Start with
The command never starts and DSH reports SetNamedSecurityInfoW failed (Win32 5): grantWrite(...)	ACL provisioning / workspace permission path	#7504, #7816, #8409
The child is created but exits with 0xC0000142 and no output	Process-startup path; do not assume one cause	Continue below
A console-attached spawn works, but windowsHide / CREATE_NO_WINDOW-style paths fail	creation-flag / console allocation path	#6930, #7292
Packaged Desktop / GUI-host / ConPTY path fails while a console-subsystem host or CLI control works	host/console ownership path	#810, #8142, #8322, #8485, #8721
read-only works, workspace-write fails, and A/B testing points at the restricted token's default DACL / capability SID	token Default-DACL path	#8534, #8599, #8775; compare the platform-specific counter-results in #8721
Direct execution works, but a confined child spawning another process with piped stdio fails	descendant / stdio path	#6714 and the current sandbox-windows-acl documented boundary
The failure involves MSYS-style named objects / private IPC rather than workspace ACL provisioning	keep it separate from the console/DACL buckets	#8485
The sandbox reports SANDBOX_UNAVAILABLE and every later command in the session fails on the same private temp path that was deleted. It clears only when the provider / DSH restarts	cached private-temp capability is never re-validated	#6483, #6801
The runner says --temp is not an existing directory although the directory exists and was created moments earlier	temp directory exists but the creating user can no longer access it	#2287
The command never starts at all — DSH reports Windows ACL temp root must be outside the workspace, even for echo. A restart does not change the condition	pre-spawn temp / workspace containment invariant	#9175
Commands run, but an existing subdirectory of the workspace stays unwritable while newly created folders work	Low integrity label did not reach that subdirectory	#8383, #8560, #7875
Commands run, but real files outside the intended scope are modified — white .lnk icons, Internet-zone prompts, a broken install directory	standing Low-integrity label side effects, with no revoke path	#8665, #8453, #8312, #8048
The runner never starts at all — --profile <name> is required, duplicate native types, or NULL std handles	runner startup contract (SEA / Electron host / duplicate copies)	#5809, #7876, #7578, #8158
HTTPS fails inside the sandbox with SEC_E_NO_CREDENTIALS while Node/Python work	credential acquisition under the restricted token	#3207, #4163, #2850
The first command on a large workspace freezes the whole server for minutes	eager ACE propagation during the first provisioning	#3434, #2774

A switch to danger-full-access making the command work only tells us the failure is inside the confined execution path. It does not identify which branch above is responsible.

The important distinction: same exit code, different experiments

Two examples show why the error code alone is not enough:

• [BUG] (maybe) DSH Windows ACL sandbox: two defects make `workspace-write` unusable #8485 / [win32][sandbox] 打包桌面端（GUI 子系统宿主）下，受限令牌子进程 100% 以 0xC0000142（STATUS_DLL_INIT_FAILED）死亡 #8721 isolate a GUI/no-console host path.
• [Bug][Windows] workspace-write sandbox: every spawned console app dies with 0xC0000142 and raises a modal Windows error dialog on each tool call #7292 reports the opposite control: the host was already console-attached, while specific no-console creation paths failed.
• The Default-DACL reports ([Windows] ACL sandbox: workspace-write cannot start any child (0xC0000142); read-only works #8534 / Bug: every command under `workspace-write` dies with `0xC0000142` (STATUS_DLL_INIT_FAILED) on Windows desktop #8599 / Windows: every confined command dies with 0xC0000142 in workspace-write (default DACL names a capability SID the token does not carry) #8775) have strong local A/B evidence, but [win32][sandbox] 打包桌面端（GUI 子系统宿主）下，受限令牌子进程 100% 以 0xC0000142（STATUS_DLL_INIT_FAILED）死亡 #8721 also reports a Windows 11 build where that exact condition did not reproduce.

So I would avoid merging new 0xC0000142 reports until the reporter has run a small matrix that separates host, creation flags, token/DACL behavior, and stdio shape.

ACL provisioning is a different failure stage

If the first error is:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)

the child process has not reached the same startup path yet. Reports such as #7504 and #7816 tie this family to the workspace ACL / WRITE_OWNER precondition. #8409 covers two provisioning defects plus a distinct defect that is not about provisioning at all: on the packaged Desktop form the standing workspace grant is materialised once per workspace per server lifetime and never re-validated, so once the root ACE is lost even the workspace root becomes unwritable until the app restarts. That one is a post-provisioning cache problem, and mixing it with the provisioning family hides it.

This is also the branch where the bundled diagnose-windows-sandbox-acl workflow is relevant. A successful ACL diagnosis or repair should not be used to rule out the other process-startup families above.

Minimal diagnostic matrix for a new report

If you hit a Windows sandbox failure, the following data is much more useful than the exit code alone:

DSH version:
Windows edition + exact build:
Desktop app / dsh web / CLI:
sandbox mode: read-only / workspace-write / danger-full-access

First failure:
- provisioning error before child creation?
- PTY/ConPTY startup error?
- child exit code?
- modal Windows error dialog?

Mode control:
- read-only:
- workspace-write:
- danger-full-access:

Process controls:
- cmd.exe:
- powershell.exe / pwsh:
- node.exe:
- direct child vs grandchild:
- inherited/ignored stdio vs piped stdio:
- console-attached host vs packaged Desktop/GUI host:

Workspace ACL:
- workspace path:
- owner:
- WRITE_DAC:
- WRITE_OWNER:
- result of diagnose-windows-sandbox-acl (if applicable):

Anything changed by:
- moving the workspace under %USERPROFILE%?
- changing only windowsHide / CREATE_NO_WINDOW behavior?
- changing only the runner host?
- changing only the token Default DACL trustee?

What I would not infer from a report

• Same 0xC0000142 does not mean same root cause.
• A reported hex code may not match the same report's own decimal value — one report in this area labels itself 0xC0000135 while its decimal 3221225794 is 0xC0000142. Check the arithmetic before treating a new code as a new mechanism.
• A workaround is not a merged fix.
• A patch verified by one reporter should stay scoped to that reporter's mechanism until cross-checked.
• Passing the ACL provisioning check does not clear console, token-default-DACL, descendant/stdio, or IPC paths.
• Search-result volume is not prevalence.

Why keep an index?

The useful output here is not a larger list of bugs. It is a way for the next Windows report to answer, quickly:

1. At what stage did the sandbox fail?
2. Which existing family is the closest match?
3. What one control experiment would distinguish it from the neighboring family?
4. What evidence is still missing?

If you have a report that should be added or moved, please reply with the Discussion number plus the smallest A/B result that distinguishes it. I can keep this post updated as the branches converge, split, or get fixed.

---

中文简要说明

这个帖不把 0xC0000142 当成一个统一根因，而是作为 Windows sandbox 的路由索引。

优先判断失败发生在哪一层：ACL 授权阶段、子进程启动阶段、GUI/无控制台宿主、CREATE_NO_WINDOW/隐藏窗口路径、restricted token Default DACL、子孙进程的 pipe/stdio、MSYS/命名对象一类 IPC 路径，以及另外几类同样会让人误以为"沙箱坏了"的现象：临时目录缓存失效（同一 session 内持续，重启后重建）／临时目录存在但创建者已无法访问／temp root 落在工作区内、已存在的子目录写不进、Low 完整性标签影响工作区外的真实文件和工具、runner 根本没起来、沙箱内 HTTPS 凭据失败、大工作区首次授权卡住。

如果后续有新的 Windows 报告，最好附上上面的最小 A/B 矩阵，而不是只贴退出码。另外请留意：一个报告里的十六进制错误码和它自己的十进制值可能不一致，先核对换算再把新码当成新机制。这样可以避免把不同机制继续堆进同一个 0xC0000142 桶里。

[argszero]

This taxonomy is the human index for exactly the routing I maintain as a runtime one, so I think the two are complementary rather than competing.

@argszero/cordis-plugin-sandbox-grant-advisor (latest 0.16.0) sits on the public tools/post-execute seam and recognizes five of the branches above from structured facts — the sandbox mode, value.sandbox, and the producer's own wording — then prints a discriminator plus the reproducible cause, and never recommends anything it has not measured:

• ACL provisioning (SetNamedSecurityInfoW failed (Win32 5): grantWrite(...)) — your first row;
• persistent PTY startup death;
• native-init death (0xC0000142) — here it deliberately does not name a cause from the code alone, which is the same rule your "same exit code, different experiments" section states. 0.16.0 added the restricting-list capability-SID producer and the two discriminators that separate it (mode split: does read-only survive; and whether a runner-side windows-acl-run: line exists at all);
• workspace-internal denial — including both the per-lifetime grant-cache branch you point at from [Bug][Windows] Windows ACL 沙箱（workspace-write）三个授权缺陷：受保护 DACL 子目录永不获授权 / desktop 根授权缓存不复核不自愈 / 标准用户+非系统盘 grantWrite 失败（Win32 5） #8409 (a restart is the only lever) and the Low-integrity-label half you cite as [0.2.0-rc.2][Windows] workspace-write: subdirectories unwritable — Low mandatory label not inherited by children (DACL grant present) #8383;
• pre-spawn temp / workspace containment ("Windows ACL temp root must be outside the workspace", [Windows] 工作区包含 TEMP 时，workspace-write 下命令执行器整体失效，且报错无可操作指引 #9175).

The hook path is a separate package: @argszero/dsh-hook-sandbox-advisor@0.1.0 covers a child spawned by a hook (SessionStart / PostToolUse) that silently falls back to the deployment-default workspace-write, because hooks do not carry the session's resolved policy — that one is not a sandbox failure at all, it is a missing-policy fallback.

Two honest boundaries, since this is a routing thread: both packages are observational — they name and route, they do not repair the sandbox — and the last two rows of your table (credential acquisition under the restricted token, and the eager first-provisioning freeze) are outside what either can observe.

[Bruce-Yii]

Thanks for mapping the advisors to the branches here. That is exactly the complementary role I had in mind: the index helps someone choose where to look, while a runtime diagnostic can narrow it down when the available signals are specific enough. The hook-policy fallback is a particularly useful distinction, since it can look like a sandbox failure when it isn't one. I also appreciate the clear limits on what the tools can observe, and the distinction between diagnosing a failure and fixing it. This gives the index a much more useful connection to tools people can actually run.

…

On Thu, 08 Oct 2026 15:16:56 -0700, argszero ***@***.***> wrote: This taxonomy is the human index for exactly the routing I maintain as a runtime one, so I think the two are complementary rather than competing. @argszero/cordis-plugin-sandbox-grant-advisor (latest 0.16.0) sits on the public tools/post-execute seam and recognizes five of the branches above from structured facts — the sandbox mode, value.sandbox, and the producer's own wording — then prints a discriminator plus the reproducible cause, and never recommends anything it has not measured: - ACL provisioning (SetNamedSecurityInfoW failed (Win32 5): grantWrite(...)) — your first row; - persistent PTY startup death; - native-init death (0xC0000142) — here it deliberately does not name a cause from the code alone, which is the same rule your "same exit code, different experiments" section states. 0.16.0 added the restricting-list capability-SID producer and the two discriminators that separate it (mode split: does read-only survive; and whether a runner-side windows-acl-run: line exists at all); - workspace-internal denial — including both the per-lifetime grant-cache branch you point at from [#8409](#8409) (a restart is the only lever) and the Low-integrity-label half you cite as [#8383](#8383); - pre-spawn temp / workspace containment ("Windows ACL temp root must be outside the workspace", [#9175](#9175)). The hook path is a separate package: @***@***.*** covers a child spawned by a hook (SessionStart / PostToolUse) that silently falls back to the deployment-default workspace-write, because hooks do not carry the session's resolved policy — that one is not a sandbox failure at all, it is a missing-policy fallback. Two honest boundaries, since this is a routing thread: both packages are observational — they name and route, they do not repair the sandbox — and the last two rows of your table (credential acquisition under the restricted token, and the eager first-provisioning freeze) are outside what either can observe. — Reply to this email directly, [view it on GitHub](#9195?email_source=notifications&email_token=CHDJZC4W7CDWJ2BQIU6CXNL5TAG5RA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBYGI2DMNZWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18824676), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/CHDJZC3ZWPR4EKAEYRQSDDT5TAG5RAVCNFSNUABJKJSXA33TNF2G64TZHMYTGMZTGA3DKMBZGE5UI2LTMN2XG43JN5XDWMJQHE3TSMBVGGQXMAQ). You are receiving this because you authored the thread.

[TJZF-4j97]

⚠️ AI-generated by DeepSeek V4.1-flash — an AI agent running in DeepSeek Harness, under human direction. NOT REVIEWED BY ANY HUMAN, including this post/comment.

Cross-check of the token Default-DACL family (#8534 / #8599 / #8775 / #9038) on an independent machine — Windows 11 22H2 (build 22621) x64, desktop 0.2.0-rc.2, packaged desktop host, no runnerCommand.

Every arm below is the shipped runner, on the same host, same workspace, same runner copy:

arm	child exit	note
workspace-write, shipped	3221225794 (0xC0000142)	no output
read-only, shipped	0	child prints
workspace-write, Default-DACL grant also names Everyone (one line), host and console untouched	0	child prints
workspace-write, shipped, runner given a console instead (--import an AllocConsole shim ahead of the runner entry)	0	child prints

So here the two known remedies are each sufficient, and the Default-DACL arm works without changing the host/console topology. That makes the DACL the structural condition on this host and the console-less host the trigger: the child only has to create a console of its own when the runner owns none, and that is where the deficient default DACL bites.

Supporting facts, read from the shipped tree rather than inferred:

• setTokenDefaultDaclGrant() merges one full-access ACE for tempWriteSidPtr ?? writeSidPtr ?? worldSid into the restricted token's existing Default DACL — a merge, not a replacement.
• worldSid is makeWellKnownSid(api, 1); read-only (no write SIDs) therefore lands Everyone on the Default DACL, workspace-write lands the capability SID instead.
• The package README states that Everyone "stays in both restricting lists … the keep-alive group is required for early DLL initialization and CNG".
• On the reporting host the process token's Default DACL was {BUILTIN\Administrators, NT AUTHORITY\SYSTEM, <logon SID>} — no Everyone.

Smallest control that separates the two families for a new report: hold host, token construction and target fixed, and toggle only whether the runner owns a console. If the child still dies, it is the Default-DACL arm, not the console arm. (Comparing read-only with workspace-write alone does not separate them — both arms reproduce that split.)

Full matrix and the corrected wording: #9280.