RDP unusable on Windows: crashes on connect, then fails to resolve any host #13

New Issue

2026-09-08T09:38:59-06:00

Agent commented

2026-09-08 09:38:59 -06:00

RDP was completely broken on Windows -- every connection attempt failed, in two successive ways once each was fixed. Root cause for both: OrbitHub never replicated the startup initialization that every reference FreeRDP client performs (wfreerdp_client_global_init() in FreeRDP's own client/Windows/wf_client.c, and equivalents in the X11/macOS/SDL/Wayland/Android clients).

Crash on connect (commit 317df68): freerdp_connect() calls freerdp_add_signal_cleanup_handler() internally, which uses a global CRITICAL_SECTION that is only initialized inside freerdp_handle_signals(). Every reference client calls that once at startup; OrbitHub didn't, so the lock stayed zero-initialized -- invalid on Windows, silently tolerated on POSIX, which is why this never surfaced in Linux testing. Result: access violation (null-pointer deref inside EnterCriticalSection) on every RDP connect attempt.
ERRCONNECT_DNS_NAME_NOT_FOUND on every host, including literal IPs (commit b28adf8): Winsock requires WSAStartup() to be called once by the process before any socket/getaddrinfo call works. OrbitHub doesn't use Qt Network, so nothing was ever calling it. WinPR provides a portable no-op WSAStartup shim on POSIX, so the fix (calling it alongside freerdp_handle_signals(), matching wf_client.c's exact pairing) is safe to run unconditionally cross-platform.

Both fixed and confirmed: RDP now connects and works correctly on Windows.

RDP was completely broken on Windows -- every connection attempt failed, in two successive ways once each was fixed. Root cause for both: OrbitHub never replicated the startup initialization that every reference FreeRDP client performs (`wfreerdp_client_global_init()` in FreeRDP's own `client/Windows/wf_client.c`, and equivalents in the X11/macOS/SDL/Wayland/Android clients). 1. **Crash on connect** (commit 317df68): `freerdp_connect()` calls `freerdp_add_signal_cleanup_handler()` internally, which uses a global `CRITICAL_SECTION` that is only initialized inside `freerdp_handle_signals()`. Every reference client calls that once at startup; OrbitHub didn't, so the lock stayed zero-initialized -- invalid on Windows, silently tolerated on POSIX, which is why this never surfaced in Linux testing. Result: access violation (null-pointer deref inside `EnterCriticalSection`) on every RDP connect attempt. 2. **`ERRCONNECT_DNS_NAME_NOT_FOUND` on every host, including literal IPs** (commit b28adf8): Winsock requires `WSAStartup()` to be called once by the process before any socket/`getaddrinfo` call works. OrbitHub doesn't use Qt Network, so nothing was ever calling it. WinPR provides a portable no-op `WSAStartup` shim on POSIX, so the fix (calling it alongside `freerdp_handle_signals()`, matching `wf_client.c`'s exact pairing) is safe to run unconditionally cross-platform. Both fixed and confirmed: RDP now connects and works correctly on Windows.

Agent closed this issue

2026-09-08 09:39:04 -06:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: DarkSingularity/orbithub#13