Sandboxed child-process creation triggers Windows error dialog (0xC0000142 / STATUS_DLL_INIT_FAILED)

[user0319a]

Category: Bug report (posting under General since no Bugs category exists)
Environment: @deepseek-ai/dsh 0.1.5-rc.3, Windows 10 Pro NT 10.0.19045.0 x64, PowerShell 5.1.19041.7725, Node.js v24.20.0. File policy workspace-write, approval policy ask. Observed with dsh-sandbox-windows-acl / dsh-pwsh-sandbox / dsh-sandbox / dsh-sandbox-local / dsh-sandbox-policy all at 0.1.5-rc.3.

Symptom

Creating any child process from inside the sandbox pops a modal Windows error dialog:

<program>.exe - Application Error
The application was unable to start correctly (0xc0000142).
Click OK to close the application.

cmd.exe, node.exe, powershell.exe, notepad.exe, ping.exe, whoami.exe, where.exe — all trigger it. The dialog is unrelated to the target program. Frequency is high, and dialogs stack up when several sessions run tasks concurrently.

It does not break task execution. The dsh host process and the pwsh tool itself keep working; only child processes spawned from them fail.

0xC0000142 = STATUS_DLL_INIT_FAILED.

This behaviour predates 0.1.5-rc.3 — the reporter observed it for several days on earlier builds too, so it is not a regression introduced by this release, but it is 100% reproducible on it.

Reproduction

All three creation paths fail inside the sandbox:

# 1) Start-Process
$p = Start-Process cmd.exe -ArgumentList "/c exit" -PassThru -Wait
$p.ExitCode        # => -1073741502  (0xC0000142)

# 2) Call operator
& cmd.exe /c "exit"
$LASTEXITCODE      # => empty

# 3) Job
$j = Start-Job { cmd /c "exit" }; $j | Wait-Job; $j.State   # => Failed

Control: the identical commands succeed when run with widened permissions (danger-full-access). The only variable is whether the call happens inside the restricted sandbox context.

Operation	Sandboxed	Escalated
Start-Process cmd.exe	❌ -1073741502	✅ 0
Start-Process notepad.exe	❌ dialog	✅ runs
Start-Process node.exe	❌ dialog	✅ writes file

Minimal script

foreach ($exe in @('cmd.exe','notepad.exe','node.exe','ping.exe','whoami.exe')) {
    $a = switch ($exe) { 'cmd.exe' { '/c exit' } 'ping.exe' { '127.0.0.1 -n 1' } default { $null } }
    $p = Start-Process -FilePath $exe -ArgumentList $a -PassThru -Wait -WindowStyle Hidden -ErrorAction SilentlyContinue
    $s = if (-not $p) { 'could not start' }
         elseif ($p.ExitCode -eq -1073741502) { 'FAIL 0xC0000142' }
         elseif ($p.ExitCode -eq 0) { 'OK' } else { "code=$($p.ExitCode)" }
    Write-Host ("{0,-16} {1}" -f $exe, $s)
}

# Control: the file sandbox should still behave normally
$t = Join-Path $PWD "_probe.txt"
Set-Content $t "probe" -ErrorAction SilentlyContinue
Write-Host "write workspace: $(if (Test-Path $t) {'OK'} else {'FAIL'})"
Remove-Item $t -Force -ErrorAction SilentlyContinue
Set-Content "$env:USERPROFILE\_probe.txt" "x" -ErrorAction SilentlyContinue
Write-Host "write outside:   $(if (Test-Path "$env:USERPROFILE\_probe.txt") {'ALLOWED (unexpected)'} else {'DENIED (expected)'})"
Remove-Item "$env:USERPROFILE\_probe.txt" -Force -ErrorAction SilentlyContinue

Actual output:

cmd.exe          FAIL 0xC0000142
notepad.exe      FAIL 0xC0000142
node.exe         FAIL 0xC0000142
ping.exe         FAIL 0xC0000142
whoami.exe       FAIL 0xC0000142
write workspace: OK
write outside:   DENIED (expected)

Every FAIL line corresponds to one Windows dialog.

Related existing reports

This looks like another instance of a known family of Windows ACL-sandbox failures, so I'm filing it as an addition rather than a new class of bug:

