Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   has reproHas detailed reproduction stepsHas detailed reproduction steps

   platform:windowsIssue specifically occurs on WindowsIssue specifically occurs on Windows

   area:core

   area:packaging

   high-priority

   on Jan 30, 2026
2. github-actions commented on Jan 30, 2026

   

   github-actionsBot

   on Jan 30, 2026 – with GitHub Actions

   More actions

   Found 3 possible duplicate issues:

   1. Bun segfault during extended multi-agent workflow (Windows) #21869
   2. Segfault crash on Windows: Bun v1.3.5 segmentation fault during long-running agent task #21620
   3. [BUG] Bun Bun Segmentation Fault Crashes on Windows #21469

   This issue will be automatically closed as a duplicate in 3 days.

   • If your issue is a duplicate, please close it and 👍 the existing issue instead
   • To prevent auto-closure, add a comment or 👎 this comment

   🤖 Generated with Claude Code

   👎React with 👎5Reacted by Mike Ramsey Jr, Martin Wickman, Joe Brown, Xekri and RDURKIN-Rx
3. github-actions

   added

   oncall

   on Feb 4, 2026
4. balandari

   changed the title [-]Repeated Bun segfaults - 3 crashes in rapid succession (Windows)[/-] [+]Repeated Bun v1.3.5 segfaults -- 78 crashes, root cause identified (Windows + WSL)[/+] on Feb 5, 2026
