Claude Desktop (Windows) crashes repeatedly during Browser-pane screenshot verification, then fails to relaunch

Reproduced this again today under a controlled test, and this time captured full forensics that weren't available for the original report yesterday.

Environment: unchanged — Claude Desktop MSIX v1.24012.9.0, Windows 11 Pro 10.0.26200, Intel UHD Graphics (driver 32.0.101.7085), 16GB RAM.

Timeline (from main.log / unknown-window.log, local time):

• Internal (non-agent) preview-thumbnail capture failed 4x over ~13s: Screenshot timed out after 5s: the Browser pane is not displayed, so the page is not compositing frames.
• ~78s later, renderer console floods with WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat (a dozen+ in one tick).
• GPU child process reported crashed: reason: 'crashed', exitCode: 101457950 (0x60C201E).
• main.log stops logging entirely — the app does not recover and needs a manual relaunch.

New: a Crashpad .dmp was captured this time (yesterday's crashes left zero WER/EventLog/Crashpad traces). Parsed directly from the minidump streams (no debugger/symbols available):

• ExceptionCode: 0x80000003 (EXCEPTION_BREAKPOINT) — not an access violation / driver fault.
• Faulting module: Claude.exe itself, offset +0x6DD36F9.
• Crashing thread: CrBrowserMain — the main UI thread of the browser process, not the GPU child process.

So this isn't just the GPU child process dying — the browser process's own main thread hits a deliberate CHECK()/IMMEDIATE_CRASH()-style breakpoint trap within ~1s of the GPU process crash, which is why the whole app goes down hard instead of transparently recovering with a fresh GPU process (normal/expected Chromium behavior on GPU-process loss).

Trigger, more specifically: a step-by-step log kept during today's test (each risky action logged before it ran, so the last line identifies what was in flight at crash time) shows the fatal action was a Browser-pane viewport resize (resize_window) — the repro never even reached the screenshot step. Scrolling immediately prior used ref-based scrolling and completed fine.

Updated theory: any operation forcing the Browser pane's GPU compositing surface to reallocate (resize, and presumably screenshot too) is unstable here, especially when the compositor is already destabilized by the app's own internal preview-capture failing on an occluded/hidden pane.

Happy to share the raw .dmp/logs if useful — this is integrated Intel graphics, reinforcing that this isn't NVIDIA/HDR-specific.

Update: corrected timeline, and ruled out one hypothesis.

I initially guessed this was a silent Windows Store background update. That was wrong — the reinstall was manual, from the claude.ai/claude.com download page (confirmed via the AppX deployment log: source URL was downloads.claude.ai, not the Store CDN).

Corrected full sequence:

1. Weeks of stable use on an earlier build.
2. 2026-07-27 morning: the in-app "Relaunch to get changes" prompt appeared. Clicked it after finishing a session, started a new session — crashes began almost immediately, 3x in that session (app also failed to restart at one point).
3. Used claude.ai in the browser to get help; recovered in-progress work via the CLI (commit/push).
4. Followed instructions to fully clear the app and reinstall from the download page — this reinstalled the same version, 1.24012.9.0.
5. Crash reproduced twice more that same day, on the clean install.
6. Reproduced again the next day in a deliberate repro (see previous comment) — still the same clean install.

Checked just now: https://claude.ai/api/desktop/win32/x64/setup/latest/redirect still resolves to .../releases/win32/x64/1.24012.9/ClaudeSetup-...exe — no newer build has been published, so there's no update-based workaround available yet.

Since a full data wipe + clean reinstall of the same build still crashes reliably, this rules out stale per-user cache/state as the cause — it points to a regression in build 1.24012.9.0 itself, reproducible from a completely fresh install with zero local state.

Reproduced again today (2026-07-30), same exact signature as my 2026-07-28 comment — third confirmed recurrence now, and this one narrows the trigger further.

Context: doing manual auth testing for a new "assign/revoke superuser role" feature in an unrelated app. Desktop's own embedded Preview feature (not a CLI/agent computer{screenshot} or resize_window call — this is Desktop's built-in "run + embedded browser" mechanism) started a local dev server and navigated its embedded pane to http://localhost:3100 so I could manually complete a CAPTCHA-gated login. I then left that pane in the background, unfocused, for about 20 minutes while doing unrelated work in the chat (editing an env var via a PowerShell tool call).

Log timeline (main.log):