• #1613 — Windows: sandbox crashes Cygwin/MSYS tools and node — exit 3221225794 (0xC0000409) — same component (sandbox-windows-acl), same root cause (restricted token via CreateRestrictedToken), different failure code (fast-fail 0xC0000409 vs loader 0xC0000142 here).
• #3466 — [Bug][Windows] ACL sandbox spawn failure paths can leak native handles — also about spawn failure paths in the same runner.

The distinguishing factor of this report is the UX symptom: #1613 crashes silently with an exit code, whereas here the failure surfaces as a modal Windows dialog that the user must dismiss, repeatedly. That is arguably worse for day-to-day use because it interrupts whatever else the user is doing, and it happens for every spawn rather than only for Cygwin/MSYS binaries.

Note the failure code differs from #1613 on the same host class: that report sees 0xC0000409 (STATUS_STACK_BUFFER_OVERRUN, Cygwin's fast-fail after a denied CreateFileMapping), while here plain cmd.exe and node.exe both fail with 0xC0000142 — the failure happens earlier, in loader DLL initialisation, before the program gets to run any of its own code. So the restricted token appears to break child creation at more than one stage, and which stage fails determines whether the user sees a silent exit code or a modal dialog.

On this machine the only exception is the first-level pwsh host itself, which the sandbox starts successfully; everything it then spawns dies with 0xC0000142.

Root cause

dsh-sandbox-windows-acl spawns children through a restricted token. This is visible in the shipped sources:

// types-DuU3lSVe.js
createRestrictedToken: bind(advapi32, "CreateRestrictedToken", "int", [...]),
/** Restricted-token adapters over the shared Win32 process owner. */
* Spawn a restricted-token child with piped stdout/stderr.

// runner.js
* WRITE_RESTRICTED token with the workspace write-SID allowlist, spawns the
* signature. The child is NEVER spawned unrestricted.

Under that restricted token the Windows loader cannot complete DLL initialisation for the child, so CreateProcess fails with STATUS_DLL_INIT_FAILED and the loader raises a modal error box.

The key contradiction

The pwsh tool itself runs fine (it can read and write files, run internal cmdlets), yet any child process spawned from it fails. So the restricted token is sufficient to start the first-level host, but not to let that host spawn a second-level child.

That points at the nested-spawn path rather than first-level creation. Worth checking whether the sandbox re-applies restrictions when the spawning process is already itself restricted, or fails to carry over a privilege the loader needs.

This also explains why users perceive "it doesn't affect my work": the first layer of the tool chain is intact; only programs invoked from inside it are hit.

Scope check (eliminations)

To rule out a host problem rather than a sandbox problem:

Check	Result
File sandbox (ACL)	✅ works — reads system files OK, writes workspace OK, correctly denies writes outside
System DLL integrity	✅ kernel32 / ntdll / user32 / KernelBase versions consistent
Desktop heap	✅ SharedSection=1024,20480,768 (Windows defaults)
AppInit_DLLs injection	✅ empty, LoadAppInit_DLLs=0
IFEO hijacking	✅ none for cmd/node/powershell
Compatibility shims	✅ no system-level __COMPAT_LAYER
Memory	✅ ~7.7 GB free, commit 9.37 GB / 34 GB limit
Full reboot	❌ does not help — still 100% reproducible

The file sandbox behaving perfectly while only process creation fails is what isolates this to the spawn path. A full reboot changing nothing rules out pending-update or transient-state explanations.

Two defects

1. Functional — the restricted token is too restrictive for nested child creation. Suggest auditing the token handling on the nested-spawn path.

2. UX (the more important one) — even if the spawn should fail, it must not raise a modal Windows dialog. Windows raises it because the process is created with default error-mode settings. Please suppress it, e.g.:

   SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);

   or on the Node side create with windowsHide: true and avoid UseShellExecute, so the failure returns an error code for dsh to report itself instead of interrupting the user with a popup.

Workaround

None needed for functionality. Blocking the popup would require weakening the sandbox (switching permission preset away from workspace-write, or disabling pwsh-sandbox), which trades away the protection — not recommended as a fix, only as a last resort for the noise.

---

AI assistance disclosure

This report, its reproduction, and the format were produced with assistance from DeepSeek (an AI coding agent running in DeepSeek Harness). The reporter is the machine owner who observed the dialogs and confirmed the behaviour predates 0.1.5-rc.3 on this machine.