5. balandari commented on Feb 5, 2026

   

   balandari

   on Feb 5, 2026

   Author

   More actions

   Dump Analysis Follow-Up: 27 Full Memory Dumps (Feb 4-5, 2026)

   This follows the consolidation report that condensed 85 individual crash report comments into a structured analysis identifying 3 crash families and a suspected N-API race condition root cause. Since that report, we captured 27 full-memory dumps via ProcDump and analyzed them with cdb (WinDbg command-line debugger). The new data confirms a single root cause across four crash families and provides disassembly-level evidence for the corruption mechanism.

   Symbol disclaimer: claude.exe ships without debug symbols. All function names in stack traces (e.g., uv_tty_get_vterm_state, uv_getnameinfo, simdutf::get_active_implementation) are nearest-export-symbol artifacts -- cdb resolves addresses to the closest exported function name. The actual code at those offsets is Bun/JSC internal code, NOT libuv TTY code or simdutf. Bun developers should use the RVA offsets (e.g., +0x11d3a8) to locate the real code in a symbolicated build.

   Environment

   • OS: Windows 11 x64 Build 26200
   • CPU: Intel Core i9-14900HX (32 logical processors)
   • Claude Code: v2.1.31 (26 dumps), v2.1.32 (1 dump)
   • Embedded Bun: v1.3.5
   • Capture tool: ProcDump (full memory dumps, -ma flag)

   Family Distribution (27 dumps)

   Family	Count	%	Exception	Mechanism
   F2: Main Thread / JSC GC	22	81.5%	C0000005 (Access Violation)	Corrupted vtable indirect call; NaN-boxing sentinel fault addresses
   F4: FAST_FAIL	3	11.1%	C0000409	Bun internal corruption detection -> __fastfail(7)
   F5: Partial Pointer	1	3.7%	C0000005 (Access Violation)	Partial pointer corruption (0x000001FF00000003)
   F6: Heap Corruption	1	3.7%	C0000374	Windows heap manager detects double-free
   F1: Worker Thread	0	0%	--	Not observed in this batch

   Process uptimes ranged from 35 seconds to 1 hour 13 minutes -- the crash is a race condition with no time threshold.

   ---

   Key Finding 1: All Families Share One Code Path

   Disassembly and stack analysis across F2, F4, and F6 show all three pass through the same code regions (symbol names are nearest-export artifacts; RVA offsets identify the actual code):

   • F2 (segfault): napi_remove_async_cleanup_hook -> simdutf::get_active_implementation -> uv_tty_get_vterm_state+0x11d3a8 -> RIP = 0x7
   • F4 (FAST_FAIL): node_module_register -> simdutf::get_active_implementation -> uv_tty_get_vterm_state -> uv_getnameinfo+0x5c029 (int 29h)
   • F6 (heap corruption): uv_tty_get_vterm_state+0xd32e6 -> uv_getnameinfo+0x7968c -> RtlFreeHeap -> HEAP_FAILURE_SEGMENT_LFH_DOUBLE_FREE

   The F2 crash site disassembly at uv_tty_get_vterm_state+0x11d3a8:

   mov  rdx, r9           ; set up argument
   call qword ptr [rcx]   ; indirect call through vtable pointer -> loads 0x7 into RIP

   This is a C++ virtual function call or function-pointer dispatch. At crash time, [rcx] contains 0x7 -- a corrupted vtable entry from a freed object. The small value 0x7 is consistent with free-list metadata or a zeroed pointer that replaced the valid vtable when the GC reclaimed the object prematurely.

   Register fingerprint across all F2 dumps: r12 = fffe000000000002 (NaN-boxed boolean true in JSC encoding), confirming crashes occur during active JS execution in the JSC interpreter loop -- not during startup or shutdown.

   Thread state is identical across all families. Every dump shows:

   • 7-9 threads in napi_unref_threadsafe_function -> RtlWaitOnAddress
   • 4-8 threads in simdutf::get_active_implementation -> SleepConditionVariableSRW (worker pool)
   • 4 libuv worker threads
   • 1 thread running uv_run event loop inside napi_unref_threadsafe_function

   The napi_unref thread count stabilizes at 7-9 regardless of total thread count (26-42), crash family, or process uptime.

   ---

   Key Finding 2: FAST_FAIL Trigger Decoded

   The consolidation report noted "silent crashes" where the process disappears without a crash dialog. This is now explained. Disassembly at the F4 crash site (uv_getnameinfo+0x5c029):

   call    claude!uv_getnameinfo+0x67038              ; call validation function
   test    byte ptr [claude!icudt73_dat+0x222d05c], 2 ; test a flag bit
   je      skip_abort                                  ; if not set, skip
   mov     ecx, 17h                                    ; load parameter 0x17
   call    qword ptr [claude!icudt73_dat+0x1f06490]   ; call through function pointer
   test    eax, eax                                    ; check return value
   je      skip_abort                                  ; if zero (ok), skip
   mov     ecx, 7                                      ; FAST_FAIL_FATAL_APP_EXIT
   int     29h                                         ; __fastfail(7) -- process terminated

   This is a two-stage validation sequence. Stage 1 calls a check function and tests a flag. Stage 2 calls through a function pointer and checks the result. If both indicate corruption, Bun fires __fastfail(7) (FAST_FAIL_FATAL_APP_EXIT) -- the Windows equivalent of abort().

   The int 29h instruction raises a non-continuable second-chance exception (C0000409) that bypasses SEH entirely. The process is terminated by the kernel without invoking any exception handlers or crash reporters. This is why the process "just disappears" -- Bun detects corruption, calls abort, and the kernel kills the process before any crash UI can appear.

   F4 is the same corruption as F2, detected by a different code path. The race is between: (a) dereferencing the corrupted pointer directly (produces F2 segfault at 0x7), and (b) Bun's validation check catching the invalid state first (produces F4 FAST_FAIL). Which fires first depends on CPU scheduling.

   ---

   Key Finding 3: Double-Free Confirmed

   The F6 dump provides the most direct evidence of the corruption mechanism. The !heap -s output:

   Error type:    HEAP_FAILURE_SEGMENT_LFH_DOUBLE_FREE
   Details:       The heap detected that the current free operation
                  is attempting to free a block which is already free.
   Error address: 0000021551efa6e0
   

   This is textbook double-free. The N-API race condition causes two code paths to free the same memory:

   1. napi_remove_async_cleanup_hook frees the async resource
   2. JSC GC sweep later tries to free the same backing memory (or vice versa)

   The crash stack passes through the same code regions as F2 and F4:

   ntdll!RtlFreeHeap+0x231
   claude!uv_getnameinfo+0x7968c       (Bun internal code)
   claude!uv_tty_get_vterm_state+0xd32e6  (same region as F2/F4)
   0x0000021510363156                   (JIT-compiled code)
   

   The Windows heap manager caught the double-free during RtlFreeHeap before the corruption could propagate to a segfault.

   ---

   Unified Model

   All four crash families are the same bug detected by four different mechanisms:

   1. F2 (81.5%): CPU catches invalid memory access when code dereferences a corrupted pointer
   2. F4 (11.1%): Bun's internal validation detects corruption before the dereference
   3. F5 (3.7%): Corrupted pointer lands in an unusual address range (0x000001FF00000003 -- partial pointer corruption)
   4. F6 (3.7%): Windows heap manager detects double-free during RtlFreeHeap

   The underlying corruption is a race condition between napi_remove_async_cleanup_hook and concurrent napi_unref_threadsafe_function operations. When cleanup hook removal and threadsafe function operations interleave, an object gets freed while still referenced (or freed twice). Fix the N-API lifecycle race and all four families should disappear.

   ---

   Open Questions

   • F1 (Worker Thread Cleanup) was absent from all 27 dumps. It may be rare (a 27-sample batch has a 25% chance of missing a 5%-frequency event), workload-dependent, or possibly misclassified in the earlier analysis which had only 5 dumps.
   • ProcDump capture rate for FAST_FAIL is unknown. __fastfail bypasses SEH, so ProcDump must catch it as an unhandled exception. Our 11.1% F4 rate is likely a lower bound -- some FAST_FAIL crashes may not produce dumps.
   • Exact identity of the corrupted object is unknown without debug symbols. We can see the vtable pointer was corrupted to 0x7, but identifying which C++ class requires a symbolicated build or a debug build reproduction.
   • v2.1.32 (1 dump) shows identical crash behavior to v2.1.31. The v2.1.32 changelog contains no changes to Bun version or N-API handling. The crash signature (fault address 0x7, F2 family, r12 = fffe000000000002) is indistinguishable from v2.1.31 dumps.

   ---

   Full Dump Inventory (27 dumps)

   #	Dump File	Uptime	Threads	Fault Address	AV Type	Family	Version
   1	260204_094147	3:47	38	0x7	Execute	F2	2.1.31
   2	260204_095059	4:52	35	FAST_FAIL (int 29h)	C0000409	F4	2.1.31
   3	260204_095537	4:21	36	0xFFFFFFFFFFFFFFFE	Read	F2	2.1.31
   4	260204_095936	1:51	37	0xA	Read	F2	2.1.31
   5	260204_103149	24:03	34	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   6	260205_000334	1:40	34	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   7	260205_001841	13:46	32	0x0	Read	F2	2.1.31
   8	260205_002154	3:02	38	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   9	260205_092138	6:00	38	0x6	Read	F2	2.1.31
   10	260205_092443	2:44	39	FAST_FAIL (int 29h)	C0000409	F4	2.1.31
   11	260205_100709	42:18	34	0xFFFFFFFFFFFFFFFE	Read	F2	2.1.31
   12	260205_102340	12:47	30	0x000001FF00000003	Read	F5	2.1.31
   13	260205_103137	7:43	35	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   14	260205_104800	11:59	40	0x7	Execute	F2	2.1.31
   15	260205_105502	13:52	32	0xFFFFFFFFFFFFFFFE	Read	F2	2.1.31
   16	260205_105547	0:35	40	FAST_FAIL (int 29h)	C0000409	F4	2.1.31
   17	260205_105736	0:49	38	0xFFFFFFFFFFFFFFFE	Read	F2	2.1.31
   18	260205_110114	5:15	33	Heap corruption (C0000374)	RtlReportFatalFailure	F6	2.1.31
   19	260205_111011	8:33	34	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   20	260205_112647	26:14	28	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   21	260205_113329	1:13:23	26	0xFFFFFFFFFFFFFFFE	Read	F2	2.1.31
   22	260205_115948	32:47	28	0x7	Execute	F2	2.1.31
   23	260205_120718	30:12	29	0x7	Execute	F2	2.1.31
   24	260205_121446	7:13	32	0xFFFFFFFFFFFFFFFE	Read	F2	2.1.31
   25	260205_122153	5:20	37	0xFFFFFFFFFFFFFFFF	Read	F2	2.1.31
   26	260205_132149	59:48	34	0x0	Read	F2	2.1.31
   27	260205_133922	11:04	42	0x7	Execute	F2	2.1.32

   Uptime format is minutes:seconds except dump 21 which is hours:minutes:seconds.

   Disassembly Evidence

   1. F2: Vtable corruption (crash site)

   From dump claude.exe_260205_115948.dmp, disassembly at claude!uv_tty_get_vterm_state+0x11d3a8:

   ; This is the crash instruction. rcx points to an object whose vtable
   ; has been corrupted. [rcx] loads 0x7 into RIP -> ACCESS_VIOLATION (execute).
   ; The function names are nearest-export-symbol artifacts -- this is actually
   ; Bun/JSC internal code, NOT libuv TTY code.
   
   mov  rdx, r9           ; argument setup
   call qword ptr [rcx]   ; indirect call through vtable -> RIP = 0x7

   Register state at crash:

   rax=00000150e60adc40  rbx=fffe000000000000  rcx=000000a301d8c200
   rdx=00000150e60adc40  rsi=000002b508826718  rdi=00000150e60adc40
   r8=000000000000001e   r9=000002b50994ba40   r10=0000000000000018
   r11=000000a301d8c200  r12=fffe000000000002  r13=000000000000000a
   r14=0000000000000001  r15=000002b508830000
   

   Note: r12 = fffe000000000002 is a NaN-boxed boolean true in JSC's encoding scheme. This value is consistent across all F2 dumps, confirming the crash occurs during active JavaScript execution in the JSC interpreter loop.

   2. F4: FAST_FAIL trigger (validation and abort sequence)

   From dump claude.exe_260204_095059.dmp, disassembly at claude!uv_getnameinfo+0x5c029 (obtained via ub -- unassemble backward):

   ; Two-stage validation check. If corruption is detected, Bun calls
   ; __fastfail(7) which terminates the process immediately via kernel,
   ; bypassing SEH and crash reporters. This explains "silent crashes."
   
   call    claude!uv_getnameinfo+0x67038              ; Stage 1: validation function
   test    byte ptr [claude!icudt73_dat+0x222d05c], 2 ; test corruption flag
   je      claude!uv_getnameinfo+0x5c03f              ; if clear, skip abort
   
   mov     ecx, 17h                                    ; parameter 0x17 (23)
   call    qword ptr [claude!icudt73_dat+0x1f06490]   ; Stage 2: secondary check
   test    eax, eax                                    ; check result
   je      claude!uv_getnameinfo+0x5c02b              ; if zero, skip abort
   
   mov     ecx, 7                    ; FAST_FAIL subcode: FAST_FAIL_FATAL_APP_EXIT
   int     29h                       ; __fastfail(7) -- kernel terminates process

   3. F6: Heap analysis (double-free detection)

   From dump claude.exe_260205_110114.dmp, !heap -s output:

   HEAP_FAILURE_BLOCK_NOT_BUSY at 0000021551efa6e0
   
   Error type:    HEAP_FAILURE_SEGMENT_LFH_DOUBLE_FREE
   Details:       The heap detected that the current free operation
                  is attempting to free a block which is already free.
   Error address: 0000021551efa6e0
   
   Stack at failure:
     ntdll!RtlFreeHeap+0x231
     claude!uv_getnameinfo+0x7968c        ; Bun internal (symbol is artifact)
     claude!uv_tty_get_vterm_state+0xd32e6 ; Same code region as F2/F4
     0x0000021510363156                    ; JIT-compiled code
   

   The double-free confirms the race condition: one code path (N-API cleanup) frees the resource, then another code path (JSC GC sweep) attempts to free the same backing memory.

   Analysis Methodology

   Capture:

   • ProcDump configured with -ma flag for full memory dumps
   • Monitored claude.exe for unhandled exceptions
   • 27 dumps captured over Feb 4-5, 2026 during normal Claude Code usage

   Analysis tools:

   • cdbX64.exe from WinDbg Store package (command-line debugger)
   • Analysis commands: .exr -1 (exception record), !analyze -v (verbose analysis), ~*kn (all thread stacks with frame numbers), !heap -s (heap summary), ub (unassemble backward from address), dps (display pointer-sized values with symbols)

   Process:

   1. Batch extraction via PowerShell script (analyze-all.ps1) -- extracted exception code, fault address, AV type, process uptime, thread count, and Claude Code version from all 27 dumps
   2. Classification against known families from the consolidation report
   3. Three detailed deep-dive analyses: one F2 dump (115948), one F4 dump (095059), one F6 dump (110114)
   4. Cross-family comparison of thread state (~*kn), register state, and code paths

   Limitations:

   • No debug symbols for claude.exe -- all function names are nearest-export-symbol artifacts
   • Stack unwinding is impaired by JSC's mixed native/JS frame layout
   • JIT-compiled code regions cannot be disassembled meaningfully (they change per execution)

   ---

   Note

   This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.

   👍React with 👍2Reacted by Joe Brown and RDURKIN-Rx
