[BUG] Windows 桌面端无法启动：GPU 进程初始化失败直接终止应用（Intel Arc + 多虚拟显示器环境）

[tiancaixiaoxi]

问题概述

Windows 11 桌面端无法通过应用自己的快捷方式启动，双击后进程约 1 秒内退出，无任何界面、无任何提示。稳定复现。

同时发现：应用不写任何日志文件，所有诊断信息只走 stdout，用户双击启动时完全看不到，导致无法自助排查。

---

环境信息

硬件

项目	值
电脑厂商 / 型号	HUAWEI / ENZH-XX（产品版本 M1010）
主板	HUAWEI ENZH-XX-PCB
BIOS	HUAWEI 1.16（2025-07-22）
处理器	Intel(R) Core(TM) Ultra 5 125H（14 核 / 18 线程 / 3.60 GHz）
内存	15.5 GB
操作系统	Microsoft Windows 11 家庭版 中文版
系统版本	10.0.26200（Build 26200），64 位

显示适配器（关键）

适配器	驱动版本	驱动日期	类型
Intel(R) Arc(TM) Graphics	31.0.101.5382	2024-03-27	物理 GPU（核显） PCI\VEN_8086&DEV_7D55&SUBSYS_3E7219E5&REV_08
wjIddDriver Device	9.22.56.244	2025-04-22	虚拟显示器 ROOT\DISPLAY\0000
GameViewer Virtual Display Adapter	15.6.5.199	2026-02-28	虚拟显示器 ROOT\DISPLAY\0001

系统中并存 1 个物理 GPU + 2 个虚拟显示器适配器，怀疑这是 GPU 枚举失败的直接诱因。

软件版本

项目	值
DSH 桌面端（初装）	0.2.0-rc.1
DSH 桌面端（复现时）	0.2.0-rc.2（经应用内自动更新）
安装包	deepseek-harness-0.2.0-rc.1-win-x64.exe（288,472,536 字节） deepseek-harness-0.2.0-rc.2-win-x64.exe（289,313,640 字节）
Electron	44（resources/version = 44.0.0）
内置运行时	Node 24.21.0 / pnpm 11.7.0 / Python 3.12.14
安装位置	D:\software\DeepSeek Harness
用户数据目录	%APPDATA%\ZCode

---

复现步骤

1. 使用官方安装包安装 DSH 桌面端并开启自动更新（升至 0.2.0-rc.2）。
2. 通过开始菜单快捷方式启动，或直接双击 DeepSeek Harness.exe（即不带任何命令行参数 —— 这是普通用户的标准路径）。
3. 观察进程列表：进程出现后约 1 秒内全部退出，稳定复现。

要看日志需要手动重定向 stdout：

cd "<安装目录>"
env -u ELECTRON_RUN_AS_NODE -u NODE_OPTIONS "./DeepSeek Harness.exe" > plain.log 2>&1

---

实际表现

崩溃日志

Checking for update
[34008:0929/185231.719:ERROR:content\browser\gpu\gpu_process_host.cc:1035]
    GPU process exited unexpectedly: exit_code=-2147483645
