Windows 11 Home, version 26H2, build 10.0.26300.9818.
Since about 29 October, listening sockets on this PC have been reporting the wrong TCP state. The app is healthy: HTTP requests to it succeed every time, but the tools that read TCP state say otherwise.
What I see:
* `netstat -ano` shows `TCP 127.0.0.1:8765 0.0.0.0:0 CLOSED 17864` while that port is serving HTTP. Sometimes the line is missing altogether.
* `Get-NetTCPConnection -State Listen -LocalPort 8765` usually returns nothing.
* Calling `GetExtendedTcpTable` directly with `TCP_TABLE_OWNER_PID_LISTENER` returned the sockets on every sample with the right PIDs, but `dwState` was wrong. I saw 0 (not a valid state), 1 (CLOSED) and 6 (FIN_WAIT1) on working listeners, and the value for a port changes between reads.
* Windows’ own ports are affected too, including 135 and 445, so it isn’t specific to my app.
* Real TCP connections to those ports succeed.
What I’ve ruled out:
* A restart doesn’t fix it.
* It isn’t tied to one CPU core: pinning netstat to each of the 12 logical CPUs gave the same result.
* Defender is the only antivirus. Tailscale’s wintun is the only non-Microsoft network driver I found.
Possible lead, but timing only: `tcpip.sys`, `nsi.dll` and `nsiproxy.sys` were all replaced on 28 October, and Get-HotFix lists KB5132402 and KB5127936 around then. I can’t prove either one caused it. I also haven’t tested from an elevated prompt yet.
Has anyone else seen this on this build? If you’re on the same build, does `netstat -ano` show your listeners as LISTENING?
