Repeated Bun v1.3.5 segfaults -- 78 crashes, root cause identified (Windows + WSL)

[balandari]

Repeated Bun Segfaults -- Comprehensive Report (Windows + WSL)

78 crashes documented | Jan 30 -- Feb 5, 2026 | Zero user-side mitigations effective

Claude Code's embedded Bun v1.3.5 segfaults repeatedly under normal usage on Windows x64. Crashes occur during active work, idle sessions, typing, right-clicking, and even on startup. No user-side configuration change prevents them.

This issue has been consolidated from 85 individual crash reports into a single structured document. Dump file analysis (ProcDump/WinDbg stack traces and variant classifications) will follow as a separate comment.

No further crash reports will be posted to this issue. We have documented 78 crashes across 7 days with full diagnostic data, identified root causes mapping to known Bun bugs, tested and eliminated every user-side mitigation, and provided 8 full memory dumps (7.5GB+). The evidence is comprehensive. The fix -- updating the embedded Bun version -- is on Anthropic's side.

---

Environment

Component	Value
OS	Windows 11 x64 (Build 26200)
CPU	Intel i9-14900HX (32 logical, sse42/avx/avx2)
RAM	192GB
Claude Code	v2.1.x (multiple versions across reporting period, currently v2.1.31)
Embedded Bun	v1.3.5 (1e86cebd) -- 3 versions behind latest 1.3.8
Node.js	v22.22.0 (clean install)
WSL (cross-platform test)	WSL2, kernel v6.6.87, glibc 2.39

Installation methods tested (crashes persisted across all four):

1. Windows native install
2. Windows npm install (npm install -g @anthropic-ai/claude-code)
3. WSL native install
4. WSL npm install

The embedded Bun v1.3.5 was the constant across every configuration. Currently running Windows native install.

---

Crash Families

Three distinct crash families identified through signature analysis:

Family 1: Worker Thread Cleanup (Use-After-Free)

• Thread: Worker (not main)
• Timing: Early in session (seconds to minutes)
• Stack signature: KERNEL32.DLL + ntdll.dll
• Addresses: 0x108, 0x150, 0x12300000007, 0x20600000010
• Spawn counts: Low (41-130)
• Maps to: oven-sh/bun#18198 -- worker thread cleanup use-after-free (known since March 2025)

Family 2: Main Thread / JSC GC (Use-After-Free)

• Thread: Main
• Timing: Variable (seconds to 2+ hours)
• Mechanism: JSC garbage collector use-after-free during MarkedBlock sweep after abort_signal frees WatchpointSets
• Addresses: 0x0, 0x6, 0x7, 0xA, 0xFFFFFFFFFFFFFFFE, 0xFFFFFFFFFFFFFFFF, and other near-null values
• Correlation: Higher abort_signal counts and page faults track with higher spawn volumes
• Maps to: JSC GC use-after-free documented across 6+ issues in Bun's tracker. Other Bun-based AI tools (opencode) trigger identical crashes.

Family 3: Heap Address Crashes

• Thread: Main
• Addresses: Non-null, non-near-null heap addresses (0x28727DC0024, 0x292288EB1E0, 0x94E3800000, 0xD731E00000, 0x7EDD96561004, etc.)
• Behavior: Pointer dereference into heap memory that's been freed or corrupted
• Overlap: Likely the same underlying GC corruption as Family 2, manifesting at different points in the object graph

---

Root Cause Analysis

Primary: N-API Async Cleanup Race Condition

Identified via ProcDump/WinDbg memory dump analysis:

1. Main thread executes napi_remove_async_cleanup_hook (destroying async resources)
2. 5+ worker threads simultaneously inside napi_unref_threadsafe_function (using same resources)
3. A worker thread runs a second uv_run event loop inside napi_unref_threadsafe_function
4. Cleanup frees/corrupts function pointer while workers still hold references
5. TTY input processing follows corrupted pointer -> ACCESS_VIOLATION

Secondary: NaN-Boxing Value Corruption

All 5 analyzed memory dumps share one pattern: JSC engine using NaN-boxed JavaScript values as raw memory pointers.

• 0xFFFE... prefix encodes type information in high bits (NaN-boxing)
• When GC corrupts the tagged value, the engine dereferences type metadata as a memory address
• Manifests in both native runtime code and JIT-generated code

Contributing: TTY/SIMD Intersection