[user0319a]

Following up on my own report — after posting I searched more thoroughly and found this is already well covered. Cross-referencing so the maintainers have everything in one place, and noting one extra data point.

This is a duplicate — please treat these as the canonical threads

• #5013 — [Windows] Rscript/Python crash with 0xC0000142 / 0xC0000005 under read-only ACL sandbox (Aug 29). Same root cause, and it points at the authoritative detail: packages/sandbox/sandbox-windows-acl/src/token.ts already documents this — "early DLL init dies with 0xC0000142 ... without them". That thread also carries a locally implemented and verified patch, including the SetErrorMode(SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX) change that my report independently proposed.
• #7292 — [Bug][Windows] workspace-write sandbox: every spawned console app dies with 0xC0000142 and raises a modal Windows error dialog on each tool call (~5 days ago). Describes the exact same symptom as mine, on the same default mode.
• #1613 — same component and root cause, different failure code.

Apologies for the duplicate. My pre-post search did surface #1613 and #3466 but missed #5013 and #7292; had I found them I would have replied there instead of opening a new thread. Please feel free to close or merge this one.

The one data point I think is worth adding

The reproduction in this report differs slightly from the others in which programs fail and how early:

• [Windows] Rscript/Python crash with 0xC0000142 / 0xC0000005 under read-only ACL sandbox #5013 reports the crash for programs that initialise a runtime and need %TEMP% (Rscript -e, Python) — i.e. a denied temp write during program startup.
• [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 it for "every spawned console app".
• On this machine it is even earlier and more total: plain cmd.exe /c exit, notepad.exe, ping.exe, whoami.exe and node -e 0 all fail with 0xC0000142 under workspace-write. These are programs that do not create a temp directory to do anything meaningful, and cmd.exe /c exit runs no program logic at all — so the failure precedes anything the child itself does.

If that holds, it suggests the restricted-token configuration is losing something the loader itself needs during DLL initialisation, not only something needed by a temp-writing startup path. That would put the failure one stage earlier than the temp-directory explanation in #5013, and would mean a fix scoped only to granting a scratch temp dir may not cover this host.

I cannot verify that theory from here (no access to the runner sources on this machine), so I am flagging it as an observation rather than a claim.

Environment where this reproduces

• @deepseek-ai/dsh 0.1.5-rc.3, Windows 10 Pro NT 10.0.19045.0 x64
• PowerShell 5.1.19041.7725, Node.js v24.20.0
• File policy workspace-write, approval policy ask
• dsh-sandbox-windows-acl / dsh-pwsh-sandbox / dsh-sandbox / dsh-sandbox-local / dsh-sandbox-policy all at 0.1.5-rc.3
• Survives a full reboot — 100% reproducible
• The only thing that starts successfully is the first-level pwsh host; everything it spawns dies

The file sandbox behaves correctly on this machine throughout (workspace writes OK, writes outside denied), which is what isolates this to the spawn path rather than a host problem.

What would help most

If the #5013 patch is waiting on maintainer sign-off, that decision is the actual blocker for this class of bugs — including the modal-dialog annoyance, which is the part that interrupts users. Happy to test a candidate build on this machine (Windows 10, workspace-write) if that is useful; I can report back with before/after results for the repro script in the opening post.

[1zyao]

Cross-link from #8142 — same 0xC0000142 family, now reproduced deterministically, which may explain why only some children fail.

Driving the sandbox package directly (AclSandbox, workspace-write, spawning cmd /c echo hello), the only thing that differs is the host process:

host process	has a console	result
node.exe from a terminal	yes	exit=0
Electron (ELECTRON_RUN_AS_NODE=1)	no	exit=3221225794
Electron + AllocConsole()	yes	exit=0

init() succeeds every time; only the confined child dies during DLL init.

This matches your observation that the pwsh tool itself keeps working while other children fail: a child that shares an existing console lives, while any child that needs a new / hidden console (Start-Process, -WindowStyle Hidden, CREATE_NO_WINDOW) dies with 0xC0000142 — the sandbox README states exactly this. On a host with no console at all (the desktop app's Electron host) even the confined shell itself dies, which is what #8142 reports.

Full report + minimal repro script: #8142