microsoft
WinUI3 apps using 1.6 SDK stop rendering in remote desktop
Describe the bug
We have a WinUI3 application that we recently updated to use WindowsAppSDK version 1.6.240829007. Prior to this update it ran over remote desktop fine, however after this update it will visually freeze if you switch away from the remote desktop window and back, however it still accepts mouse input during this time. Switching away from remote desktop and back again will restore the app's rendering functionality, and it will update as though all clicks had been interpreted and it just wasn't rendering for a while.
I've attached a small application which reproduces the behavior, as well as a video to demonstrate it. We've had multiple people run into this issue with the app after the update to 1.6.
This affects our unpackaged application, and the demo application is also unpackaged. I do not know if this bug exists for packaged applications, however our application must remain unpackaged, so I didn't attempt to test the packaged app behavior.
Steps to reproduce the bug
- Compile the attached demo application as Release x64.
- Copy the compiled app to a separate computer via a remote desktop connection. The RDP settings can be anything, I've tried a variety of performance settings from the default lowest (Modem) to the default highest (LAN) and they all produce the behavior.
- Run the compiled app in the remote desktop session and click a few buttons to verify it is working (clicking the buttons and nav view items should add messages to the log text box).
- Switch focus on the main (non-remote) computer to an application other than the remote desktop connection, and interact with the other application.
- Switch focus back to the remote desktop connection and click on the demo app. Attempt to click on some buttons and menu items, and it will not appear to respond to the clicks. The first click may apply the hover or pressed style to whatever you clicked, and after that nothing will update.
- Switch away from the remote desktop session and back again, then click on the application. It will update as though it had been processing the mouse clicks and just wasn't rendering until now. The application will now continue to behave as expected (until you switch away from remote desktop again).
Expected behavior
At step 5 of the reproduction, the application should behave normally and continue rendering. Clicking buttons and menu items should show the usual WinUI animations, and the text box log should update as things are clicked.
Screenshots
This video shows the problem in action: WinUI3RemoteDesktopBug
NuGet package version
WinUI 3 - Windows App SDK 1.6.0: 1.6.240829007
Windows version
No response
Additional context
The host computer is Windows 11 (23H2) build 22631.4169, the remote computer is Windows Server 2019 Standard (1809) build 17763.6293.
Remote desktop connection information is:
[Client details]
Client version: 10.0.22621.4036 (x64)
Local OS: Windows 10 Pro x64 (10.0, Build 22631)
[Network details]
Transport protocol: TCP
Round-trip time: 170 ms
Available bandwidth: 9.98 Mbps
Frame rate: 0 FPS
[Remote computer details]
Remote session type: Remote desktop
Gateway name: Not in use
Gateway logon method: Not in use
Remote computer: [redacted]
I was also able to reproduce this with the host computer being Windows 11 (23H2) build 22631.4169 and the remote computer being Windows 11 (23H2) build 22631.4169. Remote desktop connection information for that session is:
[Client details]
Client version: 10.0.22621.4036 (x64)
Local OS: Windows 10 Pro x64 (10.0, Build 22631)
[Network details]
Transport protocol: TCP
Round-trip time: 170 ms
Available bandwidth: 31.20 Mbps
Frame rate: 2 FPS
[Remote computer details]
Remote session type: Remote desktop
Gateway name: Not in use
Gateway logon method: Not in use
Remote computer: [redacted]
Seeing this too, as we have apps in production that can only be executed from a remote desktop session this is a critical bug for us.
We are experiencing this as well, but it's more like the app stops responding to mouse input. Using navigation keys on the keyboard (tab and arrow keys), we are still able to navigate through our app. Pressing a key such as spacebar sometimes returns mouse input. This must be a regression, since this was an issue in a previous version of the Windows App SDK.
I'm experiencing the same issue. Initially I thought it was the Remote Desktop Manager I was using. Downstream report: https://forum.devolutions.net/topics/43042/freezing-issues-with-rdm-20243100
Have a similar behavior even without RDP environment.
Simply hold down the Tab key for a while, at some point the window no longer responds to pointer inputs. But it seems to be random when this happens.
After pressing ALT or Shift, however, all previous clicks are processed.
https://github.com/user-attachments/assets/e11552e6-e1c4-4496-a298-91ab7fb71d6a
Is there any commitment, or at least acknowledgment, that this will be worked on? I wonder why this isn't treated with a bit more urgency, as it essentially makes version 1.6 unusable in production for enterprises.
This is a serious issue guys, and it's fully and easily reproduceable with any WinUI 3 app that targets any version of Windows App SDK 1.6. This creates serious confusion for users that need to work on VMs or via Remote Desktop when the app appears to have frozen after clicking out of and back into a VM / Remote session.
This issue still exists when using WindowsAppSdk version 1.6.241114003 and 1.7.241114004-experimental1. We'd like to keep our application up to date with new WinUI versions, however as most of our users run our application over remote desktop this is a hard stop for us.
Are there any active plans or a target version to get this issue fixed?
This issue still exists when using WindowsAppSdk version 1.6.250108002 which released today.
At this point this is probably one of those issues that will just be ignored until the end of days.
Unfortunately we cannot update our application to use newer versions of WindowsAppSdk until this is resolved, so I'll continue to report on this with every release until either it gets fixed, we rewrite our app with a different UI framework, or I move to a new job.
But yeah, I'm not terribly optimistic either...
Facing the same problem here. It's terribly frustrating.
I actually ended up motivating to rewrite our app in Blazor using MAUI, so much faster to dev, easier to create a good looking UI, and also performs far better than WinUI. It's not a small task, but so far it's going much smoother than working with this nonsense.
Just to echo some others here, we have held back updating to 1.6 because we have some scenarios for our application where we use RDP.
Would be good to get some feedback if this is being looked at, or any sort of estimated timeline for when that will be.
@torleifat get used to it...Don't expect a feedback any time soon from XAML team...From my experience they don't care too much to give any response. I'm at 1.5 and it doesn't look like I will be migrating to 1.6 soon because of this issue without any fix ETA and response from xaml team. There is also another regression issue without any feedback I'm waiting for fix.
And I'm already giving up in hope someone will reply this or other issues. It's frustrating af.
Hopefully this bug triggers in the Windows Explorer once they upgrade to this version...
This issue also occurs with the WinUI 3 Gallery app. However, I've discovered that I cannot reproduce it when using the Remote Desktop app from the Microsoft Store. That's our workaround for now.
This has nothing to do with the app being remote. I reproduced it too in a VM, but also locally. This is the issue: https://github.com/microsoft/microsoft-ui-xaml/issues/10213
This bug is really pathetic. I cannot believe the lack of urgency from MS regarding this.
This negatively affects our image and reputation with customers.
We wasted hours of valuable time with this immature technology stack.
We are now abandoning WinUI and moving to different technology.
This is still present in WindowsAppSDK version 1.6.250205002, released Feb 11, 2025.
We are running into the exact same issue. This also sometimes happens when running locally and not on a VM somewhere (but this is hard to reproduce). Can this get some recognition and priority? Sudden freezes like this are unacceptable for users.
Still present in Windows App SDK 1.6.6 (1.6.250228001). I had hopes because the changelog mentions a loop that blocks new mouse input events.
This is still present in WindowsAppSDK version 1.7.250310001, released March 18, 2025.
We are experiencing this as well, but it's more like the app stops responding to mouse input. Using navigation keys on the keyboard (tab and arrow keys), we are still able to navigate through our app. Pressing a key such as spacebar sometimes returns mouse input. This must be a regression, since this was an issue in a previous version of the Windows App SDK.
I'm really glad to find this comment. For a while i thought it's only my app and kept thinking what i'm doing wrong, but now i see so many people have the same problem.
Basically whenever I install my app to test it in a clean Hyper-V VM, i experience intermitted freeze in the UI. No mouse or touch inputs work on the UI elements but i can still move the window itself.
Many of users of my app need to use it in a VM too and this is a big problem.
This appears to be fixed in WindowsAppSDK 1.6.250402001 and 1.7.250401001 released April 9th, 2025!
We'll upgrade and do more testing in our production application as time allows, and I'll close this issue once we're confident it's been fully resolved.
Thank you everyone for your patience. This was fixed in WinAppSDK 1.6.7 and 1.7.1 as has been noted. Definitely let us know if you run into the issue again though!
as my test , it has been fixed as WinUI3, however the problem still happen on MAUI, but the MAUI does not allow to post: https://github.com/dotnet/maui/issues/26055 any plan of fix it on MAUI?
@liqiug https://github.com/dotnet/maui/pull/28499 was merged and is planned to be released as .NET 9 SR7[^1]. You can try MAUI nightly to confirm if the issue is fixed for you or not.
[^1]: I expect release on patch Tuesday -- i.e. in a week.
