Windows XP SP2 TCP Connection Limit Impact
When Microsoft released Windows XP Service Pack 2 (SP2) in 2004, it introduced a strict throttling mechanism on concurrent incomplete outbound TCP connections, commonly referred to as half-open connections. While intended as a security measure to curb the rapid propagation of network worms and malware, this change created widespread performance bottlenecks for legitimate applications, particularly peer-to-peer (P2P) file sharing and network scanning tools.
The Half-Open Connection Throttle
Under Windows XP SP2, the core network driver
(tcpip.sys) was altered to enforce a limit of 10 concurrent
half-open outbound connections. A half-open connection occurs when a
system transmits a TCP SYN packet to establish a handshake
but has not yet received a SYN-ACK from the target host or
sent the final ACK.
When an application initiated more than 10 simultaneous incomplete outbound connections, the operating system placed subsequent attempts into a queue, processing them at a rate of roughly 10 per second. If the queue filled up, connection attempts were dropped, and the operating system logged a warning in the System Event Log under Event ID 4226: "TCP/IP has reached the security limit imposed on the number of concurrent TCP connect attempts."
Why the Limit Was Implemented
The primary objective of this restriction was malware containment. In the early 2000s, mass-mailing worms and automated network scanners like Blaster and Sasser caused global outages by rapidly generating thousands of outbound TCP requests per second to scan random IP addresses for vulnerabilities. By capping half-open connection attempts to 10, Microsoft severely degraded the ability of infected machines to scan the internet quickly, effectively dampening the speed at which network worms could spread from an unpatched host.
Collateral Impact on Legitimate Software
The limit did not restrict established connections or standard web browsing, but it drastically hindered software that required high-frequency address discovery:
- Peer-to-Peer (P2P) Clients: Applications like BitTorrent, eMule, and Gnutella constantly probed dozens or hundreds of remote peers to verify availability. With the SP2 cap, these clients experienced severe connection queues, causing transfer speeds to drop and user interfaces to report connection timeouts.
- Network Scanners and Admin Tools: Administrative utilities like Nmap and internal port scanners were throttled, significantly extending the time required to complete network audits.
- Online Gaming: Multiplayer game server browsers that pinged hundreds of game servers simultaneously to display latency took substantially longer to refresh server lists.
- DNS Resolution Delays: Under heavy network activity, the queue could cause regular DNS lookups to stall, leading users to believe their entire internet connection had dropped.
Workarounds and Ultimate Deprecation
Because Microsoft provided no native registry key or interface toggle
to adjust the limit, power users and developers turned to unofficial
binary modifications. Third-party tools, most notably the widely
distributed EvID4226Patch, modified tcpip.sys in memory or
on disk to increase the threshold from 10 to 50, 100, or unlimited.
Recognizing that network environments and software architectures had evolved—and that alternative security layers like host firewalls were more effective—Microsoft eventually rolled back this policy. The connection limit was officially removed in Windows Vista Service Pack 2 and was not included in Windows 7 or subsequent Windows releases.