GPU process crash (exitCode 101457950) during browser-preview screenshot capture

Status Open
Maintainer reply None cached
Activity 1 comment · opened Aug 26, 2026

Description

Claude desktop app's Electron GPU/compositor process crashed twice in immediate succession (~3 minutes apart), fully killing the app each time. After each crash, Windows required the app package to be repaired before it would relaunch.

Environment

  • App version: 1.37937.0 (MSIX/Microsoft Store install)
  • OS: Windows 11 Pro N, build 10.0.26200
  • Package family: Claude_pzs8sxrjxfjjc

What I was doing

Actively driving the embedded Browser pane (live preview) via the Claude Code CLI session: repeated cross-origin navigation (localhost app -> an external hosted auth page) plus repeated screenshot/read_page calls against the preview in quick succession.

Evidence from %LOCALAPPDATA%\Claude\logs\main.log

Identical crash signature both times:

2026-08-26 03:05:18 [info] GPU process gone: {
  type: 'GPU',
  reason: 'crashed',
  exitCode: 101457950,
  serviceName: 'GPU'
}

Immediately followed by:

2026-08-26 03:08:43 [warn] [Preview] capturePreviewScreenshotIfChanged failed: {
  error: [Error: UnknownVizError] {
    [stack]: [Getter/Setter],
    [message]: 'UnknownVizError'
  }
}

Second occurrence ~3 minutes later, same exit code (101457950), also right after a capturePreviewScreenshotIfChanged call. Both times the app stopped logging entirely after the GPU crash and only resumed after a full relaunch (Starting app { ... }), ~85-140 seconds later. The associated CoworkVMService Windows service also cycled stop/start at the same timestamps.

A separate, unrelated Windows shutdown/restart earlier in the session (Windows session ending (shutdown) - quitting the app) was a clean, expected exit and is not part of this report.

Impact

Full application crash requiring a Windows "repair" step before the app would start again, losing the active session state.

Suggested investigation

The Viz/GPU compositor crash appears tied to the embedded browser-preview screenshot capture path (capturePreviewScreenshotIfChanged), possibly triggered by rapid cross-origin navigation + screenshot calls in quick succession. A software-rendering fallback or automatic GPU-process restart (rather than a full app crash) would likely mitigate this.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