6. balandari commented on Feb 6, 2026

   

   balandari

   on Feb 6, 2026

   Author

   More actions

   First npm/Node.js Crash Dump Captured

   After switching from Bun to npm (Node.js v22.22.0) to escape the NaN-boxing crashes, we've now captured the first Node.js crash. Different runtime, different crash mechanism.

   Environment

   • Runtime: Node.js v22.22.0 (npm, not Bun)
   • Claude Code version: Current (npm-based)
   • OS: Windows 11
   • Process uptime: 13 minutes 54 seconds
   • Context at crash: ~80% context window, orchestrator was mid-analysis after running tests (heavy thinking)
   • ProcDump config: procdump -ma -e -w node.exe

   Exception

   • Code: 0xC0000005 (Access Violation -- INVALID_POINTER_WRITE)
   • Faulting instruction: mov dword ptr [rdi], ebx at 0x0000033d9b1e2024
   • Write target: 0x0000000000011a18 (near-null, unmapped)

   Registers

   rax=00000000000119a8  rbx=00000000000119b0  rcx=0000000000000000
   rdx=000000000012313c  rsi=0000036654f60111  rdi=0000000000011a18
   rip=0000033d9b1e2024  rsp=00000009183fc2a0  rbp=00000009183fc348
    r8=0000000000011a28   r9=00000000ffffffff  r10=0000033d9b1e1958
   r11=00000000000119a8  r12=0000000000000000  r13=0000013316600080
   r14=0000000000000000  r15=0000000000000000
   

   Multiple registers (rax, rbx, rdi, r8, r11) contain similarly low addresses (0x119a8, 0x119b0, 0x11a18, 0x11a28) -- offsets from a null base object.

   Call Stack (Key Frames)

   ntdll!RtlUserThreadStart
   kernel32!BaseThreadInitThunk
   node+fa4780                          (Node.js entry)
   node!node::Start+0x1e
   node!node::SpinEventLoop+0x195       (event loop)
   node!uv_run+0x3ef                    (libuv)
   node!uv_pipe_pending_type+0x354      (pipe I/O callback)
   node!node_api_throw_syntax_error+... (NAPI dispatch)
   node!node::MakeCallback+0xf7         (native -> JS)
   node!v8::Function::Call+0x134        (V8 call)
   --- V8 JIT code zone ---
   0x0000033d9b1e9f14  x9 frames        (recursive function, counter 12->5)
   0x0000033d9b1e8d0c  x3 frames        (alternate JIT function)
   0x0000033d9b1e2024  <-- CRASH        (null deref with ~72KB offset)
   

   Analysis

   Root cause: V8 JIT null object dereference during recursive execution.

   The faulting IP is on the heap (JIT-compiled JavaScript). A recursive function with a decrementing counter (visible in args: 0xc, 0xb, 0xa... 0x5) was executing when it hit a null object reference. The ~72KB offset (0x11a18) suggests access to a field deep in a large object or indexed array that had been garbage collected while JIT code still held a stale reference.

   The trigger path is: libuv pipe I/O -> NAPI callback -> V8 Function::Call -> JIT recursion -> null deref. This is Claude Code's IPC mechanism triggering JavaScript execution.

   Comparison to Bun Crashes

   Characteristic	Bun crashes (30+ dumps)	This Node.js crash
   Exception code	0xC0000005	0xC0000005
   Pointer pattern	0xfffe/0xffff NaN-boxed	0x00011a18 near-null
   Faulting location	Bun/Zig runtime	V8 JIT JavaScript
   Root cause	NaN-boxed value misinterpreted as pointer	GC'd object still referenced by JIT code
   Deep recursion	Not typically present	9+ recursive frames

   This is a completely different crash family. No NaN-boxed pointers, no Zig runtime involvement. This is a V8 JIT compiler bug -- the generated code doesn't guard against a null reference during optimized recursive execution.

   Implications

   The npm switch eliminated the Bun NaN-boxing crashes (zero Bun crashes since switching), but Node.js/V8 has its own crash vector. Same symptom (unexpected termination during heavy usage at high context), different engine, different mechanism. The common factor across both runtimes appears to be Claude Code's usage pattern: sustained heavy computation with high context and active IPC.

   Note

   This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.
