Upstream report : workspace-write makes every confined command exit 0xC0000142

[Icefox12138]

Summary

On the Windows desktop build, when the file policy is workspace-write, every command executed through
the sandbox is terminated during DLL initialization with exit code 0xC0000142
(STATUS_DLL_INIT_FAILED), producing no output at all.

I isolated the failure out of DSH entirely and reproduced it 1:1 with raw P/Invoke:

Create a Low-integrity token via CreateRestrictedToken with WRITE_RESTRICTED,
restricting SIDs = [Everyone, logon SID] (approximating the workspace-write set),
then start cmd.exe /c exit 7 through CreateProcessWithTokenW → the child dies with 0xC0000142.
Merely adding S-1-5-32-544 (Administrators) or S-1-5-18 (SYSTEM) to the restricting list
makes the same spawn succeed with exit 7.

In other words: the root cause is that the WRITE_RESTRICTED token's restricting SID list lacks a SID that
carries write access to some resource the process needs during initialization. It is unrelated to windowsHide,
to console inheritance, or to the target program. The failure also hits a minimal, IO-free executable, so it
is on the generic initialization path.

Reproduction

A. Inside DSH

1. Windows 11 25H2 (build 26200.9711), DSH desktop 44.7.0.
2. Set the file policy to workspace-write.
3. Run any command through the pwsh tool, e.g. echo ok.
4. Observed: no stdout/stderr; process exit code 3221225794 (0xC0000142).

The result is identical whether DSH was launched from the desktop GUI or from a PowerShell terminal.

B. Minimal reproduction, without DSH (best for root-causing)

A single self-contained file reproduces it. csc repro.cs, then pass the restricting SIDs as one comma-separated argument
(the logon SID comes from whoami /logonid):

// repro.cs — csc repro.cs && repro.exe <comma-separated restricting SIDs>
// Prints "child exit = ..." ; 3221225794 (0xC0000142) = the failure, 7 = the child ran.
using System;
using System.Runtime.InteropServices;

static class P
{
    [StructLayout(LayoutKind.Sequential)] struct SAA { public IntPtr Sid; public uint Attr; }
    [StructLayout(LayoutKind.Sequential)] struct PI { public IntPtr hProc, hThread; public int pid, tid; }
    [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)] struct SI
    {
        public int cb; public string r, d, t;
        public int x, y, xs, ys, xc, yc, fill, flags;
        public short show, cb2; public IntPtr r2, stdin, stdout, stderr;
    }

    [DllImport("advapi32", SetLastError = true)] static extern bool OpenProcessToken(IntPtr p, uint a, out IntPtr t);
    [DllImport("advapi32", SetLastError = true)] static extern bool DuplicateTokenEx(IntPtr t, uint a, IntPtr sa, int imp, int type, out IntPtr nt);
    [DllImport("advapi32", SetLastError = true, CharSet = CharSet.Unicode)] static extern bool CreateRestrictedToken(IntPtr t, uint f, uint dis, IntPtr s, uint dp, IntPtr pv, uint n, SAA[] rs, out IntPtr nt);
    [DllImport("advapi32", SetLastError = true)] static extern bool SetTokenInformation(IntPtr t, int c, IntPtr i, int l);
    [DllImport("advapi32", SetLastError = true, CharSet = CharSet.Unicode)] static extern bool CreateProcessWithTokenW(IntPtr t, uint lf, string app, string cmd, uint f, IntPtr env, string cwd, ref SI si, out PI pi);
    [DllImport("advapi32", SetLastError = true, CharSet = CharSet.Unicode)] static extern bool ConvertStringSidToSid(string s, out IntPtr sid);
    [DllImport("kernel32")] static extern IntPtr GetCurrentProcess();
    [DllImport("kernel32")] static extern uint WaitForSingleObject(IntPtr h, uint ms);
    [DllImport("kernel32")] static extern bool GetExitCodeProcess(IntPtr h, out uint c);
    [DllImport("kernel32")] static extern bool CloseHandle(IntPtr h);

    static int Main(string[] args)
    {
        IntPtr tok, prim, res;
        if (!OpenProcessToken(GetCurrentProcess(), 0x02000000, out tok)) return Err("OpenProcessToken");
        if (!DuplicateTokenEx(tok, 0x02000000, IntPtr.Zero, 2, 1, out prim)) return Err("DuplicateTokenEx");

        string[] sids = args[0].Split(',');
        var saa = new SAA[sids.Length];
        for (int i = 0; i < sids.Length; i++)
            if (!ConvertStringSidToSid(sids[i], out saa[i].Sid)) return Err("ConvertStringSidToSid");

        const uint DISABLE_MAX_PRIVILEGE = 0x1, WRITE_RESTRICTED = 0x8;   // <-- the toggle
        if (!CreateRestrictedToken(prim, DISABLE_MAX_PRIVILEGE | WRITE_RESTRICTED,
                0, IntPtr.Zero, 0, IntPtr.Zero, (uint)saa.Length, saa, out res)) return Err("CreateRestrictedToken");

        IntPtr lowIl;
        if (!ConvertStringSidToSid("S-1-16-4096", out lowIl)) return Err("low IL sid");
        var label = new SAA { Sid = lowIl, Attr = 0x20 };                  // SE_GROUP_INTEGRITY
        int sz = Marshal.SizeOf(typeof(SAA));
        IntPtr buf = Marshal.AllocHGlobal(sz);
        Marshal.StructureToPtr(label, buf, false);
        bool ok = SetTokenInformation(res, 25, buf, sz);                  // TokenIntegrityLevel
        Marshal.FreeHGlobal(buf);
        if (!ok) return Err("SetTokenInformation");

        var si = new SI { cb = Marshal.SizeOf(typeof(SI)) };
        PI pi;
        if (!CreateProcessWithTokenW(res, 0, null, "cmd.exe /c exit 7", 0, IntPtr.Zero,
                @"C:\Windows", ref si, out pi)) return Err("CreateProcessWithTokenW");

        CloseHandle(pi.hThread);
        WaitForSingleObject(pi.hProc, 15000);
        uint code;
        GetExitCodeProcess(pi.hProc, out code);
        CloseHandle(pi.hProc);
        Console.WriteLine("child exit = {0} (0x{1:X8})", code, code);
        return 0;
    }

    static int Err(string w) { Console.WriteLine("{0} failed, err={1}", w, Marshal.GetLastWin32Error()); return 1; }
}

