Windows: GPU driver timeout kills Desktop window, orphaned claude.exe processes + deferred MSIX update block relaunch until reboot

Summary

On Windows, when the Claude Desktop window dies during a GPU driver timeout, the embedded claude-code child processes survive as orphans. Combined with a Microsoft Store (MSIX) update that was staged with DeferRegistrationWhenPackagesAreInUse, this leaves the app impossible to relaunch — Windows reports the executable is in use, and killing the process shown in Task Manager doesn't help because multiple claude.exe processes remain. The user is locked out of Claude until a full reboot. This has happened repeatedly to this user.

Environment

• OS: Windows 11 Pro 10.0.26200
• App: Claude Desktop, Microsoft Store MSIX package (Claude_pzs8sxrjxfjjc), version 1.37937.1 → 1.37937.2 at the time of the incident (1.37937.3 today)
• Embedded runtime: claude-code 2.1.246 (%APPDATA%\Claude\claude-code\2.1.246\claude.exe)
• GPU: NVIDIA GeForce RTX 3050 6GB Laptop (PCI VEN_10DE&DEV_25EC), 40 GB RAM

Timeline of the incident (2026-08-26, UTC-3, reconstructed from Windows Event Log + WER + session transcripts)

1. ~17:06–17:08 — User is working with three concurrent desktop sessions. At 17:08 the System log records a burst of 5 LiveKernelEvent reports. The WER queue contains Kernel_141 reports (0x141 = VIDEO_ENGINE_TIMEOUT_DETECTED, GPU TDR), and WHEA-Logger records corrected PCIe AER errors originating from the NVIDIA GPU (VEN_10DE&DEV_25EC).
2. The Claude Desktop window closes spontaneously. However, background claude-code session processes keep running — session transcript files (~/.claude/projects/...jsonl) continue being written until 17:50.
3. 17:18 — The Store stages the update 1.37937.1 → 1.37937.2 (DeferRegistrationWhenPackagesAreInUse). AppXDeploymentServer events 658/638: "Marking package for deferred registration because 1.37937.1 is still running. Running apps: {Claude_pzs8sxrjxfjjc!Claude}" — i.e., the orphaned processes are counted as "app still running", and the package family enters the pending-update state.
4. User tries to relaunch: Windows reports the Claude executable is in use. Task Manager shows a running Claude; killing it doesn't help — relaunch fails again identically. (Today, with the app healthy, there are 14 concurrent claude.exe processes between the MSIX package and the claude-code runtime, so killing the one visible entry is never enough.)
5. 18:25–18:26 — Deferred registration finally completes; 18:29 system restart. After reboot the app works normally.

Note: the same deferral pattern re-armed today (1.37937.2 → 1.37937.3 staged at 09:55, deferred registration, package state Set=0x400), and there is an older AppHang_Claude_1.32885.1 WER report from 2026-08-21, so this failure mode is recurring for this machine.

Expected behavior

• If the main window / GPU process dies, the app should either recover the window or shut down its whole process tree — child claude-code processes should not outlive the desktop shell (e.g., put them in a kill-on-close job object).
• On activation failure, detect orphaned processes from the same package family and offer to clean them up, instead of silently failing to launch.
• A crashed shell + pending deferred MSIX registration should not require a full OS reboot to recover.

Impact

Complete loss of access to Claude Desktop (and all running sessions) until reboot; work in three active sessions was interrupted. Recurring issue.