claude-code - 💡(How to fix) Fix [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 [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52539Fetched 2026-04-24 06:04:28
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Participants
Timeline (top)
labeled ×2unlabeled ×1

Error Message

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. 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. 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. No Windows Error Reporting entries (Event ID 1000) generated. No crash dialog. No user-facing error of any kind. 3. Observe: no window appears, no error, no sound

  • Exception address 0x10000007354 — outside all loaded module ranges, consistent with a crash in dynamically-allocated GPU process memory (heap or JIT region)

Root Cause

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.

Fix Action

Fix / Workaround

  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

Code Example

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.

---

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

---

"%LOCALAPPDATA%\AnthropicClaude\claude.exe" --disable-gpu
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • 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:

FieldValue
Claude Desktop version1.3883.0.0
Install methodDirect download from claude.ai/download (Squirrel/NSIS installer)
Install path%LOCALAPPDATA%\AnthropicClaude\claude.exe
OSWindows 11 24H2, Build 26100
Architecturex64
GPUIntel integrated graphics

Relationship to Prior Closed Issues:

#25801 / #45031This issue
Install methodMSIX (Windows Store)Direct download (Squirrel/NSIS)
GPUNVIDIA RTX 4080/4090Intel integrated graphics
SymptomWindow opens, content blackWindow never appears at all
GPU process stateRuns, compositing failsCrashes before renderer spawns
--disable-gpu accessibleNo — MSIX ignores env varsYes — 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.

extent analysis

TL;DR

The issue can be temporarily worked around by launching Claude Desktop with the --disable-gpu flag, which suggests a GPU subprocess crash is the root cause.

Guidance

  • Verify the GPU subprocess crash by checking if launching with --disable-gpu resolves the issue, as it did for the reporter.
  • Consider implementing an automatic GPU crash fallback, similar to Chrome's gpu_crash_count behavior, to retry launching with --disable-gpu if the GPU subprocess fails.
  • Adding a Hardware Acceleration toggle in the Settings UI could provide users with a workaround and improve overall user experience.
  • Investigate respecting ELECTRON_EXTRA_LAUNCH_ARGS in the MSIX build to address the MSIX packaging limitation.

Example

No specific code example is provided due to the nature of the issue, but the command to launch Claude Desktop with GPU disabled is:

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

Notes

The issue seems to be related to Electron's GPU subprocess failing on Windows 11, and Claude Desktop lacks a fallback or error handling for this scenario. The provided minidump analysis and diagnostic steps suggest a crash in the GPU process before logging initializes.

Recommendation

Apply the workaround by launching with --disable-gpu until a more permanent fix, such as an automatic GPU crash fallback or a Hardware Acceleration toggle, can be implemented. This is because the workaround is confirmed to resolve the issue and provides a temporary solution for users affected by the GPU subprocess crash.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING