Repository navigation
[Windows] pwsh child process cannot start under Workspace Write (0xC0000142 STATUS_DLL_INIT_FAILED) #8772
Replies: 3 comments 1 reply
Follow-up: the root cause has been located independently, and this machine matches the signatureThe
This machine matches that scenario:
That issue ships a reproducible probe, Additional possible contributoranweat/dsh-restart#10 points out that DSH deliberately omits That distinction was not verified on this machine and is listed only as a parallel possibility. ConclusionThe "causes ruled out" section of the original report still stands (ACL healthy, pwsh installed correctly, executable resolution correct), but the "suspected token-construction layer" direction now has a concrete mechanism behind it, so there is no need to keep investigating ACLs or antivirus. ## Follow-up: the root cause has been located independently, and this machine matches the signatureThe
This machine matches that scenario:
That issue ships a reproducible probe, Additional possible contributor[anweat/dsh-restart#10](anweat/dsh-restart#10) points out that DSH deliberately omits That distinction was not verified on this machine and is listed only as a parallel possibility. ConclusionThe "causes ruled out" section of the original report still stands (ACL healthy, pwsh installed correctly, executable resolution correct), but the "suspected token-construction layer" direction now has a concrete mechanism behind it, so there is no need to keep investigating ACLs or antivirus. |
|
Still reproducible on 44.7.0 / Windows 11 build 26100, and I think I can reduce it to a single rule. Posting here because it contradicts the "non-system-drive workspace" theory in the other reports. The rule
That is exactly why read-only → [logonSid, Everyone] // both already in the token
workspace-write → [logonSid, Everyone, workspaceSid, tempSid] // the derived capability SIDs never areThe workspace SID is derived per path ( Evidence
Not the authority: the same subauthorities fail under Controls, all still Why nothing useful is reported
Suggested
Happy to run any patch or diagnostic build on this machine (Windows 11 26100, x64, non-elevated user, PowerShell 7.6.9). |
|
Additional data point: the PowerShell version and install style are not the variable — one identical binary fails only under Environment differs from the original report in several ways that let it rule out the remaining hypotheses:
A/B on the same executable path, same session, minutes apart:
Ruled out by this data point:
Together with the follow-up about where the restricted token is created and @lwc18's restricting-SID rule, this supports the conclusion that nothing here is specific to I have not yet re-run the |
|
The restricting-SID rule you cited is mine — and it is still an inference, not a verified mechanism. Worth saying plainly before anything else: Everything else in your data point holds up, and two parts of it are more valuable than you framed them:
The test that can falsify the ruleDrive import { AclSandbox } from '@deepseek-ai/dsh-sandbox-windows-acl';
for (const sid of ['S-1-5-11','S-1-5-32-545','S-1-5-32-546','S-1-5-2','S-1-5-1000']) {
const sb = new AclSandbox({
writableDirs: ['C:\\ws'], tempDir: null, mode: 'workspace-write',
writeSid: sid, manageDacls: false,
});
await sb.init();
const c = sb.spawn({ command: 'cmd', args: ['/c','exit','0'], cwd: 'C:\\', stdio: 'ignore' });
console.log(sid, (await c.wait()).exitCode);
sb.dispose();
}Result on 26100:
Not the SID authority (same subauthorities fail under If 22621 reproduces the tableThen the conclusion stops being "DSH spawns children incorrectly" and becomes:
That moves the fix: not the spawn path, but the capability-SID mechanism (token-native group SIDs, or an AppContainer capability). It also explains why the two keep-alive SIDs — logon SID and Everyone — were the right thing to add and the wrong thing to rely on. Proof of concept: what a working configuration looks likeSame So the sandbox is not structurally broken: with a token-native capability SID the child starts, and the fence behaves — writes inside the granted directory succeed, writes outside are refused. But the isolation is weaker, and that is the actual design problem. With And a non-privileged process cannot add an arbitrary group SID to its own token — that needs That leaves three options, none of them local:
Caveat on 0.2.1-rc.5: the |
Uh oh!
There was an error while loading. Please reload this page.
Windows:
pwshchild process cannot start under Workspace Write (0xC0000142STATUS_DLL_INIT_FAILED)Summary
On Windows, with the default Workspace Write permission mode, every call to the model-facing
pwshtool ends immediately with0xC0000142(STATUS_DLL_INIT_FAILED) — even a trivialecho hi— with no stdout and no stderr. Switching the same session to full access (danger-full-access) makes the identical command succeed at once. The file sandbox itself works correctly (writeinside the workspace succeeds,writeoutside is denied); only process creation is broken.Environment
Conclusion: the filesystem ACL fence works; only starting a child process under the restricted token fails.
Causes ruled out
Each of the following was tested, not assumed:
Not a missing PowerShell installation.
C:\Program Files\PowerShell\7\pwsh.exeexists and runs standalone; the registry keyHKLM:\SOFTWARE\Microsoft\PowerShellCore\InstalledVersionscarriesSemanticVersion=7.6.6; the systemPATHcontainsC:\Program Files\PowerShell\7\. Running it from an ordinary terminal prints7.6.6.Not executable resolution. The first candidate of
candidatePwshPaths()in@deepseek-ai/dsh-pwsh-localis%ProgramFiles%\PowerShell\7\pwsh.exe, so it always matches; the profile'scordis.patch.ymlcontains nopwshPathoverride.Not a workspace ACL problem. A full diagnose-and-repair run of this repository's bundled
diagnose-windows-sandbox-aclscript againstD:\DSH--Test(run unconfined) reported:That is,
writeDac=TrueandwriteOwner=True, and noS-1-15-2-*foreign package ACEs to remove. The full record is in the appendix below.Not an unreadable binary.
C:\Program Files\PowerShell\7grantsBUILTIN\UsersReadAndExecute, Synchronize; the directory carries no explicit integrity label (it inherits Medium).Suspected direction
0xC0000142surfaces at the token-construction layer, not the file-permission layer. DSH's own sandbox documentation names this exact exit code:So the suspicion is that the Windows ACL restricted-token runner (
@deepseek-ai/dsh-sandbox-windows-acl) fails to create a usable restricted token on this machine. I tried to reproduce the mechanism standalone (CreateRestrictedToken+ set the low-integrity label +CreateProcessWithTokenW) but could not complete it, becauseSetTokenInformationreturned998. So the root cause is not confirmed — only the exclusionary evidence above is offered.Impact and workaround
WARN powershell: PowerShell 7 not foundin thedsh-win32 doctoroutput.Aside: a separate installation trap worth confirming
On this machine,
winget install --id Microsoft.PowerShellinstalls the MSIX/Store build (PowerShell-7.6.6.msixbundle), which:C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.6.0_x64__8wekyb3d8bbwe;PowerShellCore\InstalledVersionsregistry key;C:\Program Files\PowerShell\7\;pwsh.exeonly through theWindowsAppsapp-execution alias.DSH's resolver only looks at
%ProgramFiles%\PowerShell\7\pwsh.exeandPATH, so it reports "PowerShell 7 not found" even thoughwinget listshows the package as installed. Installing the MSI instead (or--installer-type msi) clears that warning. This may deserve its own hint indsh-win32 doctor.Appendix: raw `diagnose-windows-sandbox-acl` record (acl-report-4a4debcf158f497aa3ce78b6b549893a.jsonl, all 12 lines)
All reactions