Repository navigation
V8 Maglev JIT causes STATUS_STACK_BUFFER_OVERRUN (0xC0000409) on Windows 11 Insider build 26200 #62260
Description
Activity
- added a commit that references this issue
on Mar 16, 2026 I think this might be the same issue we are observing in the CI: https://github.com/nodejs/reliability/blob/main/reports/2026-03-17.md there are a bunch of tests related to HTTP crashing with the same code on Windows
@nodejs/v8 could someone please take a look? It seems like there is an issue with maglev :)
Reacted by Tobbe LundbergI think this might be the same issue we are observing in the CI: https://github.com/nodejs/reliability/blob/main/reports/2026-03-17.md there are a bunch of tests related to HTTP crashing with the same code on Windows
For posterity, this was likely a separate issue (#63620).
- added a commit that references this issue
on Jun 30, 2026 - added a commit that references this issue
on Jul 1, 2026 Additional data point, possibly the same underlying defect:
- Node v24.12.0 on Windows 11 build 10.0.26200 (release channel, not Insider) fast-fails with the same exit code
-1073740791(0xC0000409) a few seconds after startup, running an interactive TUI host (senpi+ a large ESM extension bundle). - Our failure signature differs from the reporter's: the dump shows FastFail parameter
0x5(FAST_FAIL_INVALID_ARG) raised from the UCRT invalid-parameter handler, with an fs temp-file path on the crashing thread's stack. No JS stack, no stderr, no WER event — same bypass behavior. --no-maglevdid not prevent it in our case.- Behavior-preserving source perturbations of the hot functions (e.g. wrapping a call in
try/catch) reliably avoided the crash, which is why we suspect JIT-tier involvement despite the different subcode. - Node 24.19.0 and 22.23.2 do not crash with the identical workload (survived 20x+ the crash window; 24.12.0 crashed 5/5).
So if a fix landed between 24.12.0 and 24.19.0, it likely covers this variant too; if not, there may be a second Windows-26200-specific fast-fail path in the 24.x line.
- Node v24.12.0 on Windows 11 build 10.0.26200 (release channel, not Insider) fast-fails with the same exit code
Independent corroboration on the same Windows build, from a different workload, plus a reproducer that crashes on demand rather than after 20-70 seconds. One result differs from the report above:
--no-maglevreduces the crash rate here but does not eliminate it.Environment
- Node v24.15.0, V8 13.6.233.17-node.48, libuv 1.51.0, x64
- Windows 11 Pro, build 10.0.26200.9457 (same 26200 line as the original report)
- 16 CPUs, 30 GB
What it looks like
Running a test suite with
node --test, individual test files fail with the parent exit code 1 and a child exit code of3221226505(0xC0000409). Every time:not ok 1 - c.test.mjs --- duration_ms: 630.5697 failureType: 'testCodeFailure' exitCode: 3221226505 signal: ~ error: 'test failed' code: 'ERR_TEST_FAILURE'- zero subtests reported for the affected file, so the child dies at or before its first test result
- zero bytes on stderr, no JavaScript stack, no
FATAL ERROR:line - no Windows Error Reporting event (no 1000/1001/1026 in the Application log, while other events land normally in the same window), consistent with
__fastfail --report-on-fatalerrorwrites no report. That proves nothing on its own: a forcedprocess.abort()with the same flags also writes no report on this build- the affected file moves around: 12 distinct files so far, each passing on its own immediately afterwards
- it is not TypeScript related. The suite normally runs
.tsfiles through type stripping; compiled to plain JavaScript first, it crashes at the same rate (3 crashes / 210 full-suite runs each way)
Reproducer
Two files, no dependencies. The generator makes a small import graph; the test file starts an ephemeral-port HTTP server per test.
// make-mods.mjs -> node make-mods.mjs import { mkdirSync, writeFileSync } from 'node:fs'; mkdirSync('mods', { recursive: true }); for (let i = 0; i < 54; i++) { const next = i < 53 ? `export { v${i + 1} } from './m${i + 1}.mjs';` : ''; writeFileSync(`mods/m${i}.mjs`, `${next}\nexport const v${i} = ${i};\n`); }
// c.test.mjs import { test } from 'node:test'; import assert from 'node:assert/strict'; import { createServer } from 'node:http'; import { readFileSync } from 'node:fs'; import { v0 } from './mods/m0.mjs'; const once = (s, ev) => new Promise((r) => s.once(ev, r)); assert.equal(v0, 0); for (let i = 0; i < 30; i++) { test(`server ${i}`, async () => { const self = readFileSync(new URL(import.meta.url), 'utf8'); assert.ok(self.length > 0); const server = createServer((_req, res) => { res.writeHead(200, { 'content-type': 'text/html' }); res.end('<h1>ok</h1>'); }); server.listen(0, '127.0.0.1'); await once(server, 'listening'); const { port } = server.address(); const res = await fetch(`http://127.0.0.1:${port}/`); assert.equal(await res.text(), '<h1>ok</h1>'); server.closeAllConnections(); server.close(); await once(server, 'close'); }); }
Then run it many times, 16 concurrently, and count the signature:
seq 1 2000 | xargs -P 16 -I{} sh -c \ 'out=$(node --test --test-reporter=tap c.test.mjs 2>&1); case "$out" in *3221226505*) echo hit;; esac'
2 hits in 2000 invocations (0.10%) here. A larger real test file reproduces at 10 hits in 3000 invocations (0.33%), which is what the flag numbers below were measured against.
One negative worth recording: spawning the same file without the test runner (
node c.test.mjs, 600 spawns, 16 concurrent) produced no crash. It appears to need the runner's child process path.Flags, all measured the same way, 3000 invocations each
Flag Signature hits Note (none) 10 / 3000 0.33% --no-maglev2 / 3000 ~5x lower, not eliminated --no-turbofan9 / 3000 no effect --jitless2 / 3000 not a like-for-like control: fetchis unavailable, so every invocation fails early and does far less work before exiting. Recorded only as "still reproduces"So on this build the crash is reduced but not removed by disabling Maglev, and TurboFan looks unrelated. That may mean a second trigger beyond Maglev-compiled code, or that the flag changes timing rather than removing the fault. I did not want to report
--no-maglevas a workaround when it still crashed twice.Happy to run further flag combinations, or a patched build, against the reproducer. Each 3000-invocation measurement takes about 15 minutes here.
What happened?
Node.js processes crash with exit code
-1073740791(0xC0000409/STATUS_STACK_BUFFER_OVERRUN) within 20-70 seconds of startup when running a non-trivial application (WebSocket server with HTTP, Telegram bot polling, and plugin system) on Windows 11 Insider (Canary channel).The crash is caused by V8's Maglev JIT compiler tier. Workaround:
--no-maglevflag eliminates the crash entirely.Reproduction
Environment:
Steps:
fetch(), WebSocket, and timers on Windows 11 Insider build 26200-1073740791(0xC0000409) within 20-70 seconds__fastfailFlags tested:
fetch()works?--jitless--no-maglev--no-turbofan--no-maglevis the minimal workaround — disabling only the Maglev tier prevents the crash while keeping TurboFan and fetch() functional.Additional context:
http.createServer) does NOT crash — the issue requires enough code to trigger Maglev optimization__fastfail/ SEH)Expected behavior
Node.js should not crash with STATUS_STACK_BUFFER_OVERRUN. Maglev-compiled code should respect Windows CFG/CET enforcement on Insider builds.
Workaround
Pass
--no-maglevas a command-line flag (cannot be set viaNODE_OPTIONS):