amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-15 13:52:15 +00:00

[GH-ISSUE #3048] [Windows][Regression] AmneziaWG 2.0 fails to connect on 5.0.1.5: wsasendmsg/wsarecvmsg invalid pointer error #1404

New issue

Open

opened 2026-10-13 20:41:47 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-13 20:41:47 +00:00

Owner

Originally created by @rudenko-ks on GitHub (Aug 25, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3048

Describe the bug

После обновления клиента AmneziaVPN на Windows с 4.8.21.0 до 5.0.1.5 ни одно из ранее рабочих подключений (self-hosted AmneziaWG, сервер на протоколе AmneziaWG 2.0) больше не устанавливается: приложение зависает в статусе «Подключение…» и само разрывает соединение примерно через 28 секунд. Откат на 4.8.21.0 на том же ПК с тем же конфигом сразу восстанавливает работу.

To Reproduce

Настроить AmneziaWG-подключение к self-hosted серверу, работающему на AmneziaWG 2.0 (в конфиге заданы H1–H4 и HeaderProtectionKey)
Обновить клиент до 5.0.1.5
Нажать «Подключиться»

Expected behavior

Handshake завершается за 1–2 секунды, как в 4.8.21.0.

Desktop

OS: Windows 11, Version 25H2 (x86_64)
Клиент (не работает): AmneziaVPN 5.0.1.5, сборка 7d4f3e0f5
Клиент (работает): AmneziaVPN 4.8.21.0, сборка 72ee32af1
tunnel.dll: WireGuard/0.3.15, Wintun/0.14 — одинаковы в обеих версиях
Протокол: AmneziaWG, сервер self-hosted на AmneziaWG 2.0

Log files

Прикладываю оба лог-файла целиком (клиентский AmneziaVPN.log и сервисный AmneziaVPN-service.log) для рабочего (v4.8.21.0) и нерабочего (v5.0.1.5) подключений — по ним видна полная последовательность.

Ключевой фрагмент service-лога 5.0.1.5, сразу после поднятия интерфейса:

[TUN] [AmneziaVPN] Failed to receive v4 packet: read udp4 0.0.0.0:51618: wsarecvmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call.
[TUN] [AmneziaVPN] Routine: receive incoming v4 - stopped
[TUN] [AmneziaVPN] Failed to receive v6 packet: read udp6 [::]:51618: wsarecvmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call.
[TUN] [AmneziaVPN] Routine: receive incoming v6 - stopped

Оба recv-воркера (v4 и v6) падают сразу после старта. Далее каждая попытка отправить handshake initiation проваливается той же ошибкой (повторяется каждые ~5 сек: retry 2, 3, 4, 5…):

[TUN] [AmneziaVPN] peer(Oc56…D1gg) - Failed to send handshake initiation: write udp4 0.0.0.0:51618-><VPN_SERVER_IP>:443: wsasendmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call.

В логе 4.8.21.0 recv v4/v6-воркеры стартуют и остаются активными без единой ошибки, handshake завершается за ~150 мс.

Additional context

Сравнил оба service-лога построчно. Строка Registered I/O is unavailable: ...invalid pointer address... присутствует в обеих версиях идентично и, судя по всему, не является проблемой сама по себе — это ожидаемый триггер fallback'а на обычные (не-RIO) сокеты. Единственное структурное отличие в последовательности поднятия интерфейса — 4 новых вызова UAPI в 5.0.1.5, которых нет в 4.8.21.0:

UAPI: Updating h1 padding
UAPI: Updating h2 padding
UAPI: Updating h3 padding
UAPI: Updating h4 padding
...
UAPI: Updating header protection key

Это параметры Header Protection из AmneziaWG 2.0 (ranged-заголовки H1–H4 + ChaCha20 HeaderProtectionKey). Все остальные шаги (воркеры, правила firewall, маршруты, тот самый RIO-фолбэк) идентичны в обеих версиях и после фолбэка ни разу не ошибаются в 4.8.21.0.

Судя по блог-посту о 5.0.1.5, клиент перешёл на движок AmneziaWG 3.1, а self-hosted-серверы на AmneziaWG 2.0 (как в моём случае) поддерживаются как legacy через загруженный конфиг. Похоже, что именно код, который в Windows-реализации tunnel.dll собирает буфер/указатель для WSARecvMsg/WSASendMsg при активных H1–H4/HeaderProtectionKey, формирует некорректный указатель — из-за этого рвётся и приём, и отправка UDP одновременно, и handshake физически не может уйти на сервер. В 4.8.21.0 этого кода пути ещё нет, поэтому там всё работает.

AmneziaVPN.log

AmneziaVPN-service.log

Originally created by @rudenko-ks on GitHub (Aug 25, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3048 ## Describe the bug После обновления клиента AmneziaVPN на Windows с **4.8.21.0** до **5.0.1.5** ни одно из ранее рабочих подключений (self-hosted AmneziaWG, сервер на протоколе **AmneziaWG 2.0**) больше не устанавливается: приложение зависает в статусе «Подключение…» и само разрывает соединение примерно через 28 секунд. Откат на 4.8.21.0 на том же ПК с тем же конфигом сразу восстанавливает работу. ## To Reproduce 1. Настроить AmneziaWG-подключение к self-hosted серверу, работающему на AmneziaWG 2.0 (в конфиге заданы `H1`–`H4` и `HeaderProtectionKey`) 2. Обновить клиент до 5.0.1.5 3. Нажать «Подключиться» ## Expected behavior Handshake завершается за 1–2 секунды, как в 4.8.21.0. ## Desktop - OS: Windows 11, Version 25H2 (x86_64) - Клиент (не работает): AmneziaVPN 5.0.1.5, сборка `7d4f3e0f5` - Клиент (работает): AmneziaVPN 4.8.21.0, сборка `72ee32af1` - tunnel.dll: `WireGuard/0.3.15`, `Wintun/0.14` — одинаковы в обеих версиях - Протокол: AmneziaWG, сервер self-hosted на AmneziaWG 2.0 ## Log files Прикладываю оба лог-файла целиком (клиентский `AmneziaVPN.log` и сервисный `AmneziaVPN-service.log`) для рабочего (v4.8.21.0) и нерабочего (v5.0.1.5) подключений — по ним видна полная последовательность. Ключевой фрагмент service-лога 5.0.1.5, сразу после поднятия интерфейса: ``` [TUN] [AmneziaVPN] Failed to receive v4 packet: read udp4 0.0.0.0:51618: wsarecvmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call. [TUN] [AmneziaVPN] Routine: receive incoming v4 - stopped [TUN] [AmneziaVPN] Failed to receive v6 packet: read udp6 [::]:51618: wsarecvmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call. [TUN] [AmneziaVPN] Routine: receive incoming v6 - stopped ``` Оба recv-воркера (v4 и v6) падают сразу после старта. Далее каждая попытка отправить handshake initiation проваливается той же ошибкой (повторяется каждые ~5 сек: retry 2, 3, 4, 5…): ``` [TUN] [AmneziaVPN] peer(Oc56…D1gg) - Failed to send handshake initiation: write udp4 0.0.0.0:51618-><VPN_SERVER_IP>:443: wsasendmsg: The system detected an invalid pointer address in attempting to use a pointer argument in a call. ``` В логе 4.8.21.0 recv v4/v6-воркеры стартуют и остаются активными без единой ошибки, handshake завершается за ~150 мс. ## Additional context Сравнил оба service-лога построчно. Строка `Registered I/O is unavailable: ...invalid pointer address...` присутствует в обеих версиях идентично и, судя по всему, не является проблемой сама по себе — это ожидаемый триггер fallback'а на обычные (не-RIO) сокеты. Единственное **структурное** отличие в последовательности поднятия интерфейса — 4 новых вызова UAPI в 5.0.1.5, которых нет в 4.8.21.0: ``` UAPI: Updating h1 padding UAPI: Updating h2 padding UAPI: Updating h3 padding UAPI: Updating h4 padding ... UAPI: Updating header protection key ``` Это параметры Header Protection из AmneziaWG 2.0 (ranged-заголовки H1–H4 + ChaCha20 HeaderProtectionKey). Все остальные шаги (воркеры, правила firewall, маршруты, тот самый RIO-фолбэк) идентичны в обеих версиях и после фолбэка ни разу не ошибаются в 4.8.21.0. Судя по блог-посту о 5.0.1.5, клиент перешёл на движок AmneziaWG 3.1, а self-hosted-серверы на AmneziaWG 2.0 (как в моём случае) поддерживаются как legacy через загруженный конфиг. Похоже, что именно код, который в Windows-реализации tunnel.dll собирает буфер/указатель для `WSARecvMsg`/`WSASendMsg` при активных `H1`–`H4`/`HeaderProtectionKey`, формирует некорректный указатель — из-за этого рвётся и приём, и отправка UDP одновременно, и handshake физически не может уйти на сервер. В 4.8.21.0 этого кода пути ещё нет, поэтому там всё работает. [AmneziaVPN.log](https://github.com/user-attachments/files/31423913/AmneziaVPN.log) [AmneziaVPN-service.log](https://github.com/user-attachments/files/31423954/AmneziaVPN-service.log)

bsakaguchi commented

2026-10-13 20:41:49 +00:00

Author

Owner

@rudenko-ks commented on GitHub (Sep 11, 2026):

Trigger identified: AdGuard's SockFilter network driver — but 4.8.21.0 survives it and 5.0.1.5 does not

I have found what triggers this, and I can now reproduce it on demand in both directions. The short
version: an external socket-level filtering driver breaks the Winsock calls, but only 5.0.1.5 is
affected — 4.8.21.0 keeps working under exactly the same driver. So there is still something on the
AmneziaVPN side worth looking at.

The external trigger

AdGuard for Windows can filter through one of several network drivers. Since driver pack 8.0.80.0
it ships a socket-level one, SockFilter (adgnetworksockdrv.sys), which intercepts Winsock calls
in user mode. With it active, every message-based socket call from the AmneziaVPN service fails with
WSAEFAULT (10014):

WSAIoctl(SIO_GET_MULTIPLE_EXTENSION_FUNCTION_POINTER) for Registered I/O
→ Registered I/O is unavailable: The system detected an invalid pointer address...
WSARecvMsg → both receive incoming v4 and receive incoming v6 fail on the first call and
the routines stop immediately, so the tunnel can never receive anything
WSASendMsg → Failed to send handshake initiation

Everything before the socket layer is fine — the Wintun adapter is created, the interface goes up,
UAPI configuration succeeds, the peer is loaded. Then nothing moves in either direction, and the UI
sits at "connecting" until it times out.

Test matrix

Same machine, one variable changed at a time:

#	AdGuard network driver	AmneziaVPN	AdGuard config	Result
1	SockFilter	5.0.1.5	both executables in exclusions	❌
2	SockFilter	5.0.1.5	per-app filtering disabled for both	❌
3	SockFilter	5.0.1.5	protection fully disabled	✅
4	SockFilter	4.8.21.0	default (filtering on)	✅
5	WFP	5.0.1.5	both executables in exclusions	✅
6	WFP	5.0.1.5	exclusions removed	✅
7	WFP	5.0.1.5	"Route traffic through AdGuard" + "Filter traffic" enabled for both	✅

Two independent conclusions fall out of this:

Row 7 — with the WFP driver, AdGuard actively filters both the client and its LocalSystem service,
no exclusions at all, and 5.0.1.5 connects and works normally. So this is not about VPN traffic being
filtered; it is specific to the SockFilter driver. I have reported that side to AdGuard separately.

Row 4 — and this is the part that concerns this repository: under the same SockFilter driver,
4.8.21.0 connects and works. Whatever 4.8.21.0 does at the socket layer, SockFilter handles it;
whatever 5.0.1.5 does, it does not. This is reproducible — I can switch between the two states
deliberately.

Where I think the difference is — and how to confirm it

I no longer think my original header-protection theory is the right lead. Those UAPI calls
(Updating h1..h4 padding, Updating header protection key) all complete successfully, and the
failures happen afterwards, at socket setup, before a single packet is sent. The receive routines
die on their very first call.

A more promising lead is the line that appears at the top of every failing log:

[TUN] [AmneziaVPN] Registered I/O is unavailable: The system detected an invalid pointer address...

5.0.1.5 probes for the Registered I/O extension and then uses the WSASendMsg / WSARecvMsg path.
If 4.8.21.0 uses a plainer socket API (no RIO probe, no message-based calls), that alone would
explain why the interception layer breaks one and not the other.

Two things would settle it quickly, and I am happy to provide both:

The service log from 4.8.21.0 with SockFilter active. If it contains no
Registered I/O is unavailable line and no wsarecvmsg errors, the two builds are demonstrably
using different socket paths. Say the word and I will capture it.
A hash comparison of tunnel.dll between the two installs. I said earlier that the versions
look identical — but tunnel.dll carries no version resource at all in either build, so "identical
version" only means "both show nothing". Comparing SHA-256 would actually answer whether the
bundled amneziawg-go differs.

Workaround for anyone hitting this now

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

You do not need to disable AdGuard and you do not need exclusions — filtering keeps working fully.
Staying on 4.8.21.0 also works, but the driver switch lets you stay on 5.0.1.5.

To check which driver is active:

dir C:\Windows\System32\drivers\adgnetwork*.sys

adgnetworksockdrv.sys = affected, adgnetworkwfpdrv.sys = fine. Note that the switch to SockFilter
happens silently during an AdGuard upgrade, so this can hit users who changed nothing themselves.

Other socket-level interceptors (Proxifier, NetFilterSDK-based tools, some endpoint security agents)
can produce the identical WSAEFAULT signature, so AdGuard is an example rather than the only
possible trigger.

One usability point regardless of whose bug it is

The receive routines die on the first call and the failure is only visible in the service log; the UI
just spins. If the Windows backend detected WSAEFAULT from the bind/receive path and surfaced
something like "the socket API is being intercepted by another program — check for a filtering or
proxy driver", it would have saved me a day of digging and would likely cut down similar reports
here — especially since 4.8.21.0 keeps working, which makes it look like a plain AmneziaVPN
regression to the user.

@rudenko-ks commented on GitHub (Sep 11, 2026): ## Trigger identified: AdGuard's SockFilter network driver — but 4.8.21.0 survives it and 5.0.1.5 does not I have found what triggers this, and I can now reproduce it on demand in both directions. The short version: an external socket-level filtering driver breaks the Winsock calls, **but only 5.0.1.5 is affected — 4.8.21.0 keeps working under exactly the same driver.** So there is still something on the AmneziaVPN side worth looking at. ### The external trigger AdGuard for Windows can filter through one of several network drivers. Since driver pack `8.0.80.0` it ships a socket-level one, **SockFilter** (`adgnetworksockdrv.sys`), which intercepts Winsock calls in user mode. With it active, every message-based socket call from the AmneziaVPN service fails with **`WSAEFAULT` (10014)**: - `WSAIoctl(SIO_GET_MULTIPLE_EXTENSION_FUNCTION_POINTER)` for Registered I/O → `Registered I/O is unavailable: The system detected an invalid pointer address...` - `WSARecvMsg` → both `receive incoming v4` and `receive incoming v6` fail on the **first** call and the routines **stop immediately**, so the tunnel can never receive anything - `WSASendMsg` → `Failed to send handshake initiation` Everything before the socket layer is fine — the Wintun adapter is created, the interface goes up, UAPI configuration succeeds, the peer is loaded. Then nothing moves in either direction, and the UI sits at "connecting" until it times out. ### Test matrix Same machine, one variable changed at a time: | # | AdGuard network driver | AmneziaVPN | AdGuard config | Result | |---|---|---|---|---| | 1 | SockFilter | 5.0.1.5 | both executables in exclusions | ❌ | | 2 | SockFilter | 5.0.1.5 | per-app filtering disabled for both | ❌ | | 3 | SockFilter | 5.0.1.5 | protection fully disabled | ✅ | | 4 | **SockFilter** | **4.8.21.0** | default (filtering on) | ✅ | | 5 | WFP | 5.0.1.5 | both executables in exclusions | ✅ | | 6 | WFP | 5.0.1.5 | exclusions removed | ✅ | | 7 | WFP | 5.0.1.5 | "Route traffic through AdGuard" + "Filter traffic" **enabled** for both | ✅ | Two independent conclusions fall out of this: **Row 7** — with the WFP driver, AdGuard actively filters both the client and its LocalSystem service, no exclusions at all, and 5.0.1.5 connects and works normally. So this is not about VPN traffic being filtered; it is specific to the SockFilter driver. I have reported that side to AdGuard separately. **Row 4** — and this is the part that concerns this repository: under the *same* SockFilter driver, **4.8.21.0 connects and works**. Whatever 4.8.21.0 does at the socket layer, SockFilter handles it; whatever 5.0.1.5 does, it does not. This is reproducible — I can switch between the two states deliberately. ### Where I think the difference is — and how to confirm it I no longer think my original header-protection theory is the right lead. Those UAPI calls (`Updating h1..h4 padding`, `Updating header protection key`) all complete successfully, and the failures happen afterwards, at socket setup, **before a single packet is sent**. The receive routines die on their very first call. A more promising lead is the line that appears at the top of every failing log: ``` [TUN] [AmneziaVPN] Registered I/O is unavailable: The system detected an invalid pointer address... ``` 5.0.1.5 probes for the Registered I/O extension and then uses the `WSASendMsg` / `WSARecvMsg` path. If 4.8.21.0 uses a plainer socket API (no RIO probe, no message-based calls), that alone would explain why the interception layer breaks one and not the other. Two things would settle it quickly, and I am happy to provide both: 1. **The service log from 4.8.21.0 with SockFilter active.** If it contains no `Registered I/O is unavailable` line and no `wsarecvmsg` errors, the two builds are demonstrably using different socket paths. Say the word and I will capture it. 2. **A hash comparison of `tunnel.dll` between the two installs.** I said earlier that the versions look identical — but `tunnel.dll` carries no version resource at all in either build, so "identical version" only means "both show nothing". Comparing SHA-256 would actually answer whether the bundled amneziawg-go differs. ### Workaround for anyone hitting this now **AdGuard → Settings → switch the network driver from SockFilter to WFP, then reboot.** You do not need to disable AdGuard and you do not need exclusions — filtering keeps working fully. Staying on 4.8.21.0 also works, but the driver switch lets you stay on 5.0.1.5. To check which driver is active: ``` dir C:\Windows\System32\drivers\adgnetwork*.sys ``` `adgnetworksockdrv.sys` = affected, `adgnetworkwfpdrv.sys` = fine. Note that the switch to SockFilter happens silently during an AdGuard upgrade, so this can hit users who changed nothing themselves. Other socket-level interceptors (Proxifier, NetFilterSDK-based tools, some endpoint security agents) can produce the identical `WSAEFAULT` signature, so AdGuard is an example rather than the only possible trigger. ### One usability point regardless of whose bug it is The receive routines die on the first call and the failure is only visible in the service log; the UI just spins. If the Windows backend detected `WSAEFAULT` from the bind/receive path and surfaced something like "the socket API is being intercepted by another program — check for a filtering or proxy driver", it would have saved me a day of digging and would likely cut down similar reports here — especially since 4.8.21.0 keeps working, which makes it look like a plain AmneziaVPN regression to the user.

No labels

pull-request

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

amnezia-vpn/amnezia-client#1404

No description provided.

Rows
Columns