**一句话
在 Windows 11 上，以普通权限启动 DSH Desktop 必然崩溃（EXCEPTION_BREAKPOINT，126–145 ms 内退出，不产生任何日志）；在 Windows 8 兼容模式下以管理员身份启动则完全正常。DSH Desktop版本：0.10.0
**⚠️ 唯一可用的启动方式（实测）
本机目前只有一个组合能成功启动：
| # |
条件 |
结果 |
| 1 |
开启「Windows 8」兼容模式 |
|
| 2 |
以管理员身份运行 |
|
|
1 + 2 同时满足 |
✅ 能启动（用户日常唯一可用的方式） |
|
只双击（是否开兼容模式都一样） |
❌ 无任何反应 |
|
只以管理员身份运行（不开兼容模式） |
❌ 弹出 ERR_ABORTED 错误框后失败（见"图一"症状） |
这说明问题不是单一因素：兼容模式与提权缺一不可。
单独开启兼容模式 + 普通权限双击，已实测仍然崩溃（详见下文「新增发现」E 节），所以兼容模式本身不能替代提权。
补充：兼容模式是用户在故障出现后自行添加的排查手段。据用户陈述，故障发生前两天（安装后）不需要兼容模式即可正常使用，因此在正常安装状态下本不应依赖它。
环境
| 项目 |
值 |
| OS |
Windows 11 10.0.26200 |
| 安装目录 |
D:\AAADSH\DSH Desktop |
| 版本 |
DSH Desktop 0.10.0（DSH Desktop.exe 文件版本 0.10.0） |
| 签名 |
有效，CN="Beijing Shuju Xiangsu Intelligence Technology Co., Ltd." |
| 实时防护 |
火绒（联想版）+ Windows Defender 同时开启 |
| 内核隔离 |
VBS + HVCI 已开启（HvciEnabled,HvciStrictMode） |
| 卸载的 Electron fuses |
EnableEmbeddedAsarIntegrityValidation = 关闭；LoadBrowserProcessSpecificV8Snapshot = 关闭；RunAsNode = 开启 |
复现步骤
- 彻底退出 DSH Desktop（确保无任何
DSH Desktop.exe 进程）
- 直接双击桌面快捷方式（不要用"以管理员身份运行"）
- 结果：没有任何窗口、没有任何提示、也没有任何日志
用探针脚本以 Start-Process -PassThru 捕获到的精确行为：
本脚本权限: 普通用户（非管理员）
harness.log 行数 = 320
DSH 进程数 = 0
lockfile 存在 = 否
[正常] Start-Process 成功，pid = 3056
结果: 进程退出，存活 126 毫秒
profile 首个变化: (无任何变化)
lockfile 出现: False session.json 出现: False harness.log 新增: 0
stderr:
Received fatal exception EXCEPTION_BREAKPOINT
DSH Desktop!electron::fuses::IsLoadBrowserProcessSpecificV8SnapshotEnabled [0x7ff7863cc529+259]
DSH Desktop!v8::ScriptCompiler::CreateCodeCacheForFunction [0x7ff7863cbf32+33d82]
DSH Desktop!v8::CTypeInfoBuilder<double>::MergeFlags [0x7ff7862acacd+245d]
DSH Desktop!v8::CTypeInfoBuilder<double>::MergeFlags [0x7ff7862abf97+1927]
DSH Desktop!v8::CTypeInfoBuilder<double>::MergeFlags [0x7ff7862aba7f+140f]
DSH Desktop!uv_cond_signal [0x7ff786175562+36ac2]
KERNEL32!BaseThreadInitThunk [0x7ffe07a8e957+17]
ntdll!RtlUserThreadStart [0x7ffe08a0ad6c+2c]
退出码 = -2147483645 = 无符号 2147483651 = 0x80000003 STATUS_BREAKPOINT。
注意：崩溃发生在 libuv/V8 线程上，且 %APPDATA%\dsh-desktop 里一个文件都没有被创建或修改（没有 lockfile、没有 desktop-service\session.json、没有 chrome_debug.log、harness.log 新增 0 行）—— 说明它在 Chromium 初始化之前就死了。
参数对比（同一台机器、同一时刻、都是普通权限）
| 启动参数 |
存活 |
结果 |
| （无） |
126 ms |
EXCEPTION_BREAKPOINT |
--disable-gpu-sandbox |
145 ms |
EXCEPTION_BREAKPOINT |
--no-sandbox |
441 ms |
不崩溃，走到 JS 单实例检查，Chromium 报 Lock file can not be created! Error code: 5，然后正常退出（码 0） |
--no-sandbox --disable-gpu --disable-gpu-compositing |
397 ms |
同上一行 |
结论：崩溃点在 Chromium 的"进程沙箱"初始化路径上，不是 GPU 沙箱、不是 GPU。
[5768:0930/110138.119:ERROR:chrome\browser\process_singleton_win.cc:446] Lock file can not be created! Error code: 5
[desktop] Another instance is already running; focusing existing window and exiting.
已排除的可能（都做了直接验证）
| 假设 |
验证方法 |
结论 |
| 文件 ACL 只授权 Administrators，普通令牌读不到 |
Get-Acl 遍历 exe / app.asar / resources / userData；并用受限令牌实测创建、写入、删除、以及对管理员创建的文件做 CREATE_ALWAYS |
全部成功 → 排除 |
| 缺少强制完整性标签以外的权限 |
icacls（无 Mandatory Label） |
排除 |
| 用户令牌被 UAC 降权导致 |
受控对照实验（%TEMP% 对照 + userData 主测） |
均通过 → 排除 |
| exe 清单要求提权 |
解析 PE manifest = level="asInvoker" |
排除 |
| IFEO 劫持 |
HKLM\...\Image File Execution Options 无 DSH 项 |
排除 |
环境变量污染（ELECTRON_RUN_AS_NODE 等） |
HKCU/HKLM 持久环境变量 |
无 → 排除 |
| Crashpad 吞掉了崩溃 |
app.asar 内无 crashReporter 引用；全盘无 .dmp |
排除 |
| WER 记录了崩溃 |
WerSvc 当时是停止状态（现已确认），故无事件、无转储 |
解释了空白，不是原因 |
| GPU 降级阶梯写入脏参数 |
%APPDATA%\dsh-desktop\gpu-fallback.json 不存在 → level=default → 不追加任何开关 |
排除 |
| 杀软主动拦截 |
查询火绒 log.db / applog.db / hips.db / wlfile.db，无任何针对 DSH 的拦截记录；该目录也已在火绒信任区（TrustRegion_60.fn = D:\AAADSH） |
未见证据 |
| 安装了多个版本 / 快捷方式被改 |
桌面 + 开始菜单两个 .lnk 都指向同一 exe，RunAsUser = False；任务栏无固定项 |
排除 |
| Windows 8 兼容模式单独能否解决 |
保持 ~ WIN8RTM 兼容模式 + 普通权限双击 |
仍以完全相同的方式崩溃 → 兼容模式单独无效，必须与提权配合 |
| 是瞬时状态，重启可恢复 |
完整冷启动后重测 |
仍崩溃 → 排除 |
| 火绒防护开关 |
在"防护已关闭"（安全中心记录 SECURITY_PRODUCT_STATE_OFF）状态下重测 |
仍崩溃 → 主动防护排除 |
**一句话
在 Windows 11 上，以普通权限启动 DSH Desktop 必然崩溃（
EXCEPTION_BREAKPOINT，126–145 ms 内退出，不产生任何日志）；在 Windows 8 兼容模式下以管理员身份启动则完全正常。DSH Desktop版本：0.10.0**⚠️ 唯一可用的启动方式（实测）
本机目前只有一个组合能成功启动：
ERR_ABORTED错误框后失败（见"图一"症状）这说明问题不是单一因素：兼容模式与提权缺一不可。
单独开启兼容模式 + 普通权限双击，已实测仍然崩溃（详见下文「新增发现」E 节），所以兼容模式本身不能替代提权。
环境
D:\AAADSH\DSH DesktopDSH Desktop.exe文件版本 0.10.0）HvciEnabled,HvciStrictMode）EnableEmbeddedAsarIntegrityValidation= 关闭；LoadBrowserProcessSpecificV8Snapshot= 关闭；RunAsNode= 开启复现步骤
DSH Desktop.exe进程）用探针脚本以
Start-Process -PassThru捕获到的精确行为：退出码 = -2147483645 = 无符号 2147483651 = 0x80000003 STATUS_BREAKPOINT。
注意：崩溃发生在 libuv/V8 线程上，且
%APPDATA%\dsh-desktop里一个文件都没有被创建或修改（没有lockfile、没有desktop-service\session.json、没有chrome_debug.log、harness.log新增 0 行）—— 说明它在 Chromium 初始化之前就死了。参数对比（同一台机器、同一时刻、都是普通权限）
--disable-gpu-sandbox--no-sandboxLock file can not be created! Error code: 5，然后正常退出（码 0）--no-sandbox --disable-gpu --disable-gpu-compositing结论：崩溃点在 Chromium 的"进程沙箱"初始化路径上，不是 GPU 沙箱、不是 GPU。
已排除的可能（都做了直接验证）
Get-Acl遍历 exe / app.asar / resources / userData；并用受限令牌实测创建、写入、删除、以及对管理员创建的文件做CREATE_ALWAYSicacls（无 Mandatory Label）%TEMP%对照 + userData 主测）level="asInvoker"HKLM\...\Image File Execution Options无 DSH 项ELECTRON_RUN_AS_NODE等）crashReporter引用；全盘无.dmpWerSvc当时是停止状态（现已确认），故无事件、无转储%APPDATA%\dsh-desktop\gpu-fallback.json不存在 → level=default → 不追加任何开关log.db/applog.db/hips.db/wlfile.db，无任何针对 DSH 的拦截记录；该目录也已在火绒信任区（TrustRegion_60.fn = D:\AAADSH）RunAsUser = False；任务栏无固定项~ WIN8RTM兼容模式 + 普通权限双击SECURITY_PRODUCT_STATE_OFF）状态下重测