0X00002745

WSAECONNABORTED 0x00002745: Connection Aborted by Host Fix

WSAECONNABORTED means your own machine killed the connection, not the server. Here's how to track down what's aborting it, from quick checks to deeper fixes.

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.

  1. Close the app that threw the error. Fully — check Task Manager, not just the window.
  2. Toggle Wi-Fi off, wait 5 seconds, toggle it on. Or unplug/replug Ethernet.
  3. 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:

CauseHow to spot itFix
MTU mismatchFails on large transfers only, small requests workLower MTU: netsh int ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
Windows Update proxyOnly BITS/WU traffic failsnet stop wuauserv then restart
Socket timeout in app codeAborts at a fixed interval (30s, 60s)Increase SO_RCVTIMEO or the app's timeout setting
IPv6 issuesFails only when IPv6 is enabledDisable 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.

Related Errors in Network & Connectivity
WiFi keeps disconnecting on Windows 11 and 10 DNS_PROBE_FINISHED_NXDOMAIN DNS_PROBE_FINISHED_NXDOMAIN fix that actually works 0XC00D2EED Fix NS_E_PROXY_NOT_FOUND 0XC00D2EED in Windows Media Player 0X400D0070 NS_I_LIMIT_BANDWIDTH (0x400D0070): Why Windows Media limits your stream

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.