AdGuard for Windows 8.0.5570 with SockFilter network driver breaks AmneziaVPN (WireGuard/AmneziaWG) — WSAEFAULT on WSASendMsg / WSARecvMsg

[rudenko-ks]

Environment

AdGuard for Windows	8.0.5570.0 (installed 2026-09-10)
AdGuard driver pack	8.0.91.0 — nfsdk 1.7.6.7, wfp 1.7.2.3, sock 1.0.4.4
Active network driver	SockFilter (adgnetworksockdrv.sys, 8.0.91.0, System start)
OS	Windows 11 Enterprise, version 25H2 (build 10.0.26200), x86_64
Affected application	AmneziaVPN 5.0.1.5 (build 7d4f3e0f5), protocol AmneziaWG
Underlying stack	wireguard-go 0.3.15 + Wintun 0.14

Summary

With AdGuard running in SockFilter network driver mode, AmneziaVPN-service.exe (a LocalSystem
Windows service) cannot use the Winsock message-based socket API at all. Every relevant call fails
immediately with WSAEFAULT (10014, "The system detected an invalid pointer address in attempting
to use a pointer argument in a call").

The result is a tunnel that is created successfully but can never send or receive a single UDP packet,
so the WireGuard handshake never completes and the VPN stays stuck at "connecting" forever.

Steps to reproduce

1. Install AdGuard for Windows 8.0.5570 with the network driver set to SockFilter.
2. Install AmneziaVPN 5.0.1.5 and configure an AmneziaWG (or WireGuard) connection.
3. Try to connect.

Expected behaviour

The tunnel connects, as it does on a machine without AdGuard.

Actual behaviour

The tunnel never completes a handshake. AmneziaVPN-service.log shows three distinct Winsock
failures, all WSAEFAULT:

[07:51:16.904Z] [TUN] [AmneziaVPN] Registered I/O is unavailable:
    The system detected an invalid pointer address in attempting to use a pointer argument in a call.

[07:51:16.904Z] [TUN] [AmneziaVPN] Routine: receive incoming v6 - started
[07:51:16.904Z] [TUN] [AmneziaVPN] Failed to receive v6 packet: read udp6 [::]:54389:
    wsarecvmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call.
[07:51:16.904Z] [TUN] [AmneziaVPN] Routine: receive incoming v6 - stopped

[07:51:16.904Z] [TUN] [AmneziaVPN] Routine: receive incoming v4 - started
[07:51:16.904Z] [TUN] [AmneziaVPN] Failed to receive v4 packet: read udp4 0.0.0.0:54389:
    wsarecvmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call.
[07:51:16.904Z] [TUN] [AmneziaVPN] Routine: receive incoming v4 - stopped

[07:52:03.966Z] [TUN] [AmneziaVPN] peer(MILM…Y0hE) - Failed to send handshake initiation:
    write udp4 0.0.0.0:54389-><server-ip>:<port>:
    wsasendmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call.

Note that both receive routines stop immediately after the first failed call, so the tunnel is
dead from the moment it starts. The remaining two minutes of the log are just
Checking for handshake... / awaiting <peer key> until the user cancels.

Everything before the socket layer works correctly — the Wintun adapter is created, the interface is
configured and brought up, the peer is loaded, MTU is set:

[TUN] [AmneziaVPN] Creating Wintun interface
[TUN] [AmneziaVPN] Using existing driver 0.14
[TUN] [AmneziaVPN] Interface state was Down, requested Up, now Up
[TUN] [AmneziaVPN] Startup complete
[TUN] [AmneziaVPN] MTU updated: 1320

This is not network-level blocking: the packets never leave the machine, the WSASendMsg call itself
fails locally.

What does NOT work around the problem

• Turning off "Route traffic through AdGuard", "Filter traffic" and "Filter HTTPS" for both
  AmneziaVPN and AmneziaVPN Service in Settings → Apps.
• Adding both executables to exclusions:
  • C:\Program Files\AmneziaVPN\AmneziaVPN.exe
  • C:\Program Files\AmneziaVPN\AmneziaVPN-service.exe

What does work around the problem

• Fully disabling AdGuard protection. The tunnel then connects immediately and works normally.

The fact that per-application settings have no effect suggests the SockFilter driver intercepts
socket calls globally, below the layer where the per-app exclusion list is applied.

Analysis

WSAEFAULT from WSASendMsg, WSARecvMsg and from
WSAIoctl(SIO_GET_MULTIPLE_EXTENSION_FUNCTION_POINTER) (the "Registered I/O is unavailable" line)
is the signature of a socket-layer interceptor that does not correctly marshal the WSAMSG
structure and its control-message buffers, or that does not correctly return the pointers to the
Winsock extension functions.

wireguard-go relies on exactly these APIs on Windows:

• Registered I/O (RIO) extension function table via WSAIoctl, with a fallback to
• WSASendMsg / WSARecvMsg with IP_PKTINFO control data.

All three code paths fail under SockFilter, which is why there is no fallback left and the tunnel
is completely non-functional rather than merely degraded.

This affects any wireguard-go-based client on Windows, not just AmneziaVPN — the official WireGuard
for Windows client uses the same conn/bind_windows.go implementation.

Additional context: the machine has no third-party Winsock LSPs (the Winsock catalog contains only
Microsoft mswsock.dll providers) and AppInit_DLLs is empty, so the interception is coming from
the kernel-mode socket filter, not from a user-mode LSP.

Verification detail

The same WSARecvMsg call issued from an ordinary (non-service, interactive user) process while
AdGuard was running returned a normal WSAETIMEDOUT (10060) rather than WSAEFAULT. The failure
therefore appears to be specific to the LocalSystem service context, or to the particular
combination of extension-function usage that wireguard-go performs.

Request

Could the SockFilter driver be fixed to pass through WSASendMsg / WSARecvMsg and the extension
function pointer queries unchanged? Alternatively, could per-application exclusions be honoured at
the SockFilter layer so that excluding a VPN client actually bypasses interception?

Amnezia log file

AmneziaVPN-service.log

[rudenko-ks]

Update: confirmed workaround and a test that isolates the cause to the SockFilter driver alone

I switched the network driver from SockFilter to WFP and ran a series of tests to narrow down
what exactly is responsible. Nothing else in the environment was changed between the steps.

Test sequence

#	Configuration	Result
1	SockFilter + both executables added to exclusions	❌ no handshake
2	SockFilter + per-app filtering switched off for both executables	❌ no handshake
3	SockFilter + AdGuard protection fully disabled	✅ connects
4	WFP + both executables still in exclusions	✅ connects
5	WFP + exclusions removed	✅ connects
6	WFP + "Route traffic through AdGuard" and "Filter traffic" enabled for both AmneziaVPN.exe and AmneziaVPN-service.exe	✅ connects

Steps 1–3 are from the original report; 4–6 are new.

What this establishes

Step 6 is the important one. With the WFP driver active, AdGuard is explicitly filtering the VPN
client and its LocalSystem service — no exclusions, traffic routed through AdGuard, filtering on —
and the tunnel still establishes and works normally.

So this is not about filtering logic, about exclusion handling, or about VPN traffic being
filtered per se. AdGuard is perfectly capable of filtering this application without breaking it.
The defect is confined to the SockFilter driver (adgnetworksockdrv.sys, sock 1.0.4.4,
driver pack 8.0.91.0) and its handling of the Winsock message-based API.

This also means the decisive variable is which network driver is actually active on a given machine,
not the AdGuard application version — two machines on the same AdGuard build will behave differently
depending on whether they ended up on SockFilter or WFP.

Working workaround

Settings → change the network driver from SockFilter to WFP, then reboot.

For anyone hitting this with AmneziaVPN, WireGuard for Windows, or any other wireguard-go-based
client: you do not need to disable AdGuard protection and you do not need any exclusions — switching
the network driver is sufficient, and you keep full filtering.

Remaining request

Since WFP handles this application correctly and SockFilter does not, could the SockFilter driver be
fixed to pass WSASendMsg / WSARecvMsg and the Winsock extension-function pointer queries
(WSAIoctl / Registered I/O) through unchanged?

Until that is fixed, it would also help a lot if installations that migrate to SockFilter either
detected this failure mode and fell back to WFP, or at least documented the switch — the breakage is
silent, and from the user's side it looks like the VPN client is at fault rather than the filtering
driver.