# Main process crash (0x80000003) in perfetto::SharedMemoryArbiterImpl::BindToProducerEndpoint during GC trace polling (Windows, 3.29.9) **URL:** \ **Category:** Bug Reports\ **Tags:** crashes\ **Created:** [November 7, 2026, 2:36pm UTC](https://forum.cursor.com/t/main-process-crash-0x80000003-in-perfetto-bindtoproducerendpoint-during-gc-trace-polling-windows-3-29-9/177637 "2026-11-07T14:36:04Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Raven12138](https://avatars.discourse-cdn.com/v4/letter/r/8edcca/32.png) [@Raven12138](https://forum.cursor.com/u/Raven12138)\ **Post date:** [November 7, 2026, 2:36pm UTC](https://forum.cursor.com/t/main-process-crash-0x80000003-in-perfetto-bindtoproducerendpoint-during-gc-trace-polling-windows-3-29-9/177637/1 "2026-11-07T14:36:04Z")
### Where does the bug appear (feature/product)? Cursor IDE ### Describe the Bug All Cursor windows closed at once, with no error dialog. The main (browser) process crashed itself with exit code `0x80000003` (STATUS\_BREAKPOINT, a fatal CHECK) at **2026-11-07 07:16:49.165 UTC** (15:16:49 local time, UTC+8), after 2 h 38 min of uptime. Nobody was using the computer at the time. The failing check is in Chromium’s Perfetto tracing code: ```auto Cursor.exe+0x3d137ae perfetto::SharedMemoryArbiterImpl::BindToProducerEndpoint(perfetto::ProducerEndpoint*, perfetto::base::TaskRunner*) +0x25e third_party/perfetto/src/tracing/core/shared_memory_arbiter_impl.cc:752 PERFETTO_CHECK(IsReservationTargetBufferId(entry.second)); ``` It happened during a drain cycle of Cursor’s GC trace polling (the `gc_trace_control` experiment). This feature keeps `contentTracing` recording `disabled-by-default-v8.gc` continuously and runs stop → read → restart every 120 s. I did not turn it on, and I can’t find a setting to turn it off. ### Steps to Reproduce The crash is not deterministic. The conditions when it happened: 1. Windows 11 with Cursor 3.29.9, and GC trace polling active. Every window’s `renderer.log` contains `[GC Trace Polling] Started polling (every 130s)`. 2. Cursor had been running for a few hours with 5 windows open. 3. One drain cycle overlapped with the main process launching a new sandboxed child process, presumably a replacement tracing service, and the main process crashed 0.23 s later. ### Expected Behavior A failure in background GC tracing should not take down the main process, along with every open window and integrated terminal session. ### Operating System Windows 10/11 ### Version Information ```auto Version: 3.29.9 (user setup) VSCode Version: 1.128.0 Commit: 306d153d51d714882ab7b1bc49649cab624e8a30 Date: 2026-11-05T02:42:01.412Z Electron: 43.8.4 Chromium: 150.0.7871.250 OS: Windows_NT x64 10.0.22631 ``` Windows 11 Home 23H2 (10.0.22631), x64 ### Additional Information **Timeline (UTC; local time is UTC+8)** | Time (UTC) | Event | | --- | --- | | 04:38:28.960 | Main process starts | | 04:38:43.146 | window1 `renderer.log`: `[GC Trace Polling] Started polling (every 130s)` | | every 120 s | Drain: a GUID-named `.tmp` trace file in `%TEMP%` is written, parsed and deleted | | 07:16:47.306 | A drain starts and creates `%TEMP%\f408901b-93c1-4eb6-81a5-efde4a08b9a4.tmp` | | 07:16:48.628 | Last write to that file. It stays at 0 bytes and is never deleted; it is still on disk. | | 07:16:48.932 | The main process launches a new sandboxed child, PID 35432. Windows Security-Mitigations event 10 for it appears at 07:16:48.952. Earlier drains did not launch processes. | | 07:16:49.165 | The main process exits with `0x80000003`. The other child processes exit within the next ~140 ms. PID 35432 exits with code 0, having used no CPU time. | | 08:14:39 | Next Cursor launch. The bundled `@sentry/electron` minidump integration picks up the dump from `%APPDATA%\Cursor\Crashpad\reports` and deletes it. | **Notes** - **The check should be unreachable.** At the pinned Perfetto revision, `pending_writers_` is written in only one place, `shared_memory_arbiter_impl.cc:1020`. That write happens only when `IsReservationTargetBufferId(target_buffer)` is true, i.e. when the upper 16 bits are non-zero. Every access is under `lock_`. - **So the state was probably corrupted.** The arbiter found an entry with the upper 16 bits clear. That points to corrupted state, a use-after-free of the arbiter or its map, or a race, rather than an unusual but legal call sequence. This is my reading of the source; I may be missing a path. - **The old tracing service had already gone.** The tracing-service process the main process had been using was no longer present when the new child was launched. I could not determine when or why it exited. - **I could not confirm what PID 35432 was.** I could not recover its command line, so “replacement tracing service” is an inference. - **A child launch was in progress at crash time.** Stack data found next to the exception record includes `content::ChildProcessLauncherHelper::StartLaunchOnClientThread` and `sandbox::BrokerServicesBase::SpawnTargetAsyncImpl` on the browser IO thread. > **How the crash location was obtained (the local minidump had already been deleted)** > > 1. The dead session’s `crashpad_handler` was still running and still held a handle to the dead main process. `GetExitCodeProcess` / `GetProcessTimes` on that process gave exit code `0x80000003` and the exit time. > 2. I took a full memory dump of that `crashpad_handler` (`cdb -pv -p -c ".dump /ma ..."`). It still contained the `EXCEPTION_RECORD` (code `0x80000003`, address `0x7ff643f337ae`) and the CPU context, with `rip = 0x7ff643f337ae`. > 3. I symbolized `Cursor.exe+0x3d137ae` with the official Electron 43.8.4 Breakpad symbols from `symbols.electronjs.org`; their module ID matches `Cursor.exe`. The result is `BindToProducerEndpoint +0x25e`, line 752. > 4. The disassembly of `Cursor.exe` agrees: > - The `pending_writers_` loop does `cmp dword ptr [node+24h],0FFFFh` / `jbe` to a cold block. > - That block calls the log function with line `0x2F0` (= 752) and ends in the `int 3` at RVA `0x3d137ae`. > - The checks at lines 737 and 738 have their own separate crash blocks, so this is not a merged trap site. > > 5. The source is Perfetto `9ede949f025303868fa0c42418f122ac47312539`, the revision pinned in the DEPS of Chromium 150.0.7871.250. **Requests** 1. If the Sentry minidump upload succeeded, the crash should be in your Sentry with this signature, uploaded around 2026-11-07 08:14 UTC. I can send my crash reporter ID privately if that helps you find it. 2. Please consider turning off `gc_trace_control` until this is understood, at least on Windows with this Chromium version. Users have no way to turn it off themselves. 3. Since the check looks unreachable under Perfetto’s own invariants, it may be worth raising with the Chromium/Perfetto teams. I analyzed this one occurrence in detail. Cursor has also closed unexpectedly at other times, but I have no evidence tying those to this crash. ### Does this stop you from using Cursor Sometimes - I can sometimes use Cursor ---
**Author:** ![Colin](https://sea3.discourse-cdn.com/cursor1/user_avatar/forum.cursor.com/colin/32/90452_2.png) [@Colin](https://forum.cursor.com/u/Colin)\ **Post date:** [November 7, 2026, 4:41pm UTC](https://forum.cursor.com/t/main-process-crash-0x80000003-in-perfetto-bindtoproducerendpoint-during-gc-trace-polling-windows-3-29-9/177637/5 "2026-11-07T16:41:51Z")
Hi @Raven12138, Yes, please send your crash reporter ID! This ID is not sensitive, and you can share it directly on the forum. With that, we can look into the crash further. ---
**Author:** ![salesklin](https://avatars.discourse-cdn.com/v4/letter/s/f19dbf/32.png) [@salesklin](https://forum.cursor.com/u/salesklin)\ **Post date:** [November 13, 2026, 2:23pm UTC](https://forum.cursor.com/t/main-process-crash-0x80000003-in-perfetto-bindtoproducerendpoint-during-gc-trace-polling-windows-3-29-9/177637/7 "2026-11-13T14:23:52Z")
I can confirm that this exact issue is still reproducible on **Cursor 3.30.8 (Windows 11)**. On November 13, 2026, at 15:01:20 CET, all my Cursor windows suddenly closed without any warning or error dialog, after approximately 2 hours and 40 minutes of uptime. This has been happening repeatedly and is seriously disrupting my development workflow. I investigated the crash using Windows Event Viewer, Cursor’s internal logs, and WinDbg, and recovered two valid Crashpad minidumps generated at exactly the same timestamp. **Dump #1 — Breakpoint exception** - Exception: `0x80000003` (STATUS\_BREAKPOINT) - Module: `Cursor.exe` - RVA: `0x3D137AE` - This is the **exact same crash offset** reported in this thread, previously symbolized as `perfetto::SharedMemoryArbiterImpl::BindToProducerEndpoint`. **Dump #2 — Access violation** - Exception: `0xC0000005` (invalid memory read) - Module: `Cursor.exe` - RVA: `0x3D9CC01` - Both dumps were generated at 15:01:20 CET. **GC Trace Polling confirmed active** I checked the logs of all seven open Cursor windows. Every `renderer.log` contains: ```auto [GC Trace Polling] Started polling (every 130s) ``` The extension hosts shut down at the same timestamp, and there was no conventional Windows Application Error event associated with the incident. **Environment** - Cursor 3.30.8 (stable) - Windows 11, build 26200.9457 - x64 Given the exact match in crash offset, the active GC tracing experiment, and the identical symptoms, this appears very likely to be the same underlying issue. **Could the Cursor team please:** 1. Confirm whether `gc_trace_control` can be disabled server-side for affected accounts? 2. Provide a supported local workaround to disable GC Trace Polling while the issue is investigated? 3. Confirm whether a fix is planned for an upcoming release? This is a significant reliability issue because it terminates every open window, potentially interrupting active agent executions and terminal sessions. Mi crash reporter id: 212d3ea2-698e-41c1-a232-1b81f6a4067f Thanks for looking into this.