NODE_PENDING_PIPE_INSTANCES causes 0xC0000005 crash on Windows when a named-pipe listen() loses a bind race (EADDRINUSE)

Version

Reproduces on v22.19.0, v22.23.2, v24.11.1, v24.19.0, v26.7.0 (latest of each supported line as of 2026-08-05). Does not reproduce on v20.19.2.

Platform

Windows 11 x64 (also observed on windows-latest GitHub Actions runners).

Subsystem

net / libuv (Windows named pipes)

What steps will reproduce the bug?

Set NODE_PENDING_PIPE_INSTANCES, then try to listen() on a named pipe whose name is already taken. The EADDRINUSE error is delivered normally, but the process then dies with an access violation (exit code 0xC0000005 / 3221225477, -1073741819) while closing the failed server handle — no JS stack, no assertion message.

// repro.js — crashes with 0xC0000005 on Node 22/24/26; prints "survived" without the env var (or on Node 20)
process.env.NODE_PENDING_PIPE_INSTANCES = '32';
const net = require('net');
const PIPE = '\\\\.\\pipe\\pw-repro-' + process.pid;
const a = net.createServer(() => {});
a.listen(PIPE, () => {
  const b = net.createServer(() => {});
  b.on('error', err => {
    console.log('bind failed as expected:', err.code);   // EADDRINUSE
    setTimeout(() => { console.log('survived'); a.close(); }, 500);
  });
  b.listen(PIPE);   // loses the bind — node then closes the failed handle → crash
});

> node repro.js
bind failed as expected: EADDRINUSE
(process dies with 0xC0000005)

Result matrix:

node	NODE_PENDING_PIPE_INSTANCES=32	unset
v20.19.2	survives	survives
v22.19.0 / v22.23.2	crash	survives
v24.11.1 / v24.19.0	crash	survives
v26.7.0	crash	survives

What is the expected behavior?

The losing listen() emits EADDRINUSE and the process continues. Racing binds on a well-known pipe name is a standard singleton-election pattern on Windows (first bind wins via FILE_FLAG_FIRST_PIPE_INSTANCE), so losing the race is an expected, recoverable condition.

What do you see instead?

The process dies with 0xC0000005 (access violation) with no further output, after the error event has been delivered.

Additional information — root cause in libuv (src/win/pipe.c)

When the env var is set, node's lib/net.js (createServerHandle) calls handle.setPendingInstances() → uv_pipe_pending_instances(), which sets the UV_HANDLE_PIPESERVER flag immediately — before any bind, while handle->pipe.serv.accept_reqs is still NULL:

void uv_pipe_pending_instances(uv_pipe_t* handle, int count) {
  if (handle->flags & UV_HANDLE_BOUND)
    return;
  handle->pipe.serv.pending_instances = count;
  handle->flags |= UV_HANDLE_PIPESERVER;    /* <-- set before bind */
}

uv_pipe_bind2() allocates accept_reqs, but on failure (here: ERROR_ACCESS_DENIED from CreateNamedPipeW with FILE_FLAG_FIRST_PIPE_INSTANCE → mapped to UV_EADDRINUSE) its error path frees accept_reqs and resets it to NULL — without clearing UV_HANDLE_PIPESERVER.

Node then closes the handle; uv__pipe_close() trusts the flag and walks the accept requests:

if (handle->flags & UV_HANDLE_PIPESERVER) {
  for (i = 0; i < handle->pipe.serv.pending_instances; i++) {
    pipeHandle = handle->pipe.serv.accept_reqs[i].pipeHandle;  /* accept_reqs == NULL → AV */
    ...

(Debug builds die earlier, on assert(handle->pipe.serv.accept_reqs) in uv__pipe_endgame().)

Without the env var, uv_pipe_pending_instances() is never called, the flag is only set by a successful bind, and the crash path is unreachable — matching the observed gating.

How we hit this

Playwright set NODE_PENDING_PIPE_INSTANCES=32 to work around slow accept-replenishment on busy named-pipe servers (default 4 pending instances). Any child process that inherited the env and lost a deliberate singleton bind race then crashed the daemon with 0xC0000005 on all Windows CI jobs (microsoft/playwright#42128).

从 src/win/pipe.c 开始，重点查看 uv_pipe_pending_instances()、uv_pipe_bind2() 和 uv__pipe_close()，然后检查 lib/net.js，了解待处理实例的配置方式。在设置 NODE_PENDING_PIPE_INSTANCES 的情况下于 Windows 上运行 repro.js；当竞争失败的 named-pipe listen 发出 EADDRINUSE 且进程继续运行时，即表示完成。