[Bug] Windows workspace-write: 0xC0000142 comes from the token default DACL naming a non-restricting capability SID (corrected; follow-up to #8991 / #8067)

[nailong823]

Relation to existing reports

This continues #8991 ("every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED)") and #8067 (the 0xC0000142 bubble). Both describe the symptom. #8991 explicitly labels its root cause as "hypothesis, not verified against source" and asks whether the runner needs SeAssignPrimaryTokenPrivilege, a specific UAC configuration, AppContainer support, or particular workspace ACLs.

This post answers that question: it is none of those. The trigger can be isolated with a controlled experiment.

#8067 quotes sandbox-windows-acl/README.zh.md describing 0xC0000142 at DLL-init as a known limitation of CREATE_NO_WINDOW / CREATE_NEW_CONSOLE. The data below shows a second, distinct trigger that also fires on the ordinary stdio: "inherit" path, so the README's framing does not cover every affected host.

Summary

On Windows, every pwsh/shell tool call under the default workspace-write sandbox mode fails before the command ever runs. The restricted-token ACL runner starts fine in read-only mode, but as soon as the mode becomes workspace-write the child process exits with 3221225794 (0xC0000142, STATUS_DLL_INIT_FAILED) and produces no stdout and no stderr at all.

Two distinct problems:

1. The sandbox cannot start a child process under workspace-write on this host. Root cause: the token's default DACL names the derived capability SID (setTokenDefaultDaclGrant, index.ts:304), and under a WRITE_RESTRICTED token the image section carrying that DACL fails the access check, so the loader dies before any user code runs. The earlier "capability SID has no read ACE on System32" claim is withdrawn — see Root cause (corrected) below.
2. The failure is mis-classified. dsh-pwsh-sandbox's classifyRunnerFailure / isRunnerSpawnFailure only recognises spawn ENOENT/EACCES of argv[0]. A child that exits with 0xC0000142 is not treated as a sandbox failure, so the user sees a generic command failure instead of SandboxUnavailableError. This is what made the bug hard to diagnose, and it is arguably the more important half to fix.

Environment

item	value
DSH app	desktop 0.2.1-rc.3, commit be72761ee1a6736ebcdf4f3739363b083ae53c98
Electron / node	Electron 39, embedded node v24.21.0
OS	Windows 10/11 x64
User	COMPUTER\Administrator (S-1-5-21-…-500), high integrity, elevated via UAC
App manifest	requestedExecutionLevel level="asInvoker"
Workspace	D:\DSH-Workspace
Temp root	C:\Users\Administrator\AppData\Local\Temp, and separately D:\DSH-ww-probe (outside the workspace)

Steps to reproduce

Run the sandbox runner directly, bypassing DSH tooling:

$exe = "D:\DSH\DeepSeek Harness.exe"
$runner = "D:\DSH\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js"

# read-only: works
& $exe $runner --workspace "D:\DSH-Workspace" --temp "D:\DSH-temp" --mode read-only -- cmd /c "echo RO-OK"
# -> exit 0, stdout "RO-OK"

# workspace-write: child dies before running
& $exe $runner --workspace "D:\DSH-Workspace" --temp "D:\DSH-temp" --mode workspace-write -- cmd /c "echo WW-OK"
# -> exit 3221225794 (0xC0000142), stdout "", stderr ""

Same result through the DSH pwsh tool under the default permission preset.

What is not the cause (all verified empirically)

• Not elevation. An unelevated run (scheduled task, RunLevel=LeastPrivilege, ELECTRON_RUN_AS_NODE=1) reproduces 0xC0000142 identically while read-only still succeeds.
• Not the privileges named in [Bug] workspace-write sandbox: every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED), no stderr #8991. See the dedicated section below.
• Not the temp directory. Moving the temp root outside %TEMP% (to D:\DSH-ww-probe) changes nothing.
• Not a missing/incorrect DACL grant. Passing a fabricated capability SID S-1-4-424242-424242 that has no ACE anywhere, with manageDacls: false, still fails.
• Not the runner itself. AclSandbox.init() and win32() binding load succeed in-process (3 ms / 7 ms); the runner reaches spawn() and gets a pid. The crash is in the child.
• Not the executable. cmd.exe, where.exe, hostname.exe, whoami.exe all fail identically.
• Not permission on the exe's own directory. Copying where.exe into a directory the capability SID can read does not help.
• Not a corrupted app.asar. read-only runs from the same asar path successfully; a SHA-256 sweep over the archive is clean.

