[Bug] Claude Desktop — GPU subprocess silent crash, window never renders on launch (direct install, Intel iGPU, Win11 24H2) — related to #25801 and #45031, both closed without resolution

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: This is a Claude Desktop (Windows) bug, not a Claude Code CLI issue. Filed here as there is no dedicated Claude Desktop issues repo. Two prior reports of related GPU rendering failures (#25801 and #45031) were labeled invalid and closed without fix or acknowledgment. This issue documents a distinct but related failure mode on the direct download installer (not MSIX), with full diagnostic evidence, and explicitly requests it not be dismissed without resolution.

---

Claude Desktop launches silently with no window on Windows 11 24H2. The main process and two child processes are visible in Task Manager and consume memory normally, but no BrowserWindow is ever created. The app produces no error, no crash dialog, and writes nothing to its log files. Passing --disable-gpu at launch resolves the issue completely, confirming the GPU subprocess crashes silently before the renderer initializes.

Environment:

| Field | Value |
|---|---|
| Claude Desktop version | 1.3883.0.0 |
| Install method | Direct download from claude.ai/download (Squirrel/NSIS installer) |
| Install path | %LOCALAPPDATA%\AnthropicClaude\claude.exe |
| OS | Windows 11 24H2, Build 26100 |
| Architecture | x64 |
| GPU | Intel integrated graphics |

---

Relationship to Prior Closed Issues:

| | #25801 / #45031 | This issue |
|---|---|---|
| Install method | MSIX (Windows Store) | Direct download (Squirrel/NSIS) |
| GPU | NVIDIA RTX 4080/4090 | Intel integrated graphics |
| Symptom | Window opens, content black | Window never appears at all |
| GPU process state | Runs, compositing fails | Crashes before renderer spawns |
| --disable-gpu accessible | No — MSIX ignores env vars | Yes — shortcut flag works |

The common thread across all three reports: Electron's GPU subprocess fails on Windows 11, and Claude Desktop has no fallback, no user-facing error, and no built-in way to disable hardware acceleration.

What Should Happen?

Claude Desktop renders its main application window on launch regardless of GPU subprocess state. If the GPU subprocess fails, the app should either:

1. Automatically retry with --disable-gpu — mirroring Chrome's gpu_crash_count fallback behavior, or
2. Surface a visible error explaining why the window did not appear, with an option to relaunch in software rendering mode

Currently the failure is completely invisible — the process runs in memory but the user has no indication the app is running, has crashed, or what to do. There is no error dialog, no notification, and no log output. This is a significant UX failure on top of the underlying GPU crash.

Error Messages/Logs

No error messages or logs produced.

Log files at %APPDATA%\Claude\logs\ are completely empty — the crash occurs before logging initializes.
No Windows Error Reporting entries (Event ID 1000) generated.
No crash dialog. No user-facing error of any kind.
The process runs normally in Task Manager with no visible failure signal.

Steps to Reproduce

1. Install Claude Desktop 1.3883.0.0 via direct download from claude.ai/download (Squirrel/NSIS installer)
2. Launch via Start menu shortcut or desktop icon
3. Observe: no window appears, no error, no sound
4. Open Task Manager or Process Explorer
5. Observe: one parent claude.exe + two child claude.exe processes running and consuming memory
6. Wait indefinitely — window never appears

Process tree at failure:

claude.exe               ← main/browser process — running, no window
  ├── claude.exe         ← --type=gpu-process (crashes silently)
  └── claude.exe         ← --type=utility
  [--type=renderer never spawns]

Confirmation test (run after killing all claude.exe processes):

"%LOCALAPPDATA%\AnthropicClaude\claude.exe" --disable-gpu

Window appears immediately — confirms GPU subprocess crash as root cause.

Diagnostic steps already performed (all negative except --disable-gpu):

• Clean reinstall from direct download — issue persists
• %APPDATA%\Claude cleared — issue persists
• Confirmed not network/firewall related
• Log files checked — completely empty (pre-logging crash)
• Acronis Cyber Protect fully disabled — issue persists as distinct GPU crash
• --no-sandbox flag — no change
• --disable-gpu flag — window appears immediately ✓

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — Claude Desktop 1.3883.0.0 (not Claude Code CLI)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Minidump Analysis (captured via Process Explorer on version 1.2581.0.0):

• Exception address 0x10000007354 — outside all loaded module ranges, consistent with a crash in dynamically-allocated GPU process memory (heap or JIT region)
• 78 modules loaded at capture time
• Log files completely empty at capture — crash precedes logging initialization

---

Requested Fixes — any one resolves this class of issue across all three reports:

1. Automatic GPU crash fallback — if GPU subprocess fails on init, retry with --disable-gpu before giving up (Chrome already does this via gpu_crash_count in local state)
2. Hardware Acceleration toggle in Settings UI — single checkbox, works for MSIX and direct install users alike (Discord implements this identically)
3. Read %APPDATA%\Claude\electron-flags.conf — low-effort, immediately unblocks MSIX users who currently have no workaround
4. Respect ELECTRON_EXTRA_LAUNCH_ARGS in MSIX build — fixes the MSIX packaging limitation documented in #25801 and #45031

---

Secondary issue — Acronis Cyber Protect DLL injection (separate, included for visibility):

Acronis DeviceLock component injects three DLLs into the Claude process by default (even with zero DLP policies configured), hooking ZwMapViewOfSection, ProtectVirtualMemory, and LoadLibraryExW. This caused a separate crash on v1.2581.0.0. Confirmed injected DLLs from minidump:

• C:\Program Files\BackupClient\DeviceLock\DLForeignProcHlp_x64.dll
• C:\Program Files\BackupClient\DeviceLock\DLDrvUserMode64.dll
• C:\Program Files\BackupClient\DeviceLock\FreeImage_x64.dll

Injection is kernel-level — stopping the user-mode service (DLPService.exe) does not eject the DLLs. Machine reboot required after disabling the driver (DLDrv). Corporate users running Acronis Cyber Protect should be aware of this as an additional failure vector independent of the GPU crash.

---

Note on Issue Tracker:
Both #25801 and #45031 were closed as invalid / not planned without any fix, redirect, or acknowledgment from the desktop team. If a dedicated Claude Desktop bug tracker or feedback channel exists, please link it so future reporters can be directed there rather than having legitimate bugs silently dismissed.