You're mid-download, mid-upload, or in the middle of an API call and the connection just dies. The error is WSAECONNABORTED (0x00002745), which is Winsock error 10053. What's actually happening here is that your own machine — not the remote server — closed the TCP connection. The stack sent a RST or FIN because something local told it to. So stop looking at the server logs. The problem is on your end.
Common triggers: an antivirus real-time scanner aborting an HTTP stream it doesn't like, a VPN client tearing down the interface mid-transfer, a firewall rule matching a process, or a misbehaving Winsock LSP. I've seen this most often when a backup tool is uploading to S3 and the corporate endpoint agent decides the TLS renegotiation looks suspicious.
Work the list in order. Stop when it's fixed.
Step 1: The 30-second fix — restart the network stack path
Before you go digging, rule out the dumb stuff. The cheapest thing that resolves WSAECONNABORTED in a lot of cases is a stale LSP or a hung socket owner.
- Close the app that threw the error. Fully — check Task Manager, not just the window.
- Toggle Wi-Fi off, wait 5 seconds, toggle it on. Or unplug/replug Ethernet.
- Reopen the app and try the exact same operation.
If it works now, something was holding a stale handle. Note what you were doing — if it recurs on the same operation, move to Step 2. If not, you probably just hit a one-off hiccup after a sleep/wake cycle, which is a known source of ghost aborts on Windows 10 and 11.
Step 2: The 5-minute fix — find what's aborting the connection
The error tells you the abort happened locally, so the question is which process. Windows will tell you if you ask.
Check the event log for Winsock or firewall entries
Open Event Viewer (eventvwr.msc) and look at:
- Windows Logs > System — filter by source Tcpip, AFD, or Windows Filtering Platform.
- Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational — Defender logs blocked connections here.
If you see an entry near the timestamp of your abort that names a process, that's your culprit. Nine times out of ten it's a third-party AV or an EDR agent.
Test with the firewall temporarily off
Don't leave it off. Just for the test:
netsh advfirewall set allprofiles state off
Re-run the failing operation. If it succeeds, turn the firewall back on immediately:
netsh advfirewall set allprofiles state on
Now you know it's a firewall rule. Skip to Step 3.
Reset Winsock and TCP/IP
If the logs are empty and the firewall isn't it, reset the stack. This clears LSP corruption, which is a classic cause of WSAECONNABORTED on older machines that have had several VPN clients installed over the years.
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
Reboot. The reason step 3 works is that netsh winsock reset rebuilds the catalog of layered service providers — third-party DLLs that hook Winsock calls. When one of those DLLs is half-uninstalled, it can abort connections unpredictably.
Step 3: The 15-minute fix — pin down the exact rule or app
You've narrowed it to firewall or AV. Now kill it properly instead of guessing.
Enable Windows Filtering Platform audit logs
Run this in an elevated Command Prompt to turn on WFP auditing, then reproduce the error:
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
Check Event Viewer > Security for event ID 5157 (blocked) or 5156 (allowed) entries matching your process name. The Filter Run-Time ID in the event maps to a rule — cross-reference it with:
netsh wfp show state
That dumps wfpstate.xml to your current directory. Search it for the filter ID. Now you have the exact rule that's aborting your connection.
Whitelist the app properly
Don't just click "allow" in the popup — popups create rules for the wrong profile half the time. Add an explicit rule:
netsh advfirewall firewall add rule name="Allow MyApp" dir=out action=allow program="C:\Path\To\MyApp.exe" enable=yes profile=any
If your AV is the aborter (Kaspersky, CrowdStrike, SentinelOne are frequent offenders), the fix isn't in Windows Firewall — you need to exclude the process or the destination host in the AV console. For Defender, it's Windows Security > Virus & threat protection > Manage settings > Exclusions.
Check for VPN interface interference
Some VPN clients (I'm looking at you, older Cisco AnyConnect and split-tunnel OpenVPN configs) install a virtual adapter that captures traffic and aborts connections when the route table changes mid-session. Test by fully disconnecting the VPN — not just toggling the kill switch — and re-running.
If the abort stops when the VPN is off, your fix is a route exception. Add a static route for the destination IP so it bypasses the tunnel:
route add 203.0.113.10 mask 255.255.255.255 192.168.1.1 metric 1
Replace the IPs with your actual destination and gateway. This tells Windows to send that traffic out the physical NIC instead of the VPN adapter.
When it's not a firewall at all
A few less common causes worth knowing:
| Cause | How to spot it | Fix |
|---|---|---|
| MTU mismatch | Fails on large transfers only, small requests work | Lower MTU: netsh int ipv4 set subinterface "Ethernet" mtu=1400 store=persistent |
| Windows Update proxy | Only BITS/WU traffic fails | net stop wuauserv then restart |
| Socket timeout in app code | Aborts at a fixed interval (30s, 60s) | Increase SO_RCVTIMEO or the app's timeout setting |
| IPv6 issues | Fails only when IPv6 is enabled | Disable IPv6 on the adapter temporarily to confirm |
The MTU one trips people up constantly. If you can ping a host with -l 1472 but not -l 1473, that's your problem: your packets are getting fragmented and dropped, and the stack aborts the connection instead of retrying cleanly.
If you're a developer seeing this in code
WSAECONNABORTED in your own socket code means the local stack aborted the connection — often because a send or receive completed with a timeout and something upstream called closesocket. Check your error handling. A common bug pattern is treating WSAETIMEDOUT as fatal and calling closesocket(), which then surfaces as WSAECONNABORTED on the next op. Log both errno and GetLastError at the point of failure, not just at the top of the call stack.
The connection wasn't reset by peer. It was reset by you. That distinction is the whole game with 0x00002745.
Work the steps in order. Most people get fixed at Step 2 with a Winsock reset. The stubborn cases are almost always an endpoint protection agent, and now you know how to prove it.