[Bug] Will not start any app

[Mgrmjp]

What version of WinBoat are you running?

WinBoat Beta v0.9.0 Prod

Your Environment

OS: EndeavourOS
Kernel: 6.18.13-arch1-1
DE: KDE (wayland)
Plasma: plasmashell 6.6.1
GPU: c4:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Phoenix1 (rev dd)
Drivers: linux-firmware-nvidia-20260221-1,mesa-1:26.0.1-1 mesa-utils-9.0.0-7
Audio: gst-plugin-pipewire-1:1.4.10-2,kpipewire-6.6.1-1 libpipewire-1:1.4.10-2,libwireplumber-0.5.13-1 pipewire-1:1.4.10-2,pipewire-alsa-1:1.4.10-2 pipewire-audio-1:1.4.10-2,pipewire-jack-1:1.4.10-2 pipewire-pulse-1:1.4.10-2,qemu-audio-pipewire-10.2.0-3 wireplumber-0.5.13-1

Steps to Reproduce / Context

Looks like this when starting any app:

Logs

winboat.log

Expected Behavior

Should open app?

Current Behavior

Stuck.

Possible Solution

No response

Quality Notice

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

[SuhasBharadwajK]

I actually have the same issue. I am running Kubuntu 25.10 with KDE Plasma 6.4.5 running on Wayland. Full-screen apps work (such as Windows Desktop and browser-based RDP) but any normal applications like Windows Explorer, etc. are stuck on the welcome screen. I have to send a KILL to each of the xfreerdp processes to even close them.

[lual98]

Same here as well with CachyOs and KDE Plasma 6.6.1. It only shows parts of the login screen instead of the app and I need to kill xfreerdp even if the container has already been stopped.

[Aqua1ung]

Same boat. The only application that works is "Windows Desktop." None of the others open up properly, and can't even be killed other than by stopping the container. (Using Podman, if this makes a difference.)

[Mgrmjp]

Downgrading FreeRDP seemed to fix this for me, but I haven’t done comprehensive testing yet, so please treat this as a workaround and not a confirmed root cause.

Before downgrade:

• “Windows Desktop” could open

After downgrade:

• Apps started opening again in my quick checks.

Command used (Arch-based):

sudo pacman -U https://archive.archlinux.org/packages/f/freerdp/freerdp-2%3A3.22.0-2-x86_64.pkg.tar.zst

Reference (similar report in another project):
eylenburg/linoffice#110

If others can confirm whether this helps on their setup too, that would be useful data.

If this is reproducible across multiple distros/DE setups, it may point to something in newer FreeRDP versions rather than WinBoat-specific behavior.

[lual98]

Downgrading FreeRDP seemed to fix this for me, but I haven’t done comprehensive testing yet, so please treat this as a workaround and not a confirmed root cause.

I can confirm that downgrading freerdp fixed it for me

[SinclairKS]

Not Winboat related, but I can confirm this is also affecting WinApps on Arch. Rolling back to the provided version restored normal operation. Seems like something changed or got broken in the latest FreeRDP version.

[aaylnx]

Downgrading FreeRDP seemed to fix this for me, but I haven’t done comprehensive testing yet, so please treat this as a workaround and not a confirmed root cause.

This worked for me. Thank you!!!

[SuhasBharadwajK]

Downgrading FreeRDP seemed to fix this for me, but I haven’t done comprehensive testing yet, so please treat this as a workaround and not a confirmed root cause.

Before downgrade:

• “Windows Desktop” could open

After downgrade:

• Apps started opening again in my quick checks.

Command used (Arch-based):

sudo pacman -U https://archive.archlinux.org/packages/f/freerdp/freerdp-2%3A3.22.0-2-x86_64.pkg.tar.zst
Reference (similar report in another project): eylenburg/linoffice#110

If others can confirm whether this helps on their setup too, that would be useful data.

If this is reproducible across multiple distros/DE setups, it may point to something in newer FreeRDP versions rather than WinBoat-specific behavior.

Yes, that is exactly right. I suspected the same thing and downgraded it to 3.22.0. I am using the Flatpak version, so I used sudo flatpak update --commit=7e1febf6bca22fb1d59dd224d6fbaa06e5fffb20cb7e0199f7300e98efcd814b com.freerdp.FreeRDP to downgrade to the commit of the 3.22.0 release.