7. balandari commented on Feb 11, 2026

   

   balandari

   on Feb 11, 2026

   Author

   More actions

   Additional Data: npm ~80% Context Crash Pattern

   Adding another data point to the Node.js crash pattern documented in my Feb 6 comment.

   New incident (Feb 10, 2026):

   • Runtime: Node.js v22.22.0 (npm install), Claude Code 2.1.37
   • Trigger: Running /analyze (heavy multi-file analysis) with context at ~80%+
   • Result: Session crashed to command prompt
   • Additional failure: On restart, hit a new error -- SyntaxError: Too many arguments in function call (only 65535 allowed) at cli.js:2026 during ESM module compilation. Restart failed repeatedly before eventually succeeding. Filed separately as [BUG] SyntaxError: Too many arguments (65535 limit) on restart after session crash - Node.js v22.22.0 #24874.

   Pattern strengthening: This is now the second documented npm/Node.js crash at ~80% context during heavy workload. The common factors:

   • npm version (not native/Bun)
   • Node.js v22.22.0
   • Context window at ~80%+
   • Heavy computation (orchestrator analysis, multi-file operations)
   • Windows x64

   The restart failure (#24874) appears to be a secondary issue -- the bundled cli.js hitting a V8 bytecode compilation limit, possibly influenced by system state after the primary crash.

   Note

   This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.
8. balandari commented on Feb 13, 2026

   

   balandari

   on Feb 13, 2026

   Last edited by balandari

   Author

   More actions

   ProcDump Analysis -- 5 Full Dumps on Canary v1.3.9-canary.51 (Windows x64)

   Five crashes within 22 minutes, all captured with ProcDump (-e 1 -ma). First canary dump analysis with full memory.

   Triage Results

   Dump	Family	Exception	Fault Address	Threads	Uptime
   100738	F4	c0000409 (FAST_FAIL)	n/a (int 29h)	40	5:46
   102058	F4	c0000409 (FAST_FAIL)	n/a	46	12:54
   102303	F2	c0000005	0xFFFFFFFFFFFFFFFF (read)	50	1:56
   102516	F2	c0000005	0xFFFFFFFFFFFFFFFF (read)	44	1:41
   102945	F2-new	c0000005	0x1CACC793F40 (execute)	37	3:55

   Distribution: F4 (FAST_FAIL) 40%, F2 (NaN-boxing) 40%, F2-variant (execute AV) 20%.

   F4 Stack Trace -- N-API Cleanup Path Confirmed

   Dump #1 (100738) stack trace via cdb:

   claude!uv_getnameinfo+0x1ea909          <- int 29h (FAST_FAIL trigger)
   claude!llhttp_should_keep_alive+0x12d87
   claude!napi_close_callback_scope+0x89d3f
   claude!napi_close_callback_scope+0x21527
   claude!napi_close_callback_scope+0x204fe
   claude!v8::Value::StrictEquals+0x336581
   claude!v8::Value::StrictEquals+0x337183
   0x0000020e82918413                      <- JIT-compiled code
   

   Three frames through napi_close_callback_scope before the FAST_FAIL_FATAL_APP_EXIT (__fastfail(7)). Bun's internal corruption check fires during N-API callback scope cleanup. This supports the root cause identified in our previous dump analyses: N-API race condition during cleanup triggers use-after-free, Bun detects the corruption and aborts.

   New Variant: Execute AV at Heap Address

   Dump #5 (102945) -- a new crash pattern not seen in our previous 40+ dump analyses:

   ExceptionAddress: 000001cacc793f40
   ExceptionCode: c0000005 (Access violation)
   Attempt to execute non-executable address 000001cacc793f40
   

   The stack is completely trashed -- JSC NaN-boxed tagged values (0xFFFE0000000000A3, 0xFFFE0000000000006) mixed with heap pointers. This is a corrupted function pointer/vtable: JSC tried to call through a pointer that had been freed and reallocated as heap data. Different from the standard F2 NaN-boxing sentinel crashes -- those read from an obviously invalid address, this one tried to execute at a plausible heap address.

   Crash Context and Memory Correlation

   • First crash occurred at >50% conversation context usage, RSS 0.87GB
   • After restart, subsequent crashes happened in under 2 minutes at 1.46-1.99GB RSS
   • Orphaned claude.exe processes from previous crashes remained in memory (Windows crash handler doesn't reliably terminate the process)
   • 5-7 orphaned processes accumulated ~4.5GB combined, creating a feedback loop: crashes leave orphans -> orphan memory pressure -> faster crashes -> more orphans

   Orphaned Process Feedback Loop (Windows-Specific)

   On Windows, when Bun crashes, the claude.exe process often isn't fully terminated. Closing the terminal window also doesn't reliably kill the child process. Each crash-and-restart cycle can leave an orphan holding hundreds of MB. Monitoring command:

   Get-CimInstance Win32_Process | Where-Object {
       $_.ExecutablePath -eq 'C:\Users\Mike\.local\bin\claude.exe'
   } | Sort-Object CreationDate |
   Format-Table ProcessId, @{Label='RSS_MB';Expression={[math]::Round($_.WorkingSetSize/1MB,0)}}, CreationDate -AutoSize

   During this session, 7 claude.exe processes were found when only 2 terminals were active. The 5 orphans consumed ~4.5GB combined. The oldest had been running 6+ hours at 1.16GB.

   bun.report Links Broken for Canary Builds

   None of the bun.report links resolve for canary v1.3.9-canary.51. They return either:

   • {"error":"Could not find debug info for this version of Bun."}
   • HTTP 502 Bad Gateway

   Example links:

   • https://bun.report/1.3.9/e_2d5628dbmgkgEuhogCA2u//Bvuy1+lD
   • https://bun.report/1.3.9/e_2d5628dbmgkgEugogC_A2DD

   Debug symbols are not published for canary builds. This means canary testers cannot use the standard Bun crash reporting path.

   Crash Reports (Bun Panic Handler Output)

   All five crashes on Bun Canary v1.3.9-canary.51 (d5628db2), Windows x64, claude.exe -c --dangerously-skip-permissions:

   Crash 1 (0x7FF79A0A9B19 -- code-space):

   Elapsed: 1442950ms | RSS: 0.87GB | Peak: 0.92GB | Commit: 1.25GB | Faults: 976223
   Features: spawn(296) fetch(50) abort_signal(3)
   bun.report/1.3.9/e_2d5628dbmgkgEuhogCA2u//Bvuy1+lD
   

   Crash 2 (0xFFFFFFFFFFFFFFFF):

   Elapsed: 117496ms | RSS: 1.46GB | Peak: 1.48GB | Commit: 1.20GB | Faults: 810441
   Features: spawn(105) fetch(23)
   bun.report/1.3.9/e_2d5628dbmgkgEugogC_A2DD
   

   Crash 3 (0xFFFFFFFFFFFFFFFF):

   Elapsed: 101135ms | RSS: 1.99GB | Peak: 2.00GB | Commit: 1.72GB | Faults: 1982513
   Features: spawn(109) fetch(41) abort_signal(2)
   bun.report/1.3.9/e_2d5628dbmgkgEuhogC__A2DD
   

   Crash 4 (0x1CACC793F40 -- heap-space execute):

   Elapsed: 235704ms | RSS: 1.32GB | Peak: 1.32GB | Commit: 1.05GB | Faults: 1529725
   Features: spawn(122) fetch(37)
   bun.report/1.3.9/e_2d5628dbmgkgEugogC_____________A20chsg7wzB
   

   Summary

   • Canary v1.3.9-canary.51 does not fix the crash. Same families (F2, F4), same root cause (N-API cleanup race condition), plus a new variant (execute AV at heap address).
   • F4 (FAST_FAIL) is 40% of these crashes with napi_close_callback_scope directly in the call chain.
   • Windows orphaned process accumulation creates a crash feedback loop.
   • bun.report is broken for canary, so standard crash reporting doesn't work for canary testers.
   • 5 full ProcDump captures available if the team wants the dump files.

   Addendum: Two Additional Crashes (Same Session, Post-Restart)

   Two more crashes after the original five, same canary build. CDB analysis on full ProcDump captures.

   New evidence -- F2 shares the N-API cleanup path with F4:

   Dump at 11:53 (F2, 0xFFFFFFFFFFFFFFFF read, 3 min uptime) produced a clean stack trace:

   claude!bmalloc::Mutex::lockSlowCase+0x330860   <- corrupted pointer read (rdi=0x0B71530EFFBB8DB3)
   claude!pas_system_heap_free
   claude!napi_close_callback_scope
   claude!uv_getnameinfo
   KERNEL32!BaseThreadInitThunk
   ntdll!RtlUserThreadStart
   

   napi_close_callback_scope -> pas_system_heap_free -> bmalloc crash on garbage pointer. This is the same entry point as the F4 stack traces above, but F4 catches the corruption early (FAST_FAIL abort) while F2 lets it propagate to the allocator. Direct evidence that F2 and F4 are the same root cause with different detection timing.

   Memory pressure ruled out as necessary condition:

   System state at time of both crashes: 191.7GB total RAM, 167.5GB free (12.6% used), zero orphaned claude.exe processes. The orphan feedback loop documented above makes crashes worse, but is not required to trigger them. These crashes occur on a completely clean system.

   Note

   Embedded Bun version: v1.3.9-canary.51 (d5628db2). Latest stable Bun: v1.3.9. Canary is a pre-release of the same version family -- these crashes are not fixed in stable either.

   This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.
9. balandari commented on Feb 14, 2026

   

   balandari

   on Feb 14, 2026

   Author

   More actions

   Cross-Runtime Analysis: Same Root Cause on Both Node.js and Bun

   Connecting the dots between the Bun crash data (original report + canary analysis above) and the Node.js crash data (Feb 6 and Feb 11 comments).

   Shared Crash Signatures Across Runtimes

   Indicator	Bun (v1.3.5, v1.3.9-canary.51)	Node.js (v22.22.0)
   napi_close_callback_scope	In F2 and F4 stack traces	In crash path
   uv_getnameinfo	Multiple dumps	In crash path
   v8::Value::StrictEquals	Canary dumps 3, 4	Node dump (Feb 10)
   Fault address 0xFFFFFFFFFFFFFFFF	Dominant F2 pattern	Feb 10 dump
   Exception	ACCESS_VIOLATION (c0000005)	ACCESS_VIOLATION (c0000005)

   Reframed Root Cause

   The original report attributed this to Bun's N-API implementation. The Node.js crashes were documented separately as a potentially distinct issue. They aren't.

   Both runtimes crash through the same N-API cleanup path (napi_close_callback_scope), produce the same freed-memory sentinel (0xFFFFFFFFFFFFFFFF) as the fault address, and involve the same V8-compatible API surface (v8::Value::StrictEquals). The native addon code loaded by Claude Code goes through N-API on either runtime, and the race condition between async cleanup and active threads causes use-after-free regardless of the underlying JS engine (JSC or V8).

   This is not a Bun bug or a Node bug. It's a native addon lifecycle bug in Claude Code's N-API usage that manifests on both runtimes. Bun's JSC produces NaN-boxing corruption signatures. Node's V8 produces heap corruption signatures. Same cause, different symptoms.

   Practical Impact

   There is no stable runtime for Claude Code on Windows x64. Switching between npm (Node.js) and native (Bun) temporarily resets accumulated state, but both paths crash within the same session patterns:

   • Bun: 78+ crashes documented (v1.3.5), 24+ today alone on canary (v1.3.9-canary.51) -- with additional uncaptured crashes beyond that
   • Node.js: Crashes at 60%+ context usage, multiple Node versions (22.22.0, 24.0.0, 24.13.0)

   Updating the embedded Bun version will not resolve this if the native addon code itself has the race condition.

   Note

   This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.
10. jw409 commented on Feb 21, 2026

    

    jw409

    on Feb 21, 2026

    Last edited by jw409

    More actions

    Bun was bumped to v1.3.10 — crashes with the same signatures continue.

    Two newer issues report identical fault patterns on the updated runtime:

    • [BUG] Segmentation fault in Bun v1.3.10 (Windows) during long sessions — pipe write crash #27320 (v2.1.50, Bun v1.3.10): Segfault at 0xFFFFFFFFFFFFFFFF — same F2 sentinel address from the original analysis. Stack: uv__process_pipe_write_req -> uv_run.
    • [BUG] Bun segfault crash after ~2h session on Windows x64 (Bun v1.3.10) #26984 (v2.1.47, Bun v1.3.10): Segfault at 0x4B750B20520 — F3 heap address family.

    This is consistent with the cross-runtime analysis posted Feb 14 above, where the same crash path appeared on Node.js v22.22.0. If the root cause is in the native addon's cleanup ordering (as that analysis suggests), runtime version bumps alone may not resolve this.

    Filed #27356 to track the cross-runtime hypothesis separately.
11. 8 remaining items

    Load more

12. ThatDragonOverThere commented on Feb 27, 2026

    

    ThatDragonOverThere

    on Feb 27, 2026

    More actions

    End of Day: 30 Crashes Today, Switching to Node.js (Feb 26)

    This issue has high-priority and oncall labels. It has had them for over a month. Zero Anthropic staff have commented.

    Today: 30 Bun crashes on v2.1.59/v2.1.61. The v2.1.61 config corruption fix shipped today (thank you stevenpetryk on #28847) but the underlying Bun N-API crash is completely unaddressed.

    The user has switched from the native Bun binary to npm install (Node.js runtime) as a last resort. The fact that a paying Max subscriber has to swap out the runtime to make the product usable tells you everything about the state of Windows support.

    The N-API root cause analysis in this thread — with WinDbg dumps, vtable corruption patterns, and crash family classification — has been available since January. The Bun team has a comprehensive bug at oven-sh/bun#27471 filed today with 49 reproductions.

    49 crashes. 33 days. 5 computer lockups. high-priority + oncall for a month. Zero responses.

    What do these labels mean if not "someone should look at this"?

    👍React with 👍1Reacted by Mike Ramsey Jr
13. balandari commented on Feb 27, 2026

    

    balandari

    on Feb 27, 2026

    Last edited by balandari

    Author

    More actions

    I have alternated between native and npm for a few weeks now. I actually have them both installed and switch when one starts giving me fits.
14. balandari commented on Feb 28, 2026

    

    balandari

    on Feb 28, 2026

    Last edited by balandari

    Author

    More actions

    Update: 251+ Crash Dumps, Both Engines, Hardware Ruled Out

    Since the original report, we've continued collecting crash data on both runtimes:

    Current crash dump inventory:

    • 136 Node.js/V8 crash dumps (Feb 22-27, ProcDump captured)
    • 115 archived dumps (mix of Bun/JSC and earlier V8)
    • 251+ total full memory dumps

    Hardware ruled out: Tested across three RAM configurations -- 192GB (4-stick DDR5), 48GB (single-stick DDR5), and currently 96GB (2-stick DDR5). Crash frequency is identical across all three. This is not a memory pressure or IMC thermal issue.

    Node.js is NOT stable either. In response to comments suggesting switching to Node.js as a workaround -- our cross-engine analysis at #27575 documents that Node.js/V8 produces the same category of GC corruption (pointer compression failures, use-after-free, heap corruption) under the same Claude Code workload. We have 136 V8 crash dumps with 10 distinct signatures across 7 categories to prove it. The crash mechanism differs (V8 pointer compression vs JSC NaN-boxing) but the outcome is identical: session-destroying crashes that scale with context fullness.

    Crash distribution (last 6 days, Node.js only):

    Date	Crashes
    Feb 22	57
    Feb 23	5
    Feb 24	5
    Feb 25	3
    Feb 26	8
    Feb 27	58

    Heavy build days (Feb 22, 27) produce 10x the crashes of light days. The context-fullness model from #27575 holds: more subprocess spawning and deeper context = more GC pressure = more crashes.

    The common denominator is Claude Code's workload, not the runtime. Swapping engines changes the crash signature but not the crash rate.

    Note

    This comment was written by Claude (Opus 4.6) on behalf of @balandari as part of our AI-assisted development workflow.

    👍React with 👍1Reacted by Joe Brown
15. joe-hireable commented on Mar 2, 2026

    

    joe-hireable

    on Mar 2, 2026

    More actions

    I'm having similar issues. I've identified that my CPU microcode is on version 0x120, which is significantly outdated and apparently can cause these issues. I have the same 14900 HX CPU. Is your BIOS version the same? I have been informed 0x12F fixes the issues.
16. balandari commented on Mar 3, 2026

    

    balandari

    on Mar 3, 2026 via email

    Author

    More actions

    Interesting, I am just now exploring the same issue with the CPU microcode being outdated. My i9-14900HX is on microcode 0x11F. it is not supposed to affect laptop CPU's, according to Intel, and MSI doesn't have an updated BIOS for this laptop listed on their website. I am about to call them and see if they have an update they can share with me. According to Claude, the microcode fix is 0x12B. I am willing to try just about anything right now. So tired of all these crashes. MSI does have the BIOS 0x12B released for their desktops. Fingers crossed. I will give an update if anything changes.

    …

    On Mon, Mar 2, 2026 at 10:25 AM Joe Brown ***@***.***> wrote: *joe-hireable* left a comment (anthropics/claude-code#21875) <#21875 (comment)> I'm having similar issues. I've identified that my CPU microcode is on version 0x120, which is significantly outdated and apparently can cause these issues. I have the same 14900 HX CPU. Is your BIOS version the same? I have been informed 0x12F fixes the issues. — Reply to this email directly, view it on GitHub <#21875 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANE2IP4R23I6C66YJWLW6AD4OWYXNAVCNFSM6AAAAACTMYENYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSOBVGQYDSNJQHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

    -- Mike Ramsey Jr. Full-Stack Web Developer (316) 200-6729 | mikeramseyjr.com React • Next.js • TypeScript • Vercel 6 production sites shipped in 10 weeks
17. joe-hireable commented on Mar 3, 2026

    

    joe-hireable

    on Mar 3, 2026

    More actions

    Interesting, I am just now exploring the same issue with the CPU microcode
    being outdated. My i9-14900HX is on microcode 0x11F. it is not supposed to
    affect laptop CPU's, according to Intel, and MSI doesn't have an updated
    BIOS for this laptop listed on their website. I am about to call them and
    see if they have an update they can share with me. According to Claude, the
    microcode fix is 0x12B. I am willing to try just about anything right now.
    So tired of all these crashes. MSI does have the BIOS 0x12B released for
    their desktops. Fingers crossed. I will give an update if anything changes.
    …

    "Apparently" being the key word. Intel said it didn't affect the portable chips but loads of users on forums etc complained of the issue. This said it's a separate issue from the bun segfault stuff - Claude Code/Bun (I believe Bun is now owned by Anthropic) needs to fix this still.

    My laptop is PC Specialist. Have had to ask them for the BIOS update too. Let me know how you get on because I'm ripping my hair out atm 😂

    It's a bit temperamental but you can also try running Claude Code in a devcontainer. There's docs on it on Anthropic - it's kinda temperamental but at least no BSODs
18. balandari commented on Mar 3, 2026

    

    balandari

    on Mar 3, 2026 via email

    Author

    More actions

    Nothing available... Going to send it to the engineering department and see if they have anything and should get back to me in a couple days... I am not holding my breath...

    …

    On Tue, Mar 3, 2026 at 1:24 PM MIKE RAMSEY JR ***@***.***> wrote: Interesting, I am just now exploring the same issue with the CPU microcode being outdated. My i9-14900HX is on microcode 0x11F. it is not supposed to affect laptop CPU's, according to Intel, and MSI doesn't have an updated BIOS for this laptop listed on their website. I am about to call them and see if they have an update they can share with me. According to Claude, the microcode fix is 0x12B. I am willing to try just about anything right now. So tired of all these crashes. MSI does have the BIOS 0x12B released for their desktops. Fingers crossed. I will give an update if anything changes. On Mon, Mar 2, 2026 at 10:25 AM Joe Brown ***@***.***> wrote: > *joe-hireable* left a comment (anthropics/claude-code#21875) > <#21875 (comment)> > > I'm having similar issues. I've identified that my CPU microcode is on > version 0x120, which is significantly outdated and apparently can cause > these issues. I have the same 14900 HX CPU. Is your BIOS version the same? > I have been informed 0x12F fixes the issues. > > — > Reply to this email directly, view it on GitHub > <#21875 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ANE2IP4R23I6C66YJWLW6AD4OWYXNAVCNFSM6AAAAACTMYENYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSOBVGQYDSNJQHA> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > -- Mike Ramsey Jr. Full-Stack Web Developer (316) 200-6729 | mikeramseyjr.com React • Next.js • TypeScript • Vercel 6 production sites shipped in 10 weeks

    -- Mike Ramsey Jr. Full-Stack Web Developer (316) 200-6729 | mikeramseyjr.com React • Next.js • TypeScript • Vercel 6 production sites shipped in 10 weeks

    👍React with 👍1Reacted by Joe Brown
19. joe-hireable commented on Mar 3, 2026

    

    joe-hireable

    on Mar 3, 2026

    More actions

    You can try this as well maybe as an interim measure - didn't work for me but might do for you:
    https://rog-forum.asus.com/t5/rog-strix-series/intel-how-to-update-your-microcode-for-intel-hx-13-14th-cpus/td-p/1034755
20. XekriRedmane commented on Mar 7, 2026

    

    XekriRedmane

    on Mar 7, 2026

    More actions

    I'm suspicious that it's a microcode issue. I have a Snapdragon(R) X 12-core X1E80100, which is an ARM processor, not Intel, and I also get BUN crashes.
21. github-actions

    added

    staleIssue is inactiveIssue is inactive

    on Mar 22, 2026
22. jw408 commented on Apr 7, 2026

    

    jw408

    on Apr 7, 2026

    More actions

    Closing — Bun has shipped multiple fixes for WSL segfaults since v1.3.5. No longer reproducing on current versions.
23. jw408 commented on Apr 7, 2026

    

    jw408

    on Apr 7, 2026

    More actions

    Closing — Bun has shipped multiple WSL segfault fixes since v1.3.5. No longer reproducing on current versions. Can be reopened if it recurs.
24. github-actions

    removed

    staleIssue is inactiveIssue is inactive

    on Apr 7, 2026
25. jw409 commented on Apr 7, 2026

    

    jw409

    on Apr 7, 2026

    More actions

    Closing — Bun has shipped multiple WSL segfault fixes since v1.3.5. No longer reproducing on current versions.
26. github-actions

    added

    staleIssue is inactiveIssue is inactive

    on May 6, 2026