← Reddit

Claude Desktop launches (process visible) but window never appears on Windows 11 — Workaround with --disable-gpu but need a permanent solution

Reddit · Sea-Cycle-2747 · April 23, 2026
A Claude Desktop user on Windows 11 experienced the application launching as a running process but failing to display any window, which was traced to silent GPU subprocess crashes. The --disable-gpu launch flag resolved the issue and allowed the application to run normally, though the user sought a permanent solution rather than a workaround. Investigation also revealed potential interference from Acronis Cyber Protect's DeviceLock component, which injected DLLs into the Claude process and hooked critical Windows APIs used by Electron's V8 engine.

Detailed Analysis

A Windows 11 user running Claude Desktop version 1.3883.0.0 on Build 26100 (24H2) documented a silent launch failure in which the application's process spawned correctly — with one parent and two child `claude.exe` instances visible in Process Explorer — but no window, splash screen, or error message ever appeared. The troubleshooting process unfolded in two distinct phases. First, analysis of a captured minidump revealed that Acronis Cyber Protect's DeviceLock component had injected three DLLs into the Claude process, including `DLForeignProcHlp_x64.dll`, `DLDrvUserMode64.dll`, and `FreeImage_x64.dll`. These modules were hooking critical Windows NT APIs — `ZwMapViewOfSection`, `ProtectVirtualMemory`, `LoadLibraryExW`, and `ZwCreateFile` — that Electron's V8 JavaScript engine relies on heavily for JIT compilation. Disabling Acronis entirely and performing a clean reinstall eliminated the DLL injection but did not restore the window, pointing to a second, independent fault. Launching the application with the `--disable-gpu` flag from PowerShell immediately produced a functional window, identifying GPU hardware acceleration as the remaining root cause.

The two-layer nature of this failure is diagnostically significant. The Acronis DeviceLock injection represents a well-documented class of conflict between enterprise Data Loss Prevention software and Electron-based applications. Because Electron wraps a Chromium browser engine, its V8 JIT compiler maps executable memory, loads shared libraries dynamically, and performs frequent virtual memory operations — precisely the API surface that DLP hooks intercept to scan for data exfiltration. Notably, the user reports that no DLP policies were actively configured, meaning the injection was occurring by default as part of Acronis's baseline monitoring behavior. This has broader implications for enterprise environments: Claude Desktop, like other Electron applications including Slack, VS Code, and Microsoft Teams, may silently degrade or fail entirely on machines running aggressive endpoint security tools, even when no explicit blocking rules are in place.

The GPU-specific failure that persisted after removing Acronis aligns with a pattern documented across multiple GitHub issues in Anthropic's repositories and on Windows 11 builds in the 25H2 and 26H2 timeframe. The root mechanism appears to be a GPU subprocess crash occurring before Claude Desktop's own logging system initializes — which explains the empty logs folder the user found under the application's isolated AppData container. Because the crash happens prior to log initialization, standard diagnostic channels yield nothing, making this category of failure particularly opaque to end users. The `--disable-gpu` flag forces Electron to fall back to software rendering, bypassing the GPU process entirely and allowing the rest of the application to launch normally. Research context suggests this may be specifically tied to ARM64 window rendering bugs on certain Windows 11 configurations, though the user's post does not specify CPU architecture.

The absence of a permanent, user-accessible solution reflects a structural limitation in how Claude Desktop is distributed and configured on Windows. Because the application is packaged as an MSIX Windows Store app, its installation directory resides in a protected `WindowsApps` folder, and there is no documented mechanism for persistently injecting launch flags the way Chrome or other Chromium-based browsers support a `chrome-flags.conf` or equivalent. The user's workaround — launching via a PowerShell command with `--disable-gpu` appended — requires manual intervention on every session or the creation of a custom batch file or shortcut, neither of which represents a robust long-term solution. Anthropic's GitHub issue tracker contains multiple filed reports corresponding to this symptom, and the research context indicates the fix is developer-dependent, requiring either a patched release or the addition of an in-app hardware acceleration toggle analogous to what many Electron applications expose in their settings menus.

This case illustrates two converging pressures on AI desktop client deployments as they move into enterprise and power-user environments. First, the DLP injection problem signals that Anthropic will need to engage more explicitly with the enterprise security software ecosystem — whether through documented exclusion guidance for tools like Acronis, or through hardening the Claude Desktop process against hook-based injection that disrupts Electron's runtime. Second, the GPU rendering failure underscores a known fragility in Electron's Chromium GPU process architecture on Windows, where driver incompatibilities or OS-level rendering changes can silently kill the entire application UI without surfacing any actionable diagnostic output. As Claude Desktop gains adoption beyond early adopters into corporate IT environments, the combination of silent failures, empty logs, and no persistent configuration mechanism for workaround flags represents a meaningful barrier to reliable deployment at scale.

Read original article →