Observed on the affected host (<logon> from whoami /logonid):

repro.exe S-1-1-0,S-1-5-5-0-<logon>                    -> child exit = 3221225794 (0xC0000142)
repro.exe S-1-1-0,S-1-5-5-0-<logon>,S-1-5-32-544        -> child exit = 7
repro.exe S-1-1-0,S-1-5-5-0-<logon>,S-1-5-18            -> child exit = 7

Dropping WRITE_RESTRICTED from the flags makes every combination exit 7, which is why the flag — not the SID values
alone — is the switch this report is about.

Note on privilege availability: this machine's token does not hold
SeAssignPrimaryTokenPrivilege (not granted to Administrators by default), so
CreateProcessAsUser always fails with 1314. CreateProcessWithTokenW (which needs the
already-enabled SeImpersonatePrivilege) works. This may partly explain why the official path
succeeds on some Windows configurations and not on others.

Current behavior

The target process is created (a PID is returned) but dies during DLL initialization, always with
0xC0000142, and emits no output.

Matrix: WRITE_RESTRICTED + Low integrity + cmd.exe /c exit 7 (key evidence):

Restricting SIDs	Result
[] (empty)	❌ 0xC0000142
[Everyone]	❌ 0xC0000142
[Users]	❌ 0xC0000142
[Authenticated Users]	❌ 0xC0000142
[Everyone, user SID]	❌ 0xC0000142
[Administrators] alone	❌ 0xC0000142
[Users, Administrators]	❌ 0xC0000142
[Everyone, logon SID] (≈ current workspace-write)	❌ 0xC0000142
[SYSTEM] alone	✅ exit 7
[Everyone, Administrators]	✅ exit 7
[Everyone, logon SID, Administrators]	✅ exit 7; powershell.exe also ✅ exit 9
[Everyone, logon SID, SYSTEM]	✅ exit 7

Hypotheses already ruled out, each with a controlled test:

Hypothesis	Experiment	Verdict
windowsHide / CREATE_NO_WINDOW	The restricted-token path uses dwCreationFlags = 0 or 4 and never sets that flag; I also patched windowsHide in launchWindowsJob and tested it in the real build	❌ Irrelevant (patch has been reverted)
Console inheritance (GUI host has no console)	Launched DSH from a PowerShell terminal so the host owns a console — still fails	❌ Not a console problem
AppInit_DLLs injection	AppInit_DLLs empty, LoadAppInit_DLLs=0, no AppCertDlls	❌ No global injection
Low integrity level itself	Without WRITE_RESTRICTED, Low integrity spawns fine (exit 7)	❌ Not the integrity level
Target program specificity	A purpose-built IO-free executable (Main only returns 42) also dies with 0xC0000142	❌ Target-independent
Missing keep-alive group (logon SID + Everyone)	That group is already in the list and it still fails	❌ Insufficient explanation

Expected behavior

Confined child processes should start and run normally under workspace-write — the documented promise of
workspace-write is a write boundary, not "processes cannot initialize".

Even if initialization genuinely cannot succeed in some environments, I would expect a diagnosable error
(e.g. classify 0xC0000142 as a sandbox startup failure with guidance) rather than no output plus a bare exit
code. The current shape makes users misattribute the failure to the target program or to their own command.

Environment

Item	Value
OS	Windows 11 25H2, build 26200.9711
DSH	Desktop 44.7.0 (D:\Program Files\dsh\version)
Packages	@deepseek-ai/dsh-sandbox-windows-acl 0.2.1-rc.2, @deepseek-ai/dsh-subprocess-local 0.2.1-rc.2
Target shell	Windows PowerShell 5.1.26100.9711
Privileges	Running as FSGDZ0067\Administrator; token holds SeImpersonatePrivilege, does not hold SeAssignPrimaryTokenPrivilege
Endpoint security	QI-ANXIN Tianqing (QAXClientSvc / QaxEngManager / TQDefender, all running) and TEC OCular (C:\ProgramData\Ocular)
Policy comparison	danger-full-access → pwsh works; workspace-write → always 0xC0000142

One hypothesis, and questions

This machine runs enterprise endpoint-security agents. My hypothesis is that during process initialization they
need write access to a resource of their own that is granted only to SYSTEM / Administrators, and the
workspace-write restricting list does not carry that authority — so initialization fails.

I would appreciate guidance on:

1. Is this a known compatibility boundary between endpoint-security software and WRITE_RESTRICTED tokens?
2. Is there a supported way to grant the sandbox just the write capability needed for process initialization,
   instead of adding Administrators / SYSTEM wholesale to the restricting list (which would materially
   weaken the write boundary)?
3. Can the missing resource be pinpointed through configuration (custom runner, or disabling WRITE_RESTRICTED
   for a diagnostic run)?

I have not yet captured the exact ACCESS DENIED target with Process Monitor. I can do that and follow up here
if it would help.

---

Additional forensics: what was ruled out, and what remains unknown

I tried to capture the exact denied object. Summary of the attempts:

Technique	Outcome
Process Monitor 4.12 (/AcceptEula /Quiet /BackingFile:...)	Exits with code 1 after ~3 s and never creates the backing file — the kernel driver cannot load (endpoint security present). Unusable.
ETW Microsoft-Windows-Kernel-Registry	Works, and it does record access failures (0xC0000022) for other processes — but there are zero denials for the failing child. Its registry writes (SetValueKey into the BAM/AppCompat keys) all succeed. ⇒ not a registry write.
ETW Microsoft-Windows-Kernel-File	Works, but emits no denied opens (no 0xC0000022 anywhere in 55k events).
Direct device probes under both tokens	\Device\CNG, \Device\Null, \Device\KsecDD, \Device\Beep: GENERIC_READ and GENERIC_WRITE succeed for both tokens; only GENERIC_ALL differs. ⇒ CNG is not the blocker.
CreateProcess flag sweep	flags 0, CREATE_NEW_CONSOLE, CREATE_NO_WINDOW all fail identically; CREATE_SUSPENDED stays alive until resumed. ⇒ console allocation is not the discriminator.
Global resource SACL (auditpol /resourceSACL)	Rejected on this build (ERROR_INVALID_PARAMETER), so file-level failure auditing could not be enabled.

Behavioural narrowing (ETW Kernel-File event counts): the failing child emits 40 file events and stops immediately after touching
C:\WINDOWS\System32\Conhost.exe, while a succeeding child emits 318. The failing child also reads
...\qianxin\ifl\fcEng\QaxComInj\Avoid.txt, i.e. QI-ANXIN's kernel injection driver (QaxComInj64.sys) is active inside the process.

Still not pinned down: the exact object. The blocker is the same endpoint-security stack that is itself the prime suspect —
it prevents the kernel-mode tracing that would name the object.

What would close it

Any of the following would let me (or you) name the object in one run:

1. A DSH-side diagnostic that reports the failing access when a confined child exits with 0xC0000142
   (e.g. run the child under a controlled CreateProcess with a debugger-attached "last chance" handler,
   or simply log GetLastError from the sandbox runner's own setup steps).
2. Confirmation of which objects the runner expects the confined child to be able to write — if you can tell me,
   I can test that specific object with both tokens and confirm in minutes.
3. Permission to temporarily disable the endpoint agent's injection for one experiment
   (our IT must approve; this is the only remaining way to prove agent involvement on this host).

---

[AqualCross]

Reproduces on DSH Desktop 0.2.1-rc.2 (Windows x64), default workspace-write.

Every pwsh tool call exits 0xC0000142 (STATUS_DLL_INIT_FAILED) with no output;
danger-full-access works. Not PowerShell-specific — with an explicit pwshPath the
same happens for

• pwsh 7.6.7 (MSI, C:\Program Files\PowerShell\7\pwsh.exe), and
• Windows PowerShell 5.1 (%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe).

A nonexistent pwshPath surfaces the runner itself:

sandbox mode "workspace-write" is requested but no sandbox backend is usable on this host
Runner failure: windows-acl-run: CreateProcessAsUserW failed (Win32 2)

This build appears to predate the Electron console trampoline fix (a1caef3,
"keep confined shells alive when Electron has no console"). In the shipped app.asar:

• ensureWindowsConsoleHost — 0 occurrences
• AllocConsole — 0 occurrences
• windows-acl-run — present (control)

Consistent with that, the failure is a bare child exit 0xC0000142, not the signed
runner path (windows-acl-run: <detail> + exit 127) that a present-but-failing
AllocConsole() would produce. So the GUI host has no console to hand down, and the
restricted child's own conhost creation dies during DLL initialization.

OS: Windows 10 19045.6466.