Explicitly ruled out: the privileges named in #8991

#8991 asked whether the runner needs SeAssignPrimaryTokenPrivilege. On this host:

• SeAssignPrimaryTokenPrivilege is absent from the token entirely; LSA policy (secedit /export /cfg) grants it only to *S-1-5-19,*S-1-5-20 (LOCAL SERVICE, NETWORK SERVICE). AdjustTokenPrivileges returns ERROR_NOT_ALL_ASSIGNED (1300).
• Despite that, CreateRestrictedToken succeeds, AclSandbox.init() succeeds, and spawn() returns a pid — the privilege is not on the failing path for this backend.
• The app runs elevated (TokenElevation=1, high integrity) via UAC, yet an unelevated run reproduces 0xC0000142 identically while read-only still succeeds.

The variable is the content of the restricting-SID list, as shown next.

Root cause (corrected 2026-10-31)

Correction. The original version of this section claimed the trigger was the capability SID lacking a read ACE on C:\Windows\System32. That claim is withdrawn — see my reply below for the single-variable experiment. Read-only and workspace-write differ in two places at once (the restricting list and the token's default DACL), so the original two-mode comparison could not attribute the failure to either one. The corrected root cause is:

dsh-sandbox-windows-acl builds the child token with

CreateRestrictedToken(..., flags = 0xD, ...)   // 0xD = DISABLE_MAX_PRIVILEGE(0x1) | LUA_TOKEN(0x4) | WRITE_RESTRICTED(0x8)

and then grants the derived capability SID in the token's default DACL (index.ts:304):

setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);

When the process creates kernel objects without an explicit security descriptor — pipes, events, image sections — those objects inherit that default DACL. Under a WRITE_RESTRICTED token the access check consults the restricting SIDs, and an object whose DACL names only a SID that cannot satisfy the check makes the loader fail to map the system DLL, surfacing as STATUS_DLL_INIT_FAILED before any user code runs.

The invariant that predicts the outcome is "the SID named in the default DACL must also be a restricting SID". Everyone is in the restricting list ([logonSid, known.world, ...writeSids]); a capability SID, Authenticated Users, and BUILTIN\Users are not.

Controlled experiment (only the default DACL changes)

Token built exactly as shipped; only TokenDefaultDacl overwritten via SetEntriesInAclW + SetTokenInformation(TokenDefaultDacl = 6). Workspace write SID and temp write SID are the shipped capability SIDs in every row. Workspace has inheritance disabled, AU:(M) removed, granting only BA:(F), SY:(F) and the capability SID (W,D,DC).

#	restricting list	default DACL names	child exit
A1	logon, world, cap	cap (as shipped)	0xC0000142
A2	logon, world, cap	S-1-1-0 Everyone	0
A3	logon, world, cap	S-1-5-11 Auth. Users	0xC0000142
A4	logon, world, cap	S-1-5-32-545 Users	0xC0000142
B1	logon, world, world	cap	0xC0000142

A1 vs A2 is the isolating pair: identical restricting list, only the default DACL SID differs, and the outcome flips. The earlier "System32 read ACE" table below is retained only as a record of what was actually run; its interpretation was wrong.

Original (withdrawn) table, kept for the record

restricting SID	System32 ACE rights	child result
S-1-5-32-545 BUILTIN\Users	0x1200a9 (read+execute)	exit 0
S-1-1-0 Everyone	no explicit ACE (inherits read)	exit 0
S-1-5-11 Authenticated Users	no explicit ACE (inherits read)	exit 0
S-1-5-21-…-500 current user	no explicit ACE (inherits read)	exit 0
S-1-5-18 LOCAL SYSTEM	0x1301bf (full control)	0xC0000142
S-1-5-32-544 BUILTIN\Administrators	0x1301bf (full control)	0xC0000142
S-1-5-80-… service SID (TrustedInstaller)	0x1f01ff (full control)	0xC0000142
S-1-4-136077656-194402612 capability SID	absent	0xC0000142

