[Bug][Windows] workspace-write sandbox: every confined process dies with STATUS_DLL_INIT_FAILED (0xC0000142 / 3221225794)

[YUE-k666]

[Bug][Windows] workspace-write sandbox: every confined process dies with STATUS_DLL_INIT_FAILED (0xC0000142 / 3221225794)

Environment

• DeepSeek Harness desktop 0.2.1-rc.2 (dsh-sandbox-windows-acl 0.2.1-rc.2), Windows 11 Pro (26100+), zh-CN locale
• PowerShell 7.6.7 at C:\Program Files\PowerShell\7\pwsh.exe
• Permission mode: workspace-write (default), approval ask
• 100% reproducible

Symptom

Every shell command executed by the model in a workspace-write session dies instantly with no output:

[exit code: 3221225794]   # 0xC0000142 STATUS_DLL_INITIALIZATION_FAILED

read-only mode works fine. An unconfined shell works fine. cmd.exe crashes exactly the same way, so this is not PowerShell-specific.

Root cause

In workspace-write mode, AclSandbox.init() sets the confined child's token default DACL to grant only the derived workspace/temp write SID:

// lib/types-Cl_DXjhk.js
setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);

That write SID (S-1-4-*, derived from the workspace path) exists only in the token's restricting list — not in its normal groups. Any securable object the confined process creates without an explicit security descriptor (notably objects created during console/conhost initialization) therefore gets a DACL that no component can satisfy:

• pass 1 (normal SIDs): user/Everyone not granted → denied
• pass 2 (restricting SIDs): write SID granted → allowed
• restricted-token semantics require both passes to succeed → access denied

The console client/server handshake fails during loader initialization → every confined child exits 0xC0000142.

read-only is unaffected because its default DACL grants worldSid.

Minimal reproduction

Drive the shipped @deepseek-ai/dsh-sandbox-windows-acl directly (the package can be extracted from app.asar; repro script and a full crash dump are available):

import { mkdtempSync, mkdirSync, rmSync, existsSync } from 'fs';
import { tmpdir } from 'os';
import { join } from 'path';
import { AclSandbox, tempWriteSid, workspaceWriteSid } from '@deepseek-ai/dsh-sandbox-windows-acl';

const workspaceRoot = 'D:\\sandbox-probe';
if (!existsSync(workspaceRoot)) mkdirSync(workspaceRoot, { recursive: true });
const tempDir = mkdtempSync(join(tmpdir(), 'dsh-'));

const sandbox = new AclSandbox({
  tempDir,
  writableDirs: [workspaceRoot],
  tempWriteSid: tempWriteSid(tempDir),
  writeSid: workspaceWriteSid(workspaceRoot),
  mode: 'workspace-write',
});

const child = await sandbox.init().then(() => sandbox.spawn({
  command: 'C:\\Program Files\\PowerShell\\7\\pwsh.exe',
  args: ['-NoProfile', '-Command', 'exit 42'],
  cwd: workspaceRoot,
}));
const { exitCode } = await child.wait();
console.log(exitCode);          // 3221225794 (0xC0000142)
rmSync(tempDir, { recursive: true, force: true });

Discriminating results on the affected machine:

variant	result
mode: 'read-only' (restricting = [logon SID, Everyone])	✅ exit 42
workspace-write + cmd.exe	❌ 0xC0000142
workspace-write, tempDir: null (temp SID removed)	❌ 0xC0000142
workspace-write with the one-line fix below	✅ exit 42

Fix

Grant Everyone in the default DACL (aligned with the read-only branch):

setTokenDefaultDaclGrant(api, restrictedToken, worldSid);

Verified to eliminate the crash while the rest of the write boundary (workspace/temp capability ACEs, Low integrity label, FILE_DELETE_CHILD deny, WRITE_RESTRICTED + LUA_TOKEN token) remains intact.

Suggested proper fix: include both the write SID and worldSid (or the logon SID) in the default DACL, so the child's own objects stay writable by its console/conhost chain while remaining closed to other principals.

Workaround used on the affected machine

In-place equal-length byte patch of types-Cl_DXjhk.js inside app.asar (backup kept). Please treat this as a high-priority regression — it makes the default Windows desktop experience unusable.

Notes

• Not caused by third-party software: reproduced on a clean boot with no AV products installed (removed during triage), Procmon shows zero ACCESS DENIED and a normal DLL load sequence ending at conhost spawn.
• Procmon trace and a full crash dump (231 MB) are available if useful.