Repository navigation
[Bug] Windows: 'Not responding' and crash when running more than 3 sessions in parallel (32GB RAM) #7175
Description
Reported via Discord: https://discord.com/channels/1492228674081263786/1492228675272315163/1522171200975929387
I am using the Orca app on Windows system (32GB RAM). When I try to run more than 3 sessions parallelly across different projects, it goes to "Not responding" and crashes. Anyone else facing this? Is there a way to fix this?
Same symptom family as #7017 (freeze/crash under multi-agent load; that issue's Windows/WSL comment describes terminal lag, then app-wide sluggishness, then a crash).
Suspected contributing mechanisms, in rough likelihood order:
- Renderer main-thread saturation from concurrent terminal output. All sessions in a window share one renderer; the output scheduler could feed xterm up to 256 KB/ms, keeping the thread pinned in parse slices. The threshold-like onset ("more than 3 sessions") fits shared-thread saturation. This part is targeted by the drain-pacing change in Keep terminals responsive under agent output load #7139.
- Main-process load scaling with project count (git status polling, PTY/IPC, file watchers). "Not responding" on Windows usually indicates the main process message pump is blocked. Idle git polling was reduced separately by Reduce idle git status polling #7069 (v1.4.117).
- Memory growth / OOM. A crash on a 32 GB machine may be memory-driven, like the original [Bug] Orca keeps crashing my laptop M4 48GB ram with 140GB in application memory, im running only 6 agents #7017 report (140 GB). The drain-pacing change does not reduce memory use.
Triage questions for the reporter:
- Orca version, and are agents running locally, over WSL, or SSH?
- Does the terminal get visibly laggy before the whole app stops responding?
- Task Manager: which process balloons — Orca renderer, Orca main, or the agent CLIs?
- Does it recover after stopping agents / closing terminals, or only after restart?
- A screenshot of Orca's Resource Manager while it's degrading, if possible.
Activity
Stop hidden terminal panes from exhausting renderer memory (hidden-vi…
OrcaWin commentedon Jul 11, 2026
Crash-batch follow-up: the Windows OOM reports split into two distinct signatures, which matters for this issue's "32 GB but crashes under parallel sessions" symptom.
A. Confirmed system commit/pagefile exhaustion (reports 11 and 14)
These are not renderer JS leaks:
spawn ENOMEM/error launching gitimmediately before repeated renderer OOMs; JS heap only ~87 MB of a 3,586 MB limit.fatal: not enough memory for initialization, another Git launch fails, then renderer OOMs ~1.8s later; JS heap ~98 MB and renderer WS ~281 MB.The renderer/GPU/Git processes are victims of machine-wide commit exhaustion. A safe local reproduction would require a disposable Windows VM with constrained RAM/pagefile; I am not inducing global memory exhaustion on a developer workstation.
@linpeng93, could you share for the report-11 machine:
B. Low-JS-heap Chromium OOM/native-allocation family (reports 01, 03, and 07)
These do not have the ENOMEM/Git evidence above:
@IuriiKotov48 @gabriel06089, if this still happens on the current build, the most useful missing data is RAM + pagefile/Committed usage, worktree/terminal/agent counts, GPU/driver/RDP/VM status, and the raw Crashpad
.dmpfor the timestamp (not a third-party zip).This evidence means we should not group every
0xE0000008report under one renderer-heap fix: the system-commit cases need pressure detection/backoff, while the low-heap cases need native dump symbolication.OrcaWin commentedon Jul 17, 2026
Agent reproduction package (Windows orchestration 2026-07-16)
Host context: Windows 11 / Orca 1.4.143.0 / repo path used:
docs/bug-reproductions/Labels applied: see issue labels (
has_reproorcannot_repro).Security: Do not run user-uploaded binaries from issue attachments. Recreate fixtures from the steps/scripts below.
Issue 7175 — Not responding / crash with more than 3 sessions (32GB)
Status:
needs_setup/ treated ascannot_reproon this host until prerequisites landHost: Windows 11, Orca 1.4.143
Label:
cannot_repro(attempted; blocked)What we tried
Did not run a multi-hour stress open of many agent sessions (risk of host instability). Host already had high session count during other tests without AppHang on 1.4.143. Related #6874 historical AppHang on 1.4.135 only.
What is needed Dedicated load test: open 4+ heavy agent sessions, capture Event Viewer AppHangB1, orca diagnostics memory, and before/after status --json. Prefer clean profile.
Dedicated load test: open 4+ heavy agent sessions, capture Event Viewer AppHangB1, orca diagnostics memory, and before/after status --json. Prefer clean profile.
Notes
docs/bug-reproductions/. Re-run once prerequisites exist.How another agent should use this
%LOCALAPPDATA%\Programs\orca).--json, screenshots, logs) under a local folder; optionally comment results back here.cannot_repro/ needs_setup, satisfy the listed prerequisites first, then re-attempt and flip labels: removecannot_repro, addhas_reprowhen conclusive.sanshengai commentedon Aug 24, 2026
We reproduced the Windows multi-session collapse on 16 GB (Orca 1.4.188), and the host was paging, not only saturating the renderer:
codex.exeprivate 13.4 GB vs working set 1.4 GBorca diagnostics memorystill reportsprocessMemoryMetric: "working-set", so Resource Manager cannot warn before the box is already thrashingFull measurements, collector pointers, and proposed slices: #16211
This does not replace the xterm drain-pacing theory in this issue — both can be true. On 16–32 GB Windows the memory side hits first.