This table varied the write SID, which changes the restricting list and the default DACL together — it could not attribute the failure.

Relevant code:

• dsh-sandbox-local/lib/index.js — windowsAclRunnerArgv() adds --write-sid / --temp-write-sid when policy.sessionId !== undefined && mode !== "read-only"; materializeAclGrant() creates the standing recursive workspace ACE.
• dsh-sandbox-windows-acl/lib/runner.js — const api = await win32(), then new AclSandbox({... manageDacls: !seamManaged }) → init() → spawn({ stdio: "inherit" }).
• dsh-win32-process/lib/index.js:425-427 — createRestrictedProcess() calls CreateProcessAsUserW with lpEnvironment = NULL (documented workaround for a koffi ERROR_INVALID_PARAMETER); every failure there throws and emits the windows-acl-run: signature, so a silent 0xC0000142 cannot originate in that code.

Impact

On affected hosts the default workspace-write preset makes the shell tool unusable, which is the primary tool for most workflows. The only working configurations I found are read-only (no writes) and danger-full-access (no sandbox).

Suggested fixes for the sandbox half (in order of preference)

Corrected. Fix 4 of the original list ("there is no acceptable local fix") was based on the withdrawn System32 theory and is removed.

1. Add the logon SID to the default DACL alongside the capability SID (rather than replacing it with a well-known SID). findLogonSid already exists in token.ts and is imported at index.ts:55. The logon SID is already in the restricting list, so the pass-2 check that motivated the grant still passes, and the "never tag default-DACL objects with the shared workspace capability" intent still holds. This is the change that matches the A1–A4 data; replacing the SID with Authenticated Users (as proposed in Windows 10: workspace-write sandbox kills every child process with 0xC0000142 (default DACL names a capability SID) #11448) is expected to keep failing on this host, because AU is not a restricting SID here. Not yet verified by me — it is the next experiment.
2. Probe workspace-write, not just read-only. dsh-sandbox-local selects windows-acl from PLATFORM_CHAINS = { win32: ["windows-acl"] } without probing (chainVerdict() returns the first candidate when the rest list is empty), even though L137 documents a "functional windows-acl probe" that runs the runner in read-only mode only. Extend that probe to workspace-write and surface SandboxUnavailableError when it fails.
3. Widen the documented limitation. README.zh.md line 119 and the keep-alive-group note at line 94 describe 0xC0000142 as a CREATE_NO_WINDOW issue; per the data above the default-DACL composition is an independent trigger.

Additional note

app.asar in the desktop distribution is a valid asar plus a DSH trailer JSON appended after the data section (data base = 8 + headerSize + 4 = 4748104 for this build). Not a bug, just worth documenting — it cost me a false "corrupted archive" hypothesis early on.

[PerryLink]

补一条你可能想先对的证据：#11448 在同一台机器上做了受控变体，第 6 组只改默认 DACL 里的 SID（换成 S-1-5-11），restricting 列表不动，子进程就起来了。

而 workspace-write 与 read-only 的差异同时落在两处：restricting 列表，和默认 DACL——packages/sandbox/sandbox-windows-acl/src/index.ts:304 是

setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)

所以在 workspace-write 下默认 DACL 里带的是派生能力 SID，read-only 下是 world SID。这意味着"能力 SID 在 System32 上没有读 ACE"这个结论，光靠两种模式的对比还分离不开——两处同时变了。

要把你的结论钉死，需要像 #11448 的第 6 组那样只动一处。现在两份报告的根因指向不同的令牌部位，先对一次再定稿比留下两个互相矛盾的根因要好。

只读了源码（f3803c96），没有 Windows 环境可跑。

[nailong823]

You are right, and my original experiment could not have separated the two factors: read-only and workspace-write differ in both the restricting list and the default DACL, so the "capability SID has no read ACE on System32" claim was under-determined. I have now run the single-variable version. The result is that your factor (default DACL) is the decisive one, and my factor (System32 ACE) is not — my suggested fixes were wrong and I withdraw them.

Setup