But I still think WinBoat should make the required changes to work with FreeRDP 3.23.x since they fixed a bunch of CVEs in the new release, a couple of them being high impact at 8.8.

[MohnJadden]

Downgrading FreeRDP seemed to fix this for me, but I haven’t done comprehensive testing yet, so please treat this as a workaround and not a confirmed root cause.
Before downgrade:

• “Windows Desktop” could open

After downgrade:

• Apps started opening again in my quick checks.

Command used (Arch-based):
sudo pacman -U https://archive.archlinux.org/packages/f/freerdp/freerdp-2%3A3.22.0-2-x86_64.pkg.tar.zst
Reference (similar report in another project): eylenburg/linoffice#110
If others can confirm whether this helps on their setup too, that would be useful data.
If this is reproducible across multiple distros/DE setups, it may point to something in newer FreeRDP versions rather than WinBoat-specific behavior.

Yes, that is exactly right. I suspected the same thing and downgraded it to 3.22.0. I am using the Flatpak version, so I used sudo flatpak update --commit=7e1febf6bca22fb1d59dd224d6fbaa06e5fffb20cb7e0199f7300e98efcd814b com.freerdp.FreeRDP to downgrade to the commit of the 3.22.0 release.

But I still think WinBoat should make the required changes to work with FreeRDP 3.23.x since they fixed a bunch of CVEs in the new release, a couple of them being high impact at 8.8.

I'm running Zorin and running flatpak update as above did not fix the issue, unfortunately.

I'm still stuck with a window drawn over everything; ending the process from System Monitor or via kill doesn't close the window. I have to log off or reboot.

[SuhasBharadwajK]

Downgrading FreeRDP seemed to fix this for me, but I haven’t done comprehensive testing yet, so please treat this as a workaround and not a confirmed root cause.
Before downgrade:

• “Windows Desktop” could open

After downgrade:

• Apps started opening again in my quick checks.

Command used (Arch-based):
sudo pacman -U https://archive.archlinux.org/packages/f/freerdp/freerdp-2%3A3.22.0-2-x86_64.pkg.tar.zst
Reference (similar report in another project): eylenburg/linoffice#110
If others can confirm whether this helps on their setup too, that would be useful data.
If this is reproducible across multiple distros/DE setups, it may point to something in newer FreeRDP versions rather than WinBoat-specific behavior.

Yes, that is exactly right. I suspected the same thing and downgraded it to 3.22.0. I am using the Flatpak version, so I used sudo flatpak update --commit=7e1febf6bca22fb1d59dd224d6fbaa06e5fffb20cb7e0199f7300e98efcd814b com.freerdp.FreeRDP to downgrade to the commit of the 3.22.0 release.
But I still think WinBoat should make the required changes to work with FreeRDP 3.23.x since they fixed a bunch of CVEs in the new release, a couple of them being high impact at 8.8.

I'm running Zorin and running flatpak update as above did not fix the issue, unfortunately.

I'm still stuck with a window drawn over everything; ending the process from System Monitor or via kill doesn't close the window. I have to log off or reboot.

Oh man! Are you sure you installed FreeRDP via Flatpak (and flathub)? Just to be sure, you can run flatpak list --app. Then, if you are indeed using FreeRDP from Flathub, you can see the history of the specific branch you are using using flatpak remote-info --log <remote_name (remote is most likely flathub)> <(the Application ID of your specific FreeRDP package)>. Then you should see the last few versions and their associated head commits. 7e1febf6bca22fb1d59dd224d6fbaa06e5fffb20cb7e0199f7300e98efcd814b happens to be the head of the 3.22.0 release of com.freerdp.FreeRDP.

Let me know what you find.

[Aqua1ung]

Is anyone from Winboat looking into making Winboat compatible with the new FreeRDP, or are they expecting us all to revert to the old FreeRDP release and stay there forever? In other words, has any of the Winboat devs taken notice of this incompatibility, and working to fix it (not just temporarily bypass it)?

[Edit] I am guessing that the "needs-triage" label already answers this one ... in the negative, that is.

[tezoatlipoca]

Yep - downgrading my flatpak version to 3.22 is a workaround for me

sudo flatpak update --commit=7e1febf6bca22fb1d59dd224d6fbaa06e5fffb20cb7e0199f7300e98efcd814b com.freerdp.FreeRDP