https://gitlab.synchro.net/main/sbbs/-/issues/1151#note_9449
Fixed in commit 6816ce611 (`carries-19-baby`).
Two complementary changes:
1. **`xpdev/multisock.c`** — every listen socket, and every accepted client socket, is now marked non-inheritable on Windows via `SetHandleInformation(HANDLE_FLAG_INHERIT, 0)` immediately after creation. Since this is the shared listen-socket path for all servers (Terminal/Mail/FTP/Web/Services), a spawned child can no longer inherit a listen socket regardless of any `CreateProcess` inheritance flag. This closes the leak at the source.
2. **`sbbs3/xtrn.cpp` `external()`** — `bInheritHandles` is no longer passed `TRUE` unconditionally for the native/online path. It is now `TRUE` only when the child actually needs to inherit a handle we're sharing:
- the redirected stdio pipes (`use_pipes`), or
- the duplicated passthru/client socket that a native socket-door talks over (`native && passthru_thread_running && client_socket_dup != INVALID_SOCKET`).
A timed event running `jsexec` (the case in this report) shares neither, so it now gets `bInheritHandles=FALSE`. DOS doors communicate via named mailslots/events and never needed inheritance.
Approach #1 alone resolves the reported symptom; #2 is additional hygiene so we don't hand the duplicated client socket (or any future inheritable handle) to children that don't use it.
Tested locally on Windows. The POSIX `O_CLOEXEC`/`FD_CLOEXEC` audit noted in the report remains a separate follow-up.
— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
* Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)