Kernel-only manipulation, no source changes: I let init() build the token as shipped, then overwrote only TokenDefaultDacl on the resulting token via SetEntriesInAclW + SetTokenInformation(TokenDefaultDacl = 6). The restricting list, integrity level, and every other part of the token stay exactly as the shipped code builds them. Workspace write SID and temp write SID are the shipped capability SIDs in every row.

Each row is a separate process; the child is a .bat in the workspace that writes whoami and the result of an in-workspace file write to a file I read afterwards.

Workspace: a fresh directory with inheritance disabled, AU:(M) inherited ACE removed, granting only BA:(F), SY:(F) and the capability SID (W,D,DC) — so a successful write cannot be explained by the ambient Authenticated Users grant.

Results

#	restricting list	default DACL names	child exit	note
A1	logon, world, cap	cap (as shipped)	0xC0000142
A2	logon, world, cap	S-1-1-0 Everyone	0	child runs
A3	logon, world, cap	S-1-5-11 Auth. Users	0xC0000142
A4	logon, world, cap	S-1-5-32-545 Users	0xC0000142
B1	logon, world, world	cap	0xC0000142
B2	logon, world, world	Everyone	1	child starts, cannot open the workspace .bat

So: the same restricting list is fatal with a capability-SID default DACL and fine with an Everyone default DACL (A1 vs A2). That kills my System32-ACE theory outright — the capability SID never needed a System32 ACE, the child never got far enough to use one.

Where I agree and where the data disagrees with #11448

Agreed: the trigger is setTokenDefaultDaclGrant naming a derived capability SID, exactly as you traced at index.ts:304.

But the "any well-known SID works" reading does not reproduce here. Everyone (A2) works; Authenticated Users (A3) and BUILTIN\Users (A4) both stay at 0xC0000142. That is the opposite of #11448's variant 6, which reports S-1-5-11 working. The one property Everyone has and AU/BU do not, in this token, is that Everyone is already in the restricting list ([logonSid, known.world, ...writeSids] at createRestrictedToken, types-Cl_DXjhk.js:884-897). AU and BUILTIN\Users are not.

That makes your proposed fix direction the right one and the #11448 patch the wrong one: append the logon SID to the default DACL next to the capability SID, rather than replacing it with a well-known SID. Appending satisfies "the named SID is also a restricting SID", which is the invariant that actually predicts the outcome across A1–A4. Replacing with AU would be expected to keep failing on this host.

I have not yet run the append-the-logon-SID variant — I can do that next if useful, since it is the one experiment that would confirm the invariant rather than merely being consistent with it.

B2

B2 is not a sandbox-start failure: with writeSid set to Everyone the child starts normally and prints Access is denied. four times when it tries to open the workspace .bat, because the workspace grants write only to the capability SID. Different failure, not part of the trigger.

Also, on #11448's escape claim

#11448 reports that an in-workspace child writing to the Desktop is denied. On this host, with the shipped default DACL replaced by Everyone (A2), a child that runs successfully writes to C:\\Windows\\ and gets ERRORLEVEL 0. I am not claiming that is a security hole in the intended configuration — A2 is a modified token — but the "escape denied" observation should not be used as evidence about the shipped behaviour without checking which token variant it came from.

Environment: Windows 10/11 x64, DSH desktop 0.2.1-rc.3 (commit be72761), Electron 39 / node 24.21.0, COMPUTER\\Administrator (S-1-5-21-…-500), elevated-via-UAC, workspace D:\\DSH-clean-ws, temp root outside the workspace.

I will correct the original post's Root cause and Suggested fixes sections so the thread does not carry the withdrawn claim.

[nailong823]

Follow-up: the second layer, plus the variable separation PerryLink asked for

This comment completes the picture. It adds three things:

1. the isolated matrices that separate the two factors (only the default DACL changes / only the workspace inheritance changes);
2. the access-mask constraint on the appended ACE;
3. the result that the capability SID never grants anything at all — workspace write access actually comes from ordinary NTFS inheritance.

TL;DR: fixing only the default DACL makes the child start, but the capability SID in the workspace ACL is dead weight. Isolation rests on "workspace already inherits write for Authenticated Users", not on the sandbox's own ACE.

---

1. Only the default DACL changes

