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

## 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->::
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 ` 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](https://github.com/user-attachments/files/32095552/AmneziaVPN-service.log)