[BUG] Claude Desktop (Windows x64) — recurring "freeze-then-vanish" crash with zero forensic trace across all standard channels

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Over roughly two weeks of dedicated investigation, Claude Desktop has repeatedly frozen and then silently disappeared — process gone, app relaunches on its own, conversation state intact — leaving no trace whatsoever in the minidump folder, Crashpad, Windows Application log, System log, or Reliability Monitor. Six confirmed occurrences were correlated against the app's own main.log, revealing two distinct precursor patterns that may represent two separate mechanisms converging on the same symptom:

• Long stall-accumulation: several occurrences were preceded by large cumulative event-loop-stall backlogs (up to ~44.7 minutes), correlating with slow git status/git fetch operations against a large, binary-heavy repository.
• Concurrency: other occurrences had minimal or no stall backlog, but shared multiple Claude sessions actively warming/working simultaneously.

Regardless of which trigger applies, nothing explains why these crashes produce zero forensic trace across every standard Windows diagnostic channel — a genuine kernel crash (separately confirmed elsewhere in this same investigation, see Additional Information) reliably produces minidumps and event-log entries; these do not.

What Should Happen?

Claude Desktop should not become unresponsive and silently vanish without producing any diagnosable trace. At minimum, a crash of this kind should generate a standard Windows crash report (minidump, Application-log entry, or Reliability Monitor record) so it can be self-diagnosed or reported usefully, rather than requiring the multi-day manual log correlation performed here.

Error Messages/Logs

No Windows-level crash artifact exists for any of the eight occurrences (checked: minidump folder, Crashpad, Application log, System log, Reliability Monitor — all empty for these timestamps). Evidence is entirely from `main.log`/`main1.log` correlation, e.g. (representative excerpt, occurrence #4):


[event-loop-stall] main process blocked ... cumulative 2681078ms ...
[GitStatusService] Failed to check git status: git status timed out
<crash/relaunch follows ~6s later>


No stack trace, exception, or bugcheck code is available for any of these eight events — that absence is itself the core of this report.

Steps to Reproduce

Not reliably reproducible on demand. Confirmed occurrences and their precursor stall backlog:

| # | Timestamp | Cumulative stall backlog before crash | Notes |
|---|---|---|---|
| 1 | 2026-08-10 12:03:58 | — | First occurrence |
| 2 | 2026-08-10 17:21:42 | — | |
| 3 | 2026-08-10 17:22:07 | — | 25s after #2 |
| 4 | 2026-08-11 14:57:52 | ~2,681,078ms (~44.7 min), 1,353 stalls | Largest backlog on record; preceded by git status timed out |
| 5 | 2026-08-11 14:58:14 | ~2 stalls only | 22s after #4's restart |
| 6 | 2026-08-11 15:00:28 | — | 2m14s after #5; preceded by git fetch origin master timing out |
| 7 | 2026-08-11 20:47:29 | ~432,970ms (~7.2 min) | Preceded by a slow fetchGitDiff (18,938ms) |
| 8 | 2026-08-11 21:04:41 | ~64,521ms (~1.1 min) — lowest on record | Occurred while a second, different session was actively warming concurrently |

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

The version around 3 months ago

Claude Code Version

Claude 1.37937.0 (61bfd4) 2026-08-25T05:51:27.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Claude Desktop app (Windows), not invoked from a terminal.
Environment: Windows 11 Pro, Version 25H2 (OS Build 26200.9168), x64. Intel i7-12700K, AMD RX 6800 XT, 64GB DDR4. Claude Desktop versions observed across the investigation: 1.26832.0 through at least 1.34493.1.0.

Leading untested theory (~55% confidence): silent termination by Windows Process Lifecycle Manager (PLM) — normally used to suspend/resume/terminate UWP-style apps under resource pressure — could plausibly kill a hung MSIX-packaged process without generating a normal crash report. Not directly tested; plmdebug.exe (the tool that could query PLM state live during a hang) is not present on the investigating machine and would require installing the full Windows SDK "Debugging Tools for Windows" component.

Related but distinct issues investigated in the same effort, for context (not this bug):

• A genuine kernel BSOD (bugcheck 0x50) confirmed via WinDbg, caused by git.exe/Malwarebytes farflt11.sys filter-driver interaction — a documented, known Malwarebytes issue with full forensic evidence. Mitigated via a driver-level exclusion.
• AMD GPU driver crashes (amdkmdag.sys, bugcheck 0x141) — 10 historical reports, all predating an 8/3 driver update, none since.
• A separate AMD driver fault (amdfendr.sys, bugcheck 0xa2000002).
• A leaked AppContainer Job object causing "another program is using this file" on relaunch — filed as a separate report; may explain some historical "already open" incidents in this investigation, but not the freeze-then-vanish signature itself (that one involves the process disappearing mid-session, not failing to relaunch afterward).

Workarounds considered, not yet systematically tested:

1. Run one Claude Code session at a time (targets the concurrency mechanism).
2. Reduce repository size/trim large tracked binaries to cut git status/git fetch/gitDiff latency (targets the stall-accumulation mechanism).
3. Enable Windows PLM analytic/debug event channels to directly test the PLM theory — attempted, inconclusive; the initially-suspected Microsoft-Windows-AppModel-Runtime channel's available event types (AppContainer creation/integrity checks) don't match PLM's suspend/resume/terminate responsibilities, so this remains unresolved.

Suggested fixes:

1. Investigate whether the MSIX-packaged Desktop app can be silently terminated by PLM under a hung/unresponsive state, and whether that path can be made to produce a normal crash report.
2. Consider a graceful-degradation warning when event-loop-stall accumulation crosses a threshold, before the process becomes unresponsive.
3. Consider whether concurrent sessions contribute to main-process instability independent of stall backlog.
4. A crash with zero trace across every standard diagnostic channel is a defect independent of root cause — it leaves users unable to self-diagnose or report usefully.