Error 0x80072746: endpoint security resets SMB, print and RDP connections

Fix it now

0x80072746 is Winsock error 10054, WSAECONNRESET: an existing connection was forcibly closed by the remote host. Inside your own network the remote host is rarely the culprit – something on one of the two machines is tearing down a session that was already established. A reset, a refusal and a timeout have three different fixes, so establish which you have before changing any policy.

Test-NetConnection SERVERNAME -Port 445
Get-NetConnectionProfile
netsh advfirewall set allprofiles logging droppedconnections enable

1. Note the port that fails. SMB is TCP 445, Remote Desktop is TCP 3389, and print and management traffic use RPC on TCP 135 plus a dynamic high port you can read with netsh int ipv4 show dynamicport tcp.
2. If Test-NetConnection succeeds and the application still resets mid-transfer, the path is open and something is closing an established session. That rules out a blocked port and rules in a filter.
3. Pause the endpoint product’s network or firewall module on the client, retry the operation, then re-enable it immediately. If it works while paused, you have your answer without having changed anything permanently.
4. Write the exclusion into the management console – the affected ports and server addresses on the trusted or excluded list – rather than leaving protection off. Push the policy, confirm the client received it, and retest with protection fully enabled.

Read %windir%\system32\logfiles\firewall\pfirewall.log after enabling logging. If Windows Firewall is dropping the traffic, it will be in there, and you can stop investigating the security suite.

If the operation completes with protection fully on, you are done. If pausing protection changed nothing, the next section explains which layer you are actually in.

Why it happens

These five codes mark distinct moments in a TCP conversation, and knowing which one you have removes most of the guesswork. A reset – 0x80072746, WSAECONNRESET – means the connection existed and was torn down. Microsoft’s description is precise: the connection was forcibly closed by the remote host, typically because the peer application stopped, the host was rebooted, the interface was disabled, or the remote end used a hard close. A refusal – 0x8007274D, WSAECONNREFUSED – means nothing was listening when the first packet arrived. A timeout – 0x8007274C, WSAETIMEDOUT – means packets went out and nothing came back, which is the signature of a silent drop rather than an active rejection.

Endpoint protection sits in this path twice. It binds a filter to the adapter, so it sees frames before the TCP stack does, and it registers filters in the Windows Filtering Platform, so it can act on flows that are already established. An inspection module that does not recognise a particular SMB dialect or an RPC callback will often abort the flow rather than pass it, and aborting an established connection is exactly what produces a reset at the application.

That is also why the fault looks intermittent and unfair. Large file copies fail while small ones succeed, because the reset arrives when an inspection buffer fills. Remote Desktop drops after several minutes rather than refusing to connect, because the session is reset rather than blocked. And the fifth code is the one people misread: 0x80072745 is WSAECONNABORTED, which Microsoft describes as an established connection aborted by the software in your host computer. If you are seeing the abort rather than the reset, stop investigating the server – the software doing it is on the machine in front of you.

Full reference

Matching the code to the moment

Seeing the drop instead of inferring it

Guessing which layer dropped a session wastes more time on this error than anything else, and Windows will tell you if you ask. Two mechanisms are documented and neither needs a third-party tool.

1. Turn the firewall’s own log on with netsh advfirewall set allprofiles logging droppedconnections enable and read %windir%\system32\logfiles\firewall\pfirewall.log. Anything Windows Firewall drops appears there with the source, destination and port.
2. Enable the Audit Filtering Platform Connection subcategory and read the Security log. Event 5157 is logged when the Windows Filtering Platform has blocked a connection, and it names the process, the addresses and the ports.
3. Reproduce the failure while both are on, then compare timestamps against the endpoint agent’s own log. If neither Windows mechanism recorded anything and the agent did, the agent is the one closing the session.

Which ports the affected protocols actually use

That last row matters when someone opens 135 and expects printing to work. The endpoint mapper hands the client a second port from the dynamic range, and a firewall that permits 135 while blocking the range produces a connection that establishes and then dies – which is this error exactly. Read the range on the servers involved and allow it between trusted internal subnets, or configure the services concerned to use a fixed port.

When pausing protection changes nothing

• Test from a third machine with no endpoint product installed at all. If it fails there too, the fault is on the server or in the network and no exclusion will help.
• Check for a duplicate IP address on the segment. Two devices answering for one address produce resets that look precisely like inspection.
• Check for an intermediate device doing inspection – a firewall, a proxy, an SD-WAN appliance. Endpoint software is not the only thing that terminates and rebuilds sessions.
• Check MTU and offload settings where the resets cluster around large transfers. A path MTU problem produces size-dependent failures that resemble buffer-driven resets.
• On a virtual machine, check the host’s virtual switch and any security extensions bound to it.

Every code this article covers

Confirm the fix worked

1. Repeat the operation that failed with endpoint protection fully enabled, and confirm it completes.
2. Copy a large file rather than a small one, since buffer-driven resets only show up at size.
3. Leave a Remote Desktop session open for longer than the interval at which it previously dropped.
4. Check the firewall log and the Security log for the same window and confirm no new dropped-connection or 5157 entries were written.
5. Confirm the exclusion is in the management policy rather than on the machine, then check a second client has received it.

Questions people ask about this