Fixed: writeSid = workspace capability SID, tempWriteSid = temp capability SID, restricting list unchanged, Low IL unchanged, same child (powershell.exe -File <script>). Only the SID inside the token default DACL is replaced.

case	SID in default DACL	also in restricting list?	child
A1	as-built (capability SID)	yes	0xC0000142
A2	S-1-1-0 Everyone	yes	exit 0
A3	S-1-5-11 Authenticated Users	no	0xC0000142
A4	S-1-5-32-545 BUILTIN\Users	no	0xC0000142
B1	as-built, writeSid=Everyone	yes	0xC0000142
B2	Everyone, writeSid=Everyone	yes	exit 1 (starts; workspace unreadable)

The A2 vs A3/A4 pair is the point: AU and BU are ordinary groups with perfectly normal read access on System32, yet as default-DACL SIDs they still fail. Only Everyone works, and the one property Everyone has that AU/BU do not is that Everyone is already in the restricting list (createRestrictedToken() builds restricting as [logonSid, known.world, ...writeSids], types-Cl_DXjhk.js:884-897).

So the invariant is:

The SID named in the token default DACL must also be a restricting SID.

That is why #11448's variant 6 (S-1-5-11) worked on that machine and fails here: "replace with AU" is not portable. PerryLink's "append the logon SID" is the direction that survives both hosts.

Append vs replace, and the mask constraint

On the same restricted token, touching only the token default DACL:

default DACL	child
as-built	0xC0000142
append logon SID, mask 0x1f01ff	exit 0
replace with logon SID only, mask 0x1f01ff	exit 0

Append and replace are equivalent for getting the child to start; append is the safer patch because it keeps the capability ACE.

Mask sweep, with the logon SID appended:

mask	child
0x1f01ff FILE_ALL_ACCESS	starts
0x1301bf	0xC0000142
0x1200a9	0xC0000142
0x20089	0xC0000142
0x1000	0xC0000142

The appended ACE must be FILE_ALL_ACCESS; read-only or write-only masks do not lift the loader failure. That is a direct constraint on the fix: the existing FILE_ALL_ACCESS in setTokenDefaultDaclGrant() is load-bearing and must not be "tightened".

I have now run the append-the-logon-SID variant I said I had not run yet. It works.

---

2. The capability SID never grants anything

With layer one fixed, does the workspace become writable? Dumping the restricted token's groups on the host side:

GetTokenInformation(token, TokenGroups = 2)
groupCount = 14   (same with and without the appended logon SID)
attrs: 0x7 x9, 0x10 x2, 0xc0000007 (logon SID), 0x60 (Low IL)

The capability SID S-1-4-… is not among them. CreateRestrictedToken's SidsToRestrict is an intersection constraint; it does not add group membership. So the workspace ACE (A;OICI;0x1301bf;;;S-1-4-…) can never match an access check from the sandboxed child.

Two workspaces, identical ACLs except for one thing:

D:\DSH-vA : ... (A;OICI;0x1301bf;;;S-1-4-828817396-217741746) + SY/BA  + inherited Authenticated Users:(M)
D:\DSH-vB : ... (A;OICI;0x1301bf;;;S-1-4-484025387-743797302) + SY/BA  (no inheritance)

Same AclSandbox({manageDacls:true}), same appended logon SID, same temp root, same child. Judged only by host-side fs.existsSync():

workspace	inherits AU:(M)	child	temp write	workspace write	D:\ root write
DSH-vA	yes	exit 0	OK	OK	DENIED
DSH-vB	no	exit 0	OK	DENIED	DENIED

The only difference is the inherited ACE, and workspace writability flips with it.

Conclusion: workspace write access comes from ordinary NTFS inheritance (Authenticated Users), not from the capability SID. The capability ACE the sandbox installs is inert.

Consequences:

• Functional: a workspace stripped of inheritance (icacls /inheritance:r) is completely unwritable even with layer one fixed.
• Security: isolation strength is whatever the workspace's pre-existing NTFS permissions allow. A too-permissive workspace is not tightened by the sandbox.

Correction to something I said earlier

