[Desktop/Windows] App cannot start unless --no-sandbox — GPU process IMMEDIATE_CRASH (0x80000003), UI only says "无法使用"

[1second1]

Caution

The Windows desktop app (0.2.0-rc.2) cannot start on this machine at all: Chromium's process sandbox
fails to initialize, the GPU process hits IMMEDIATE_CRASH (0x80000003) 9 times in 537 ms, then
Chromium kills itself with FATAL: GPU process isn't usable. Goodbye. The UI only shows a window titled
"DeepSeek Harness 无法使用" with no error code and no log path.
The usual advice --disable-gpu does not help (it does not remove the GPU process). Only
--no-sandbox works — and with it, Chromium's stderr is completely empty (0 bytes).

Environment

• Windows 11 22631 (23H2), zh-CN
• @deepseek-ai/dsh-desktop 0.2.0-rc.2 (Electron 44.0.0 / Node 24.18.1), per-user install
• Installer verified: Authenticode Valid (Hangzhou DeepSeek Artificial Intelligence Co., Ltd.),
  SHA256 d61cd8882f8b8a1251144320493ad27920d15139503eba2465b9579eee720cfc, size matches the CDN byte-for-byte
• app.asar integrity: 11,470/11,470 files match the embedded SHA256 manifest
• Coexisting software: Huorong AV, Sogou IME, MuMu emulator virtual display adapter, Clash Verge (mihomo TUN)
• GPU: Intel UHD (2023-06 driver) + NVIDIA RTX 4060 Laptop (2026-09 driver)
• Get-ProcessMitigation -System → all NOTSET (not a system mitigation policy)

Symptom

Double-clicking the app: the window flashes and disappears. Later runs show a window titled
"DeepSeek Harness 无法使用" (unusable). No actionable error, no log path.

Root cause (Chromium logging)

--enable-logging=stderr --v=1 (trimmed to non-VERBOSE lines):

ERROR content\browser\gpu\gpu_process_host.cc:1035] GPU process exited unexpectedly: exit_code=-2147483645
WARNING content\browser\gpu\gpu_process_host.cc:1479] The GPU process has crashed 1 time(s)
Error: Desktop renderer exited: crashed
    at WebContents.<anonymous> (…/resources/app.asar/lib/main.js:12067:107)
...
WARNING content\browser\gpu\gpu_process_host.cc:1479] The GPU process has crashed 9 time(s)
FATAL content\browser\gpu\gpu_data_manager_impl_private.cc:417] GPU process isn't usable. Goodbye.

First GPU crash at 011643.717, FATAL at 011644.254 -> 537 ms end-to-end.
-2147483645 = 0x80000003 = STATUS_BREAKPOINT (Chromium IMMEDIATE_CRASH()).
Windows Application Error log agrees: faulting module = DeepSeek Harness.exe itself,
exception 0x80000003, offset 0x7274509, repeatedly.

To contrast, the same binary with --no-sandbox produced an empty Chromium stderr (0 bytes),
window title "DeepSeek Harness", host ready on 127.0.0.1:19387, GET / -> 401 (expected).

Flag matrix (measured on this machine)

flags	result
(none)	❌ crash (GPU process 9x in 537 ms)
--disable-gpu	❌ crash (6x)
--disable-gpu-sandbox	❌ GPU stops crashing, UI still "unusable" (another sandbox component fails; main crashes 1x)
--disable-gpu --disable-gpu-sandbox --disable-software-rasterizer	❌ crash
--disable-gpu-sandbox --disable-features=WebGPU,Vulkan	❌ crash
--disable-gpu-sandbox --use-angle=swiftshader	❌ crash
--in-process-gpu	✅ survives (not fully verified)
--no-sandbox	✅ works (empty stderr, UI loads, host ready)

So Chromium's process sandbox cannot be established on this machine at all.

Requests

1. Surface the Chromium FATAL/CHECK lines and the Desktop Host stdout/stderr tail in
   %APPDATA%\@deepseek-ai\dsh-desktop\logs\ and on the failure page, with a copy button. Today those logs
   only contain Desktop renderer exited: crashed / ERR_FAILED (-2) loading 'dsh-app://app/', which
   hides the actual cause.
2. When the sandbox cannot be established, fail with an actionable message (or an explicit degradation
   switch) instead of IMMEDIATE_CRASH + a window that only says "无法使用".

Other reportable items (same environment)

A. Windows sandbox grant failure breaks EVERY command under workspace-write (CLI, 0.1.7+)

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)

@deepseek-ai/dsh-sandbox-windows-acl performs three edits in ONE SetNamedSecurityInfoW call
(capability-SID allow ACE + a Deny ACE removing FILE_DELETE_CHILD from the world SID + a Low mandatory
label), which needs WRITE_DAC on the workspace root. A workspace whose DACL only carries inherited
ACEs (Administrators(F) [deny-only in an unelevated token] / SYSTEM(F) / Authenticated Users(M) /
Users(RX)) grants the user none, so every command fails — including echo. Adding a single explicit
(OI)(CI)(F) ACE for the current user fixes it instantly; afterwards icacls shows all three edits landed
(Everyone:(CI)(DENY)(DC), a capability SID :(OI)(CI)(W,D,DC), and
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)). The failure should be actionable, not silent.

B. Boot-time regression

Same machine, same stock profile, time to dsh web: http://…: 3.2 s (0.1.2-rc.1) → 12.2–13.3 s
(0.1.5-rc.2) → 17–19 s with a 4-plugin profile; a second independent install took 29.7 s on first boot.
--dump-config is 0.18 s, and startup burns 5–6 s of CPU with no child processes and no file writes,
so the cost is in-process plugin startup rather than profile composition.

[mornintokyo]

The flag results suggest that the GPU itself may not be the primary problem here.

In particular, --disable-gpu still crashes, while --in-process-gpu and --no-sandbox allow the application to survive. That points more toward an interaction between Chromium's process sandbox and the GPU process initialization rather than a simple GPU driver failure.

Since the machine has several components that can interact with Chromium's sandbox or graphics stack (Huorong AV, MuMu's virtual display adapter, and the Clash Verge TUN driver), I would try isolating those before changing the GPU configuration:

1. Temporarily disable/exit Huorong and test again.
2. Disable/remove the MuMu virtual display adapter and test.
3. Temporarily stop Clash Verge/mihomo and test.
4. If possible, test with only the Intel GPU enabled and then only the NVIDIA GPU enabled.
5. Compare the result with a clean Windows user profile or a machine without the additional virtual drivers.

The fact that --no-sandbox works is particularly useful: it suggests that bypassing Chromium's sandbox changes the failure path. I would therefore investigate why the sandboxed GPU process cannot initialize rather than treating 0x80000003 as a normal GPU-driver crash.

It may also be worth logging the Chromium sandbox initialization failure itself. The current Desktop renderer exited: crashed message hides the actual failure, so exposing the GPU process and sandbox initialization logs would make this much easier to diagnose.

I would avoid recommending --no-sandbox as the permanent fix because it disables an important Chromium security boundary.

[1second1]

It's best to wait for an official now,at least that's how it is in my case.