Skip to content

Bug: WebSocket server port stays LISTENING under a dead PID after OBS closes (Windows), causing WSAEADDRINUSE on next launch #1343

Description

@moshlp

Operating System Info

Other

Other OS

Windows 10, version 22H2, build 19045

OBS Studio Version

Other

OBS Studio Version (Other)

32.1.2

obs-websocket Version

5.1.0

OBS Studio Log URL

https://obsproject.com/logs/a5akxKlHfcboNIw6

OBS Studio Crash Log URL

No response

Expected Behavior

obs-websocket binds to the configured port (4455) successfully on every OBS launch, and external WebSocket clients (e.g. Streamer.bot) can connect normally.

Current Behavior

After closing OBS (normally, or via Stop-Process -Force on obs64.exe) and relaunching it, obs-websocket fails to bind port 4455 with:

[obs-websocket] [WebSocketServer::Start] Listen failed: Only one usage of each socket address (protocol/network address/port) is normally permitted

netstat shows port 4455 still LISTENING under the PID of the previous OBS session, even though that process no longer exists (confirmed via tasklist, Get-Process, Get-CimInstance, and Process Explorer's "Find Handle" — none find any owner for the socket or PID). Get-NetTCPConnection shows the listening socket's CreationTime matches the previous session's startup, not the current one.

Connected external clients (Streamer.bot via OBS-WebSocket v5) establish a raw TCP connection to this orphaned listener, which never responds to the Hello/Identify handshake, times out after ~90s, and retries indefinitely. Only a full Windows reboot clears the orphaned socket.

Steps to Reproduce

  1. Start OBS. Confirm obs-websocket binds to port 4455 (works on first launch after reboot).
  2. Connect an external client (e.g. Streamer.bot) to ws://127.0.0.1:4455/api/websocket. Confirm it connects.
  3. Close OBS (tested via window X and via Stop-Process -Force on obs64.exe — same result either way).
  4. Reopen OBS.

Anything else we should know?

obs-websocket Version: 5.7.3

Ruled out as causes (tested individually, no effect):

  • net stop/start winnat
  • Restart-Service hns -Force (after wsl --shutdown)
  • Restart-Service iphlpsvc -Force
  • netsh interface portproxy show all → empty
  • netsh interface ipv4 show excludedportrange → port 4455 not in any reserved range (rules out Hyper-V/WSL)
  • Killing unrelated processes (DroidCam's adb.exe) → no effect
  • Closing the external client BEFORE closing OBS → orphaned LISTENING socket still appears

Most conclusive test: Stop-Process -Force on obs64.exe, confirmed via tasklist that the process is fully gone, waited 10+ seconds — netstat still shows port 4455 LISTENING under the dead PID.

WebSocket server is configured with default settings (dual-stack, binds both 0.0.0.0:4455 and [::]:4455 — log shows "Not locked to IPv4 bindings"). Windows is reasonably up to date (cumulative updates from ~6 weeks ago at time of testing).

Happy to provide Streamer.bot logs and Get-NetTCPConnection output on request.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions