SNMP Error: 10013 - An attempt was made to access a socket in a way forbidden by its access permissions

Products

• Automic Automation

Issue/Introduction

The Automic SNMP Subagent doesn't start when the server boots or when restarted. Every restart of the SNMP service fails immediately, and the subagent trace log (ucsnmp1_##.log) with snmp=9 and stream=9 set, records the following error before the agent exits:

20260729/091700.334 Create and open stream on port 7777.
20260729/091700.601 10013 - An attempt was made to access a socket in a way forbidden by its access permissions. libcpprnt/src/Socket.cpp#net::Socket::connect:29<
20260729/091700.601 Exiting agent. 

Windows error 10013 is WSAEACCES. Standard network-layer remediation — adding explicit Windows Firewall and Windows Service Hardening (WSH) allow rules for the SNMP service on TCP port 7777 (see KB 449691) — does not resolve this specific symptom, even though it is confirmed present, enabled, and correctly scoped.

Cause

The issue is cause by (a) specific version(s) of Symantec Endpoint Protection as explained hereafter:

The Automic SNMP Subagent runs inside the shared Windows SNMP service host process (snmp.exe). Symantec Endpoint Protection injects sysfer.dll — its Application Control / Network Threat Protection interception module — into every process launched on a protected host, including snmp.exe.

A Process Monitor (ProcMon) capture of a failing restart isolated the interference to this specific component. The capture shows sysfer.dll loading into snmp.exe before Winsock (ws2_32.dll) itself loads:

    Time              Process   PID   Operation    Path                                                              Result
    2:20:53.9054537PM snmp.exe  6820  Process Start                                                                  SUCCESS
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
>>> 2:20:53.9115693PM snmp.exe  6820  Load Image  C:\...\Symantec Endpoint Protection\14.3.7393.4000.105\
    Data\Sysfer\x64\sysfer.dll                                                                                       SUCCESS
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
    2:20:53.9147222PM snmp.exe  6820  Load Image  C:\Windows\System32\ws2_32.dll                                     SUCCESS
    ...
>>> 2:20:54.0654604PM snmp.exe  6820  Process Exit                Exit Status: 1

Two findings from this capture confirm sysfer.dll as the point of interference rather than a Windows Firewall/WSH/network-layer block:

1. sysfer.dll loads before ws2_32.dll, meaning its API hooks are already active before the subagent makes any Winsock call — it is positioned to intercept the socket call the instant it happens.
2. The entire capture contains zero TCP network events for the failed attempt (no TCP Connect, TCP Listen, or any related operation). If the block occurred at the Windows Firewall or Windows Service Hardening layer, ProcMon's network capture would still record the attempt (even a rejected one), since those layers act on packets after the socket call reaches the kernel network stack. The complete absence of any kernel-level network event shows the call was intercepted and denied at the Winsock API-hook layer — inside sysfer.dll — before it ever reached the network stack. The process exits (Exit Status: 1) less than 1.2 seconds after starting.

Confirmation via comparison host: an equivalent ProcMon capture was taken on a reference server with the identical Automic/OS configuration where the issue does not occur. sysfer.dll is injected into snmp.exe there as well:

9:44:48.0879995AM snmp.exe 11408 Load Image  C:\...\Symantec Endpoint Protection\14.3.11216.9000.105\
                                              Data\Sysfer\x64\sysfer.dll                              SUCCESS

However, the host process on that server never exits — it continues running for the full duration of the capture.

The only difference identified between the two hosts is the installed SEP client build: 14.3.7393.4000.105 (affected) vs. 14.3.11216.9000.105 (unaffected). This isolates the root cause to a version-specific behavior in SEP's Sysfer/Application Control hooking of snmp.exe, rather than a missing SEPM policy exception or a Windows-level firewall gap.

Diagnostic note: the deciding evidence in this case was the absence of network-layer events in the ProcMon capture combined with the Load Image ordering (Sysfer before Winsock), together with a side-by-side ProcMon comparison against a working host on a different SEP build. For similar cases where a process receives a synchronous local WSAEACCES on a socket call with no corresponding firewall/WFP log entry, capture and compare against a working reference host early — it is often faster than exhaustively ruling out each network-layer control individually.

Resolution

Upgrade the Symantec Endpoint Protection client to 14.3 RU9 (or later) and restart the server.

This was confirmed to resolve the issue in production: after upgrading the affected host's SEP client to 14.3 RU9, the Automic SNMP Subagent restarted and continued running normally, with no further 10013 (WSAEACCES) errors.

Additional Information

• If a SEPM Application Control exception for snmp.exe is preferred over an immediate client upgrade as an interim mitigation, see KB 181736 — Symantec Application Control sysfer.dll injection interferes with an application or program for the exception procedure. This was not required once the client was upgraded to 14.3 RU9, but may be useful as a temporary workaround on hosts pending upgrade.
• No change to Automic's SNMP Subagent configuration, Windows Firewall, or Windows Service Hardening rules was required once the SEP client was upgraded. The WSH/firewall exception described in KB 449691 remains valid and should still be in place — it addresses a separate, unrelated symptom (inbound TCP connections to an already-open subagent listener hanging without a response). It does not, however, resolve the crash/10013 symptom described in this article, since that block occurs at the Sysfer API-hook layer, before any packet is generated.