Hi,
I am investigating recurring Windows 11 TCP/IP System events 4231/4266 and have managed to capture the issue at ETW level several times.
So far I have 7 natural occurrences captured in detail. The failures were triggered by different requesters/processes, including Chrome, ChatGPT, Discord and svchost/NetworkService, and I have observed both TCP and UDP cases.
This does not look like classic ephemeral-port exhaustion.
Visible port occupancy, TIME_WAIT and ephemeral-port usage were low during the captures. User-mode reproduction attempts with thousands of wildcard/Port0 binds, including SO_RANDOMIZE_PORT-oriented tests, did not reproduce the failure.
The recurring low-level pattern is:
socket creation succeeds
-> socket options succeed
-> wildcard / Port0 bind begins
-> Microsoft-Windows-TCPIP / TcpGlobalPortReservation
ReservationType = 16
StartPort = 0
NumberOfPorts = 1
Protocol = UDP 17 or TCP 6
Status = 0xC000000D (STATUS_INVALID_PARAMETER)
-> bind failure propagates as 0xC0000209 (STATUS_TOO_MANY_ADDRESSES)
-> shortly afterwards automatic port allocation succeeds again
The latest capture was:
Windows 11 Pro
Build 26200
Event 4266
RecordId 402098
Requester: Chrome NetworkService
PID 19304
UDP / IPv6 wildcard Port0
Relevant ETW timeline:
T+0.068 ms
Microsoft-Windows-Winsock-Sockets
SockCreate Start
PID 19304
T+0.090 ms
Microsoft-Windows-Winsock-AFD
AfdCreate Enter
UDP / IPv6 socket
Status 0
T+0.132 ms
Winsock SockSetOpt
Status 0
T+0.139 ms
Winsock SockSetOpt
Status 0
T+0.145 ms
Microsoft-Windows-Winsock-AFD
AfdBindWithAddress Enter
Address ::
Status 0
T+0.160 ms
Microsoft-Windows-TCPIP
TcpGlobalPortReservation
ReservationType = 16
IPTransportProtocol = 17
StartPort = 0
NumberOfPorts = 1
Status = 0xC000000D
T+0.167 ms
Microsoft-Windows-TCPIP
UdpBindEndpointPortFailure
Status = 0xC0000209
T+0.169 ms
Microsoft-Windows-Winsock-AFD
AfdBind Exit
Status = 0xC0000209
T+0.173 ms
Winsock failure returned to the caller
T+0.196 ms
failed socket closed
T+0.346 ms
new socket creation begins
T+0.409 ms
new AfdBindWithAddress(:
begins
T+0.452 ms
AfdBindWithAddress succeeds with [::]:60546
So there are only about 15 microseconds between the successful AFD bind entry and the first TCPIP failure, and roughly 0.3 ms later automatic allocation succeeds again.
I also captured a broad WPR/ETW trace containing:
- Winsock-AFD
- Winsock-Sockets
- TCPIP
- WFP
- NDIS
- Hyper-V VmSwitch
- VFP
- HNS
- WinNAT
The saved trace reported 0 lost buffers and 0 lost events.
I could not identify a corresponding failure immediately before the TCPIP event in HNS, VFP, WinNAT, WFP, NDIS or VmSwitch.
There was normal WSL/Hyper-V network activity shortly before the failure, but it completed successfully and did not share the failing Chrome socket/endpoint/resource.
The first visible actual failure therefore remains TcpGlobalPortReservation returning STATUS_INVALID_PARAMETER.
Environment, for context only (none of these are proven as the cause):
Windows 11 Pro build 26200
Hyper-V enabled
Virtual Machine Platform enabled
WSL
HNS / vmcompute / WinNAT
VirtualBox
Kaspersky
Kaspersky VPN
Tailscale
Realtek Gaming 2.5GbE
My main questions are:
-
Does anyone know what internal validation condition can cause TcpGlobalPortReservation with ReservationType=16, StartPort=0 and NumberOfPorts=1 to transiently return STATUS_INVALID_PARAMETER?
-
Has anyone seen this exact pattern before without actual ephemeral-port exhaustion?
-
Is there a useful WinDbg / kernel-debugging approach to catch the internal state at the moment this happens?
-
Would a stack trace on the AFD/TCPIP events realistically provide more useful information, or would public symbols only show the call route without the internal state that caused STATUS_INVALID_PARAMETER?
-
Are there any known interactions with Hyper-V/WSL or third-party network filter drivers that could cause this kind of transient port-reservation failure?
I have the full ETW/WPR trace, the exact failure branch, event XML, metadata and raw socket/AFD/TCPIP event data available.
I am not claiming this is necessarily a Windows bug. I am mainly trying to determine whether this can be debugged further from outside Microsoft, and what the most useful next diagnostic step would be.
Thanks.