• 12:32:41 — Preview server started, pane navigated to http://localhost:3100
• 12:32:48 — [Preview] navigatePreview failed logged with an empty error: '' string (separate glitch, right after the pane was created — didn't itself crash anything)
• 12:32:58 and 12:37:30 — two rounds of [Preview] capturePreviewScreenshot failed: Screenshot timed out after 5s: the Browser pane is not displayed, so the page is not compositing frames — harmless at this point, just warnings, confirming the pane was already backgrounded well before the fatal event
• 12:52:42 — the same warning fires again, but this time immediately followed by a flood of WebGL: INVALID_ENUM: getInternalformatParameter: invalid internalformat, then GPU process gone { reason: 'crashed', exitCode: 101457950 } — the identical exitCode from my 2026-07-28 report

Crashpad dump captured this time too (32ef5588-20ce-40d1-af05-e7f0256cf6e3.dmp), same as before — happy to share it if useful.

What's new here vs. my earlier comments: no explicit computer{screenshot} or resize_window tool call was in flight when this one hit — the only thing happening in the chat was an unrelated PowerShell tool-permission approval. So the trigger doesn't require an agent action on the pane at all: simply leaving a live dev-server tab open and unfocused in the embedded Preview/Browser pane for an extended period (~20 min here) is sufficient on its own to eventually retrigger the internal periodic preview-thumbnail capture path into a WebGL flood and GPU crash.

This is now three separate incidents (2026-07-27, 2026-07-28, 2026-07-30) with the exact same GPU exitCode and the exact same capturePreviewScreenshot failed → WebGL INVALID_ENUM flood → GPU process gone signature, on the same build (still 1.24012.9.0, confirmed no newer build published). Given how reproducible and disruptive this is (repeated full chat-history loss on relaunch), it'd help a lot to know: is there a near-term mitigation possible, e.g. backing off/disabling the periodic preview-thumbnail capture entirely while the pane isn't visible, rather than retrying it into a crash? Or exposing the "disable hardware acceleration" toggle that isn't currently in Desktop settings?

In the meantime I've had to fully disable use of the embedded Browser/Preview pane for this project (agent instructions updated to route all manual/visual verification through a separate real Chrome window instead) — happy to keep reporting new data points here as they come in.

Additional data point that rules out a few theories in this thread.

Same package, different vendor: Claude Desktop 1.24012.9.0 (MSIX Claude_1.24012.9.0_x64__pzs8sxrjxfjjc), Windows 11 Home Single Language 10.0.26200. Acer Swift Edge 16 (SFE16-42), Ryzen 5 7535U with Radeon 660M integrated graphics, 3840x2400 display, 16 GB RAM.

Driver age is not the cause. I hit this on AMD driver 32.0.21043.1005 (dated 2026-02-18), then did a clean Factory Reset install of Adrenalin 26.7.1 -> 32.0.21045.1000 (dated 2026-07-23), rebooted, and pinned it against Windows Update. The crash reproduces identically on the current driver. Combined with the Intel report here and the NVIDIA reports linked above, that's three vendors.

Browser choice is not the cause. I originally drove my own installed browser (Brave) rather than the Browser pane, because I needed my signed-in session for QA. Crash occurred. I then retried the same task restricted to Claude Code's internal browser only. Identical crash. Both paths die the same way, which points at the result-rendering path rather than at whichever browser is being driven.

Symptom chain: GPU process dies during an in-page browser action in a Claude Code session -> entire app exits instantly -> Windows flags the MSIX package as damaged ("go to advanced options for Claude and select Repair"). Repair restores the package but does not prevent recurrence.

No mitigation available. Confirming the request in the OP: there is no hardware-acceleration toggle in Desktop settings, the MSIX app-execution alias drops arguments, and ELECTRON_EXTRA_LAUNCH_ARGS is not honored. Launching the versioned exe directly with --disable-direct-composition is blocked by WindowsApps ACLs regardless of elevation. So on an MSIX install there is currently no way for an affected user to work around this.

Same build, same Windows build, and a crash during Browser-pane preview use — but on a current NVIDIA driver, and with no GPU fault logged anywhere. Details below in case the difference is useful.

Claude Desktop: 1.24012.9 (03c61d), 2026-07-24 (MSIX)
OS: Windows 10.0.26200 — same build as the original report
GPU: hybrid — Intel UHD Graphics (32.0.101.6790, 2025-04-28) and NVIDIA GeForce RTX 4070 Laptop

Driver update did not fix it

I updated the NVIDIA driver to 32.0.16.1088 (2026-07-22, Studio branch), up from 32.0.15.5597 (2024-05-29), and the app crashed again roughly 16 minutes later. The Intel iGPU driver is still at 32.0.101.6790 (2025-04-28), so that's not ruled out — but the discrete GPU being on a twelve-day-old driver didn't help.

Trigger matches

The crash happened while using the preview / Browser pane, which is consistent with the screenshot-capture path in the original report. Auto-verify runs that after every edit, so frontend sessions get disproportionate exposure to it.

Time of death, from the one log that recorded it

C:\ProgramData\Claude\Logs\cowork-service.log:

13:31:24.732  [Server] Client connected: exe=claude.exe
13:32:39.546  [Server] Persistent RPC: connection ended: failed to read length: EOF
13:32:43.955  Service stop requested

The VM service sees EOF on the named pipe — claude.exe stopped being on the other end — about 75 seconds into the session. The service then shuts down cleanly. Caveat: EOF alone doesn't distinguish a crash from a normal quit; what makes it a crash is that the window vanished with no dialog and no in-session error.

Windows records nothing

Across a 14-day window, for this app, there is no entry in:

• Application Error, Application Hang, or Windows Error Reporting providers
• WER report archives under %LOCALAPPDATA%\Microsoft\Windows\WER (searched by content)
• Win32_ReliabilityRecords
• any .dmp under the package directory

No nvlddmkm, dxgkrnl, or igfx events near the crash either, so no display-driver timeout/reset. And the app itself writes no log to disk — nothing under %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc, and nothing at all was written under the package directory in the ten minutes around the crash.

The only artifact on the machine is cowork-service.log, written by a component that reports its own clean shutdown.

Why that matters for this thread

A process that terminates with no Windows-level fault, no dump, and no application log is one that can only ever be reported anecdotally. That may be why these reports keep arriving as correlations rather than diagnoses.

Requests, seconding and extending the original:

1. A hardware-acceleration toggle, or support for an Electron flags file, on Windows — still the only way for users to test whether compositing is involved.
2. Persist Electron main-process and renderer logs to disk under the MSIX write-redirect target, so crashes leave an artifact worth attaching.
3. Specifically instrument the Browser pane's screenshot capture, since it's now the common trigger across at least two configurations.

Happy to run anything else useful.

Same crash on Windows 10 Pro 22H2 (10.0.19045), Claude Desktop 1.24012.9.0 (MSIX), so this is not limited to Windows 11 / build 26200. Adding data that narrows down what actually corrupts the package.

Reproduction: every occurrence was triggered by the in-app Browser pane — preview start → get page text → computer {action: "screenshot"}. Three separate occurrences, three identical triggers. The app dies instantly and afterwards shows "Bu uygulama açılamıyor" / "This app can't open".

Key finding: the package files are not modified at all

I took a full recursive snapshot of C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc (2225 entries: path, size, LastWriteTime) immediately after a clean repair, when Get-AppxPackage reported Status: Ok. After the next crash the package reported Status: Modified, NeedsRemediation — and the snapshot diff was:

EKLENEN (added) : 0
SILINEN (removed) : 0
DEGISEN (changed) : 0
Root folder LastWriteTime: unchanged

Not one byte, timestamp or entry differs. Microsoft-Windows-AppXDeploymentServer/Operational contains no deployment events at all between the healthy state and the corrupt state.

So Modified, NeedsRemediation here is not file tampering and not a deployment operation — the package registration state is invalidated purely as a side effect of the abnormal process termination. That may be worth checking on the servicing side, because it means a cheap Add-AppxPackage -Register fixes it (measured at 360 ms in event 613), while Windows' own automatic remediation fails.

CoworkVMService makes recovery worse

The service declared in the package manifest (event 9626: AppxManifest.xml(111,12): PackagedServiceDEH successfully parsed manifest) keeps running after the crash and holds app\resources\cowork-svc.exe open. Its SDDL is:

D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)
(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

There is no BA (BUILTIN\Administrators) ACE, so an elevated administrator cannot stop or delete the service — sc.exe delete returns access denied, which is what the bootstrapper itself logs:

Removing conflicting CoworkVMService...
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access denied.

The lock then breaks reinstallation:

Id=462 error 0x80070020: Creating file
\\?\C:\Program Files\WindowsApps\Claude_1.24012.9.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe failed.
Id=404 AppX Deployment operation failed ... with error 0x80073CF9

Deleting the service only succeeds when run as SYSTEM after resetting the SDDL with sc sdset. Granting BA at least SERVICE_STOP | DELETE would let the installer's own recovery path work.

Things that did not fix it
disableAutoUpdates=true policy (verified applied: auto-update.txt reports Updates enabled: no — blocked by: disableAutoUpdates=true, Updater state: idle) — the app still corrupted itself after ~5 hours. Related: #63397.
coworkTabEnabled=false (verified in managed-config.txt, cowork-vm-log.txt empty).
Disabling CoworkVMService (it is re-created as Auto by every package registration, since it is declared in the manifest).
Windows Defender is not involved: only detection history is an unrelated file on the Desktop; EnableControlledFolderAccess=0; no exclusions touch WindowsApps.
Disk space: 483 GB free.
Environment
OS : Windows 10 Pro 22H2, 10.0.19045, x64
CPU : Intel Core i7-11390H
RAM : 32 GB
App : 1.24012.9.0, MSIX (windowsStore=true)
Deployment : 1P, no MDM inference config
Install origin: migrated from Squirrel to MSIX by the installer on 2026-06-19
(log: "Uninstalling Squirrel installation ... Squirrel installation removed")

Worth noting the last line: this machine ran the Squirrel build for months with zero issues. Every occurrence of this problem is after the MSIX migration.

Workaround that appears to hold

Launching with GPU acceleration off, per #80444:

powershell
Invoke-CommandInDesktopPackage -PackageFamilyName Claude_pzs8sxrjxfjjc -AppId Claude `
-Command 'app\Claude.exe' -Args '--disable-gpu --disable-gpu-compositing'

A supported hardware-acceleration toggle in Settings (as requested in #81664) would make this usable for non-technical users — right now the only entry points, the Start menu tile and the taskbar shortcut, always launch with GPU enabled.