Error: Desktop renderer exited: crashed
    at WebContents.<anonymous> (file:///.../app.asar/lib/main.js:12067:107)
    at WebContents.emit (node:events:521:24)
[34008:0929/185231.810:ERROR:content\browser\gpu\gpu_process_host.cc:1035]
    GPU process exited unexpectedly: exit_code=-2147483645
[34008:0929/185232.504:FATAL:content\browser\gpu\gpu_data_manager_impl_private.cc:417]
    GPU process isn't usable. Goodbye.

exit_code=-2147483645 即 0x80000003（STATUS_BREAKPOINT）。GPU 进程连续崩溃约 10 次后，Chromium 判定 GPU 不可用，直接终止整个应用，连主界面都进不去。

命令行参数兼容性实测

启动参数	结果
无参数（快捷方式默认）	❌ GPU 崩溃，进程归零
--disable-gpu	❌ 崩溃
--disable-gpu --disable-gpu-compositing	❌ 崩溃
--disable-gpu-compositing	❌ 崩溃
--use-angle=swiftshader	❌ 崩溃
--disable-gpu-sandbox	⚠️ 不崩溃，但弹出「DeepSeek Harness 无法使用」错误框
--in-process-gpu	⚠️ 不崩溃，但弹出「DeepSeek Harness 无法使用」错误框
--no-sandbox	✅ 正常启动（5~6 个进程，主窗口正常，内置 Web 服务正常）

目前唯一可行的规避手段是 --no-sandbox。但这会关闭 Chromium 渲染沙箱，不适合作为面向普通用户的默认方案 —— 用户不知道要加这个参数，只会认为「软件坏了」。

附带问题：应用不写日志文件

排查时发现 %APPDATA%\ZCode 下只有 Chromium 会话数据（Cache / GPUCache / Local Storage / Network 等），没有任何 logs/ 目录或 .log 文件。

全部诊断输出只走 stdout，用户双击启动时被丢弃，导致：用户看不到崩溃原因、无法通过提交日志报 bug、只能靠人工重定向 stdout 才能定位问题。

建议增加本地日志落盘（如 %APPDATA%\ZCode\logs\main.log，带滚动），对桌面端问题定位帮助极大。

---

期望表现

1. 应用应能通过开始菜单快捷方式直接启动，不需要用户手动附加命令行参数。
2. GPU 初始化失败时应自动降级到软件渲染并正常出界面，而不是直接终止进程。
3. 若确实无法启动，应给出可读的错误提示（例如「显卡驱动异常，请更新驱动或禁用虚拟显示器适配器」），而不是静默退出。
4. 应写本地日志文件，便于用户自助排查与反馈。

---

补充

• 0.2.0-rc.1 与 0.2.0-rc.2 的崩溃行为完全一致，仅堆栈行号不同（main.js:11565 → main.js:12067），说明这不是某个版本的回归，而是持续存在的兼容性问题。
• 开发者若手上没有多显示适配器环境，可安装任意 IDD 类虚拟显示器驱动，使系统存在 2 个以上 ROOT\DISPLAY 设备后再尝试复现。
• 建议在 Electron 层显式指定 GPU 选择策略，或在检测到 GPU 进程反复失败时主动 fallback，而非依赖 Chromium 默认行为。

[lovemakerr]

我也是同样问题，环境不同但现象一致：

• CPU: AMD Ryzen 7 6800HS (Radeon 680M 核显)
• 系统: Windows 11 (26200)
• 显卡驱动: AMD Adrenalin 26.8.1 (WHQL，已是最新)
• dsh 桌面端版本: 0.2.0-rc.2

错误日志：
GPU process exited unexpectedly: exit_code=-2147483645
（连续 9 次后）
FATAL: GPU process isn't usable. Goodbye.

已尝试全部无效：
--disable-gpu / --use-angle=swiftshader / ELECTRON_DISABLE_GPU=1 / 更新最新驱动 / 关硬件加速 GPU 计划

补充：CLI 版 npx @deepseek-ai/dsh web 完全正常，只有 Electron 桌面端崩。

[2DogsLee]

同款硬件复现成功（0.2.0-rc.2 win-x64），补充两个证据点

环境

项目	值
CPU	Intel(R) Core(TM) Ultra 5 125H（与楼主同款）
GPU	Intel(R) Arc(TM) Graphics，PCI\VEN_8086&DEV_7D55（与楼主同一设备 ID，SUBSYS 不同），驱动 32.0.101.8331（2026-01-29，比楼主新）
OS	Windows 11 x64
版本	0.2.0-rc.2（官网安装包，装到 D:\某英文目录\）
虚拟显示器	无（楼主环境有 2 个 IDD 虚拟显示器，我没有，仍然复现——说明虚拟显示器不是必要条件，这颗 Arc 核显本身就是诱因）

证据 1：主进程退出码与楼主日志签名一致

PowerShell Start-Process -PassThru 无参数启动，主进程约数秒内退出：

ExitCode = -2147483645   # 0x80000003 (STATUS_BREAKPOINT)

与楼主贴的 GPU process exited unexpectedly: exit_code=-2147483645 完全一致。且 stdout/stderr 重定向到文件后均为空，印证了"诊断输出用户拿不到"的问题。

证据 2：叠加发现——单实例锁冲突时应用会"零反馈静默退出"（另一个独立问题）

当机器上同时运行着旧版桌面端（0.2.0-rc.1，共用用户数据目录 %APPDATA%\dsh-desktop）时，新实例即使带 --no-sandbox 也会退出码 0 静默退出，无任何窗口、无任何对话框。用 --enable-logging --log-file=... 才抓到：

[ERROR:chrome\browser\process_singleton_win.cc:318] Lock file can not be created: 拒绝访问。 (0x5)

即旧实例持有 %APPDATA%\dsh-desktop\lockfile，新进程创建单实例锁被拒后直接退出。对普通用户来说这和"软件坏了"完全无法区分。

建议（在楼主 4 条基础上追加）

• 单实例锁冲突 / GPU 初始化失败这两种退出路径，都应该给出可见的错误提示（或弹导引），而不是静默退出；
• GPU 崩溃场景下 --no-sandbox 能救（楼主已验证），但应用没有暴露任何"禁用硬件加速"的持久化开关，普通用户无法自救。

--no-sandbox 在干净环境（退出所有 DSH 实例）下的验证因上述锁冲突尚未完成，完成后我会补充结果。

[zermello]

The fact that the process exits almost immediately and that the diagnostic information only goes to stdout makes the first problem observability rather than the exact GPU failure.

I’d try launching the executable from a terminal instead of the normal shortcut so the Electron/Chromium stderr/stdout output remains visible.

I’d also test whether disabling GPU acceleration changes the behavior. If the application starts with GPU acceleration disabled, that would strongly narrow the issue to Chromium/Electron GPU initialization rather than the application startup sequence itself.

For example, depending on how the packaged application exposes Chromium arguments, testing with a GPU-disabled launch option can help isolate the problem.

Because the environment includes Intel Arc and multiple virtual displays, I’d also compare:

Intel Arc + virtual displays + GPU acceleration
Intel Arc + virtual displays + GPU disabled
Intel Arc + one physical display + GPU acceleration

The goal is to identify whether the failure follows the GPU, the virtual-display configuration, or Electron’s GPU process initialization.

For the application itself, writing startup diagnostics to a persistent log file would also make this class of failure much easier for users to diagnose because a normal desktop launch doesn’t expose stdout.

If this clears up the issue, please consider marking the answer as accepted so others who run into the same problem can find the solution more easily.