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

I've been independently tracking the same symptom (Claude Desktop on Windows freezing then vanishing, zero trace in minidump/Crashpad/Application log/System log/Reliability Monitor) with a custom watchdog that holds a handle on the process, so I can add a few data points this report doesn't have.

Exit code, captured directly (not from any Windows log — those stayed empty for us too):

0xCFFFFFFF = STATUS_APPLICATION_HANG, consistently, across 9 occurrences over 2 weeks (2026-08-16 to 2026-08-30). This string doesn't appear anywhere in the app bundle, so it's Windows' own hang-kill code, not something the app emits. This may explain part of the "zero trace" mystery: for MSIX-packaged Claude Desktop, the classic HKLM...\Windows Error Reporting\Hangs registry path expects EventType=AppHang, but this app's hang reports (when they exist at all) use EventType=MoAppHang (the MSIX/packaged-app hang path), which that registry key doesn't route dumps for. Separately, I noticed the app appears to have moved off MSIX packaging entirely at some point between 2026-08-19 and 2026-08-29 (now running from a non-MSIX install path) — whether that changes anything about hang reporting, I haven't verified.

A live hang capture (one of the 9), with a minidump:

A companion tool of mine polls IsHungAppWindow and captures a minidump + per-thread CPU deltas the moment a hang is detected. For the most recent occurrence (2026-08-30 06:47:58 local), the UI thread consumed 484ms of a 672ms sampling window right before capture — i.e., it was spinning/doing sustained synchronous work, not blocked/waiting. The dump itself only resolves one stack frame per thread (no symbols available for this build), so I can't identify what code was running.

Correlation with main.log's git status timed out:

Across the 3 occurrences where I still had the relevant main.log window, all 3 show [GitStatusService] Failed to check git status: git status timed out as the last (or near-last) log line before the process went dark. That matches the precursor pattern described in this report. However, for the one occurrence where I have clear ordering, the [event-loop-stall] main process blocked for 7726ms line appears before the git-status-timeout line by about 1 second — so I'd read this as "consistent with, but not proof of, git status being the trigger." It's equally plausible both are downstream symptoms of something else blocking the main process (my repo lives on a local, non-network drive, so I can rule out network-mount latency specifically).

On the concurrency theory:

I compared claude-code CLI session count at capture time against outcome (recovered vs. terminated) across 6 captured hangs: session counts ranged 8–18 for hangs that recovered, and the one that terminated had 11 sessions — squarely in the middle of that range. So in my data, raw session count alone doesn't predict recovery vs. termination. I haven't checked whether concurrent git operations specifically (as opposed to session count generally) correlate — that seems like the more precise version of the hypothesis and I don't have the instrumentation to test it directly.

Versions observed: Desktop app 1.40609.0, CCD/harness 2.1.247, Windows 10 (build 19045).

Happy to share the watchdog's raw exit ledger or the minidump/thread-snapshot bundle from the 2026-08-30 occurrence if useful — it's not published anywhere, just sitting locally.

Thanks for sharing what you've experienced and learned! A few notes for
you: when I whitelisted git, it didn't help. Claude had noticed a
connection in logs and while monitoring to farflt11.sys, so I removed the
git whitelist and whitelisted that, instead. As far as I can tell, it
doesn't help much, if at all, but i stopped monitoring. The biggest single
contributor seems to be having more than one session going, even if they're
not being used concurrently, but it can happen using one session. I have
had crashes when running one session, waiting until its turn is over, then
using the other, going back and forth consecutively, and it still crashes.
I've had the desktop app crash, too, when I try to use a session right
away, or when I switch to a new session and activate it right away. These
issues did not used to happen until some time in July, I believe. There
were many updates and, at some point, the app became unstable. I haven't
yet tried to uninstall and reinstall the app, but I did try the Windows
repair option. The first time I did it, it didn't make a difference. I was
prompted the other day to try again, and it couldn't repair it that time. I
may just try reinstalling. Have you tried that?

Frankly, between the problems with the app and with Claude itself, I'm
getting pretty fed up. I sure wish they'd hire a programmer or three that
can do a better job of it, or help us fix this issue.
Message ID: @.***>

Thanks for this — the exit-code data alone is a solid addition (9 occurrences landing on the same STATUS_APPLICATION_HANG is more consistent evidence than anything in the original report), and the ordering you found between the event-loop-stall and git-status-timeout lines is worth flagging back to my own report: I'd been treating "git status timed out" as a plausible trigger, but if event-loop-stall precedes it even in one clearly-ordered case, that points more toward both being downstream symptoms of something else blocking the main thread — which matches your UI-thread-spinning finding (484ms of 672ms) better than a "blocked waiting on git" story would.

On the session-concurrency point: agreed that raw session count doesn't look like it separates recovered vs. terminated in your data. If you do get instrumentation on concurrent git operations specifically (versus session count generally), I'd be very interested — that's the sharper version of the hypothesis and I don't currently have a way to test it either.

One difference worth naming: my install is still MSIX as of today (2026-09-04) — Get-AppxPackage returns a normal result — so whatever moved your install off MSIX between 8/19–8/29 either hasn't hit my machine/channel, or is unrelated to the hang itself. Not sure which yet.

Would genuinely value the watchdog's raw exit ledger and the 8/30 minidump/thread-snapshot bundle if you're willing to share — nothing on my end currently holds a handle on the process or samples on hang detection, so I have no way to reproduce your exit-code or thread-spin measurements independently. Happy to cross-check against my own main.log occurrences in the meantime.