On D:\DSH-clean-ws (/inheritance:r, only BA/SY plus the capability SID) workspace writes were denied, and I inferred "workspace-write is effectively no-write". That inference only holds for workspaces with inheritance stripped. A normal workspace behaves differently: on the real D:\DSH-Workspace, with the logon SID appended, I get realws=OK; temp=OK; outside=DENIED.

So the accurate framing is: the 0xC0000142 is what users actually hit; the inert capability SID is a separate correctness defect that normal workspaces mask.

---

3. Integrity label ruled out

I suspected the Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) that icacls prints for the workspace. Reading the SACL directly with GetNamedSecurityInfoW(SE_FILE_OBJECT, SACL_SECURITY_INFORMATION):

D:\DSH-Workspace    rc=0 present=True  AceCount=0
D:\DSH-label-test   rc=0 present=False AceCount=-1
C:\Windows          rc=0 present=False AceCount=-1

present=True with AceCount=0, and GetAuditRules() returns 0 entries. The workspace has no integrity-label ACE; the icacls line is a display artifact. Not a variable.

---

4. Two independent bugs found along the way

• Command line quoting. sb.spawn({command:'cmd.exe', args:['/c','<path with spaces>']}) always yields 命令语法不正确。, while the same command outside the sandbox exits 0 and creates the file. The command line is not quoted per MSVCRT rules.
• stdio:'pipe' is broken. The handle returned by AclSandbox.spawn() has no stdout stream; child.stdout.on(...) throws Cannot read properties of undefined (reading 'on'). Only stdio:'inherit' works.

---

5. What a correct fix looks like

Layer one — name in the default DACL a SID that is also a restricting SID, with FILE_ALL_ACCESS. Append the logon SID next to the capability SID rather than replacing it (portable across hosts, keeps the capability ACE).

Layer two — the capability-SID design does not work as written: it is restricting-only, never a real group, so it authorizes nothing. Either:

• make it a genuine group member (CreateRestrictedToken cannot do this; it needs NtCreateToken group manipulation or an AppContainer SID), or
• accept the model explicitly — "Low IL no-write-up plus whatever the workspace already grants" — and document that the workspace must remain writable for the invoking user.

Fixing only layer one leaves workspaces with inheritance stripped in a new failure mode: the child starts but cannot write anything. That is harder to diagnose than a clean 0xC0000142.

---

Environment safety

C:\Windows\System32 DACL was never modified (SDDL still matches the 501-character backup). All ACL writes were confined to throwaway directories (D:\DSH-clean-ws, D:\DSH-vA, D:\DSH-vB) which have been deleted. The real workspace's ACL was not modified. Scheduled tasks created during investigation were removed.

Host: Windows 10/11 x64, DSH desktop 0.2.1-rc.3 (commit be72761ee1a6736ebcdf4f3739363b083ae53c98), Electron 39 / node 24.21.0, COMPUTER\Administrator (S-1-5-21-…-500).

[PerryLink]

Read the matrix — A2/A1 is the decisive pair. Withdrawing the System32 claim was the right call; one caveat changes the last section, though.

The restricting list is not just the capability SIDs. packages/sandbox/sandbox-windows-acl/src/token.ts:216-230 builds it as [logonSid, world, ...writeSids] ([logonSid, world] for read-only), and buildRestrictingSids passes all of them through without filtering. So S-1-1-0 and the logon SID also satisfy the write access check. That is exactly why A2 works when you put Everyone in the default DACL — not because Everyone is special, but because it is already in the restricting list.

Which means the row where you removed the capability ACE needs one more control. index.ts:9-12 states that Authenticated Users, INTERACTIVE and LOCAL are absent from both lists, so an AU:(M) ACE cannot be what allowed your write. If that variant still wrote, resolve the granting ACE to its SID rather than reading the display name — Everyone or the logon SID would explain it, and both are in the list by design.

It matters for the conclusion: "the capability SID is dead weight, isolation rests on NTFS inheritance" and "writes come through the keep-alive logon SID" are different boundaries. The second says any process in that logon session can write to the workspace too, which is much weaker than the per-workspace capability SID the design claims (index.ts:16-20).

Agreed on the access-mask constraint on the appended ACE — that one is worth writing down regardless of how the above lands.

Version check: the restricting list is identical in rc.3, rc.4, rc.5 and master ce7073d5, so this is not a version difference.