Both stack trace paths share uv_tty_get_vterm_state and simdutf::get_active_implementation. The interaction between terminal I/O handling and SIMD string processing creates an additional corruption vector. This explains why crashes can be triggered by typing or right-clicking.

---

Key Patterns Discovered

Idle Crashes

Terminals crash while completely idle -- no user activity needed.

• 133-minute idle session (Crash Add bash/emacs keybindings to move around options #33, 3,783 spawns)
• 102-minute idle session (Crash I cannot start claude #15, 437 spawns)
• 16-minute idle with lowest-activity profile (Crash How is .env file handled? #36, 275 spawns)

Cascade Degradation

Repeated crashes cause accelerating time-to-crash on restart:

• Crash Transparency in Context Window Construction for AI Assistants #21: 9.7 min -> Model Selection Flexibility for Cost-Effective AI Interactions #22: 37s -> public release has happened :-D #23: 1.9 min -> Rename DEBUG env option to CLAUDE_DEBUG #24: 52s -> Error on first run on Windows #25: 32s -> Incorrect PowerShell Build Command for .NET Project #26: 12s
• Peak RSS stays above 1.4GB across restarts despite minimal work
• Conversation transcript accumulation appears to compound GC pressure

Cross-Platform Confirmation

Crashes persist identically on WSL2/Linux (same Bun 1.3.5). This rules out Windows-specific causes. RSS reporting was corrupted on WSL (reported 0.02ZB).

Spawn Amplification

Our workflow uses multi-agent orchestration -- up to 6,165 JSC spawns per session (typical Claude Code usage: 10-50). High spawn volume widens the race condition window by orders of magnitude, but crashes also occur at low spawn counts (25 spawns in 5 seconds for Crash #52).

UI Event Triggers

• Right-click to copy (Crash OAuth error: fetch failed #40)
• Typing input (Crashes /cost command results do not render well in dark mode terminals #41, Auto-compact to avoid "input length and max_tokens exceed context limit" errors #42, open source? #59, Fix Docker build issues on Windows and non-ARM architectures #62)
• Explained by the TTY handling path identified in dump analysis

Silent Crashes (FAST_FAIL)

Bun detects corruption internally and calls __fastfail(FATAL_APP_EXIT). No "oh no: Bun has crashed" message, no bun.report URL. Process just disappears. Unknown number of additional silent crashes may have gone unreported.

ProcDump Bypass

Bun's internal crash handler intercepts segfaults before Windows' AeDebug mechanism fires. External crash dump tools cannot capture Bun crashes via normal means. Workaround: ProcDump live-attach (first-chance exception monitor).

Thread Count Escalation

Across analyzed dumps, thread counts escalated: 22 -> 26 -> 36 -> 37 threads, with napi_unref_threadsafe_function instances growing from 5 to 10.

---

Unique Crash Addresses (~35 distinct)

Address	Category	Notes
0x0	Null deref	Most common on WSL
0x6	Near-null	Corrupted vtable
0x7	Near-null	Most common on Windows
0xA	Near-null	Both platforms
0x10	Near-null
0x20	Near-null	Worker thread
0x48	Low offset
0x8C	Low offset
0x108	Family 1	Worker, KERNEL32+ntdll
0x150	Family 1	Worker, KERNEL32+ntdll
0x1E2	Low
0x1E3B5	Low	Null + struct offset
0xCEEE	Low	Null + struct offset
0x24018	Struct	Use-after-free struct
0x3FFFFF01	Mid-range
0xFFFFFFFFFFFFFFFE	Sentinel	Second most common overall
0xFFFFFFFFFFFFFFFF	Sentinel	Third most common overall
0x650063006D	Unknown	Original Crash #1
0x12300000007	Family 1	Worker
0x20600000010	Family 1	Worker
0x26C19AF3800	Heap	Startup crash
0x28727DC0024	Heap
0x292288EB1E0	Heap
0x94E3800000	Heap
0x103010000	Heap	Startup, 181ms
0xD731E00000	Heap
0x1AB0BCF9BB0	Heap	ProcDump bypassed
0x1DE0F6B53B1	Heap
0x7EDD96561004	Heap	WSL
0x7DE1D7400000	Heap	WSL
0x7830E686D640	Heap	WSL
0x708DA96CCA64	Heap	WSL
0x000001FF00000003	Variant E	Partial pointer corruption
0xFFFE0000000003D2	JIT	NaN-boxed integer 978

---

Mitigation Attempts -- All Failed

Every user-side mitigation was tested systematically. None prevented crashes.

Mitigation	Result
Hook consolidation (9 -> 4 entries, 7 -> 2 spawns/op)	Crash still occurred within 45 min
Further hook stripping (4 -> 3, zero spawns on read ops)	Crash #52: 25 spawns in 5 seconds
npm install (bypass embedded Bun, use Node.js)	Different stability issues (crashes to command prompt)
Single instance, single terminal	Crash #55: crashed anyway
Chrome MCP disabled	Crash #56: crashed anyway
WSL migration	Same crashes, cross-platform confirmed
Clean Node.js install (v22.22.0)	No effect
Hook path format (backslash -> forward slash)	No effect

Three-Factor Resolution -- Posted Then Immediately Retracted

A resolution was claimed combining: (1) reduced subprocess spawns, (2) hook path format fix, (3) clean Node.js. Evidence: 5+ crash-free sessions including a 124-second agent run.

Retracted within hours. Three crashes occurred immediately after posting. Quote: "Hook migration had zero effect on crash prevention. Three-factor resolution is fully retracted."

Theories Systematically Eliminated

Theory	Evidence Against
Multi-instance resource contention	Crash #55: single instance, single terminal
VS Code terminal infrastructure	Same crashes in PowerShell and cmd
Hook/subprocess spawn volume	Crash #52: 25 spawns in 5 seconds
Memory accumulation	Crashes at 0.73-0.99GB RSS (192GB system)
Chrome MCP overhead	Crash #56: Chrome MCP disabled
Windows-only	WSL crashes identical

Conclusion: Bun 1.3.5 on x64 segfaults under normal single-instance usage. No user-side configuration change mitigates it.

---

Investigation Timeline

Date	Phase	Crashes	Key Events
Jan 30	Discovery	~13	Initial 3 crashes, then 10 more. Crash families identified.
Jan 30-31 eve	Cascade	~18	15 crashes in one evening. Idle crash discovery. Cascade degradation (9.7min -> 12s).
Jan 31 day	Escalation	~18	18 crashes in single day. Root cause research published. npm workaround attempted.
Feb 1	WSL migration	~20	Moved to WSL2. Crashes persisted (cross-platform confirmed). Hook consolidation applied.
Feb 1-2	WSL intensive	~10	Heavy null-deref pattern. 0.02ZB RSS anomaly.
Feb 3	Windows return	~4	UI event triggers discovered (right-click, typing).
Feb 3-4	Resolution attempt	~5	Three-factor resolution posted, immediately retracted.
Feb 4 early	Elimination	~15	Hook stripping, single-instance testing. All user-side theories eliminated.
Feb 4 afternoon	ProcDump analysis	~8	Full memory dump captures. WinDbg analysis. N-API race condition and NaN-boxing corruption identified.
Feb 5	Final analysis	3	New Variant E (partial pointer corruption). JIT crash sub-variant confirmed.

Total: ~78 crash events across 7 days.

---

The Ask

1. Update the embedded Bun version. v1.3.5 is 3 versions behind. v1.3.6 fixes an integer overflow crash path. v1.3.7 includes a JSC upgrade addressing the GC issues in Family 2.

2. Acknowledge the scope. 78 crashes, 35 unique addresses, 8 full memory dumps (7.5GB), root cause identified via ProcDump/WinDbg to N-API async cleanup race conditions and NaN-boxing value corruption. Zero Anthropic responses across 86 comments over 7 days.

3. No further reports. We consider this issue comprehensively documented. Every user-side mitigation has been tested and eliminated. The fix is a Bun version bump, which only Anthropic can apply.

---

Closing Statement

This issue has been consolidated from 85 individual crash report comments into this single structured document. The original per-crash comments have been removed to improve readability. Dump file analysis (27 full memory dumps, F1-F6 crash family classifications, unified root cause model) has been posted as a follow-up comment below.

We will not be posting additional Bun crash reports. After 78 documented crashes with full diagnostic data across Windows native and WSL, with root causes identified and mapped to known Bun bugs, we believe the evidence is sufficient. Continued reporting would be redundant. The ball is in Anthropic's court.

---

Note

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

[github-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

[balandari]

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.

[balandari]

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.