[Bug] Single-App / RemoteApp launches hang at welcome screen — no TS_RAIL_ORDER_EXEC_RESULT from guest

[CS-Websolutions]

What version of WinBoat are you running?

v0.9.0

Your Environment

• WinBoat version: 0.9.0
• Host OS: Linux Mint (Ubuntu 24.04 base)
• Kernel: 6.17.0-22-generic
• Desktop Environment: Cinnamon (X11)
• FreeRDP version: 3.5.1 (system package, freerdp3-x11)
• Docker image: ghcr.io/dockur/windows:5.14
• Docker: Docker Engine (system install)
• Guest OS: Windows 11 (Build 26200.6584)
• Installation method: .deb package
• Guest Server status: Running, listening on port 7148, /health returns {"status":"ok"}

Steps to Reproduce / Context

Context

A WinBoat 0.9.0 setup that previously worked correctly (single-app launches functional, shared folders working) stopped launching single applications after a routine Linux system update. The full Windows Desktop session continues to work normally. Issue persists after multiple container restarts and a full system reboot.

Steps to Reproduce

1. Install WinBoat 0.9.0 on Linux Mint (Ubuntu 24.04 base) with FreeRDP 3.5.1 and the ghcr.io/dockur/windows:5.14 image, Windows 11 guest.
2. Confirm baseline functionality: launch ⚙️ Windows Desktop from the WinBoat UI — full desktop opens normally, shared folder accessible, clipboard and sound working.
3. Log off cleanly from the desktop session via Start Menu → User → Sign out.
4. From the WinBoat UI, launch any single application — tested with:
   • ⚙️ Windows Explorer
   • Adobe Illustrator 2026
   • Other built-in apps
5. Observe: a FreeRDP window opens showing the Windows blue welcome screen with a loading spinner, which never advances. After ~30–60 seconds the window may turn black, but no application window ever appears.
6. WinBoat log shows: WARN | FreeRDP process returned error code 'null'
7. Killing FreeRDP (pkill -9 xfreerdp3) and retrying produces the same result.
8. Returning to ⚙️ Windows Desktop confirms the desktop session still works perfectly — the issue is isolated to single-app / RemoteApp launches.

Additional verification performed

• docker ps confirms container is Up, ports correctly mapped (47305->3389/tcp, etc.)
• docker exec WinBoat ls -la /shared shows the bind mount is intact and populated
• Inside Windows: services.msc confirms WinBoatGuestServer is running with startup type Automatic
• Inside Windows: netstat -an | findstr 7148 shows port 7148 in LISTENING state with active connections from the WinBoat host
• Inside Windows: curl http://localhost:7148/health returns {"status":"ok"}
• Manually executing the exact xfreerdp3 command from ~/.winboat/winboat.log reproduces the freeze identically — confirming this is not a UI-layer issue in the WinBoat host app.

Logs

winboat-bugreport.tar.gz

Expected Behavior

Launching a single application (e.g., Adobe Illustrator, Windows Explorer, Notepad) from the WinBoat UI should open it as a seamless RemoteApp window on the Linux host, integrated into the desktop environment like a native application. The Windows guest should respond to the TS_RAIL_ORDER_EXEC PDU with a corresponding TS_RAIL_ORDER_EXEC_RESULT and then stream the application window back via the RAIL channel.

Current Behavior

Single-application launches fail after a routine Linux system update. The behavior is consistent across every app (Illustrator, Explorer, Notepad — both user-installed and built-in):

• The FreeRDP window opens and displays either the Windows blue welcome screen with a loading spinner that never advances, or remains a black window.
• After ~30–60 seconds, WinBoat logs WARN | FreeRDP process returned error code 'null'.
• The full Windows Desktop session (⚙️ Windows Desktop) launches and works without any issues.
• The RDP connection itself completes successfully up to CONNECTION_STATE_ACTIVE, the RAIL handshake succeeds, and TS_RAIL_ORDER_EXEC is sent — but the guest never replies with TS_RAIL_ORDER_EXEC_RESULT. The connection stays alive on heartbeat PDUs only, with no application window ever appearing.
• Guest Server is healthy: port 7148 is listening, curl http://localhost:7148/health returns {"status":"ok"}, and active connections from WinBoat to the Guest API are established.

Before the Linux system update, single-application launches worked normally.

Possible Solution

The exact root cause is unclear, but based on the debug output the issue appears to be on the Windows guest side rather than in FreeRDP or the WinBoat host app, since:

• The RAIL channel handshake completes successfully
• A valid TS_RAIL_ORDER_EXEC PDU is sent
• The guest acknowledges with TS_RAIL_ORDER_MINMAXINFO but never sends TS_RAIL_ORDER_EXEC_RESULT

Possible directions to investigate:

• A recent Windows update inside the container image (ghcr.io/dockur/windows:5.14) may have changed RemoteApp/RAIL behavior or introduced a regression in the user profile initialization that prevents EXEC_RESULT from being returned.
• The WinBoat Guest Server / RemoteApp launcher inside Windows may need to be re-registered or re-installed after certain Windows updates. An option in the WinBoat UI to reinstall/repair the guest agent without rebuilding the entire container would help users recover from this state.
• Adding a fallback in the WinBoat host app that detects a missing EXEC_RESULT within a timeout and surfaces a clear error message (instead of the silent freeze on the welcome screen) would significantly improve diagnostics for affected users.
• Possibly related to issues [Bug] Apps don't launch, only desktop #216 and [Bug] application rdp windows not working freerdp 3.23.0 #698 — a consolidated investigation into RAIL/RemoteApp reliability across FreeRDP versions and Windows guest builds may be warranted.

Quality Notice

• I have checked the issue tracker and verified that this bug is a unique case.

[ZAJDAN]

same issue
WinBoat version: 0.9.0
Host OS: Debian 13
Kernel: 6.12.90+deb13-amd64
Desktop Environment: KDE Plasma 6.3.6 (Wayland)
FreeRDP version:
freerdp3-x11 3.15.0+dfsg-2.1+deb13u3
libfreerdp-client3-3:amd64 3.15.0+dfsg-2.1+deb13u3
libfreerdp3-3:amd64 3.15.0+dfsg-2.1+deb13u3

Guest OS: Windows 11