Repository navigation
WinUI3 apps using 1.6 SDK stop rendering in remote desktop #10009
Description
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]
Activity
Balkoth commentedon Sep 26, 2024
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.
AdriaanLarcai commentedon Oct 2, 2024
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.
zalox commentedon Oct 7, 2024
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
krevio commentedon Oct 8, 2024
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.
NoPointerActionsAfterTabing.mp4
naurisivanans commentedon Nov 12, 2024
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.
AdriaanLarcai commentedon Nov 13, 2024
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.
garrettpauls commentedon Dec 30, 2024
This issue still exists when using WindowsAppSdk version
1.6.241114003and1.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?
garrettpauls commentedon Jan 15, 2025
This issue still exists when using WindowsAppSdk version
1.6.250108002which released today.AdriaanLarcai commentedon Jan 15, 2025
At this point this is probably one of those issues that will just be ignored until the end of days.
garrettpauls commentedon Jan 15, 2025
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...
13 remaining items
garrettpauls commentedon Apr 10, 2025
This appears to be fixed in WindowsAppSDK
1.6.250402001and1.7.250401001released 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.
iablaauw-MS commentedon Apr 10, 2025
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!
liqiug commentedon May 5, 2025
as my test , it has been fixed as WinUI3,
however the problem still happen on MAUI, but the MAUI does not allow to post:
dotnet/maui#26055
any plan of fix it on MAUI?
MartyIX commentedon May 6, 2025
Qiuguo Li (@liqiug) dotnet/maui#28499 was merged and is planned to be released as .NET 9 SR71. You can try MAUI nightly to confirm if the issue is fixed for you or not.
Footnotes
I expect release on patch Tuesday -- i.e. in a week. ↩
malkia commentedon May 31, 2026
I've started noticing this recently. Logging into our VM machines with 24H2, coming from 25H2 26220.8474 (Insider build), and I can't click on the taskbar (but tabbing, keyboard moving works!), then feedback itself (Win+F) also does not work with mouse, neither emoji, or the Task Manager (probably more). AFAIK these might be using Win UI 3. Other apps still work.
malkia commentedon Sep 29, 2026
This is now even more pervalent with 26H1 - Please fix it! Now I have to reboot my work machine, otherwise I have to navigate with keyboard. Please!
YexuanXiao commentedon Sep 29, 2026
The taskbar uses WinUI 2. In addition, this kind of issue should be reported in the Feedback Hub.
riverar commentedon Oct 21, 2026
Dimiter 'malkia' Stanev (@malkia) Is this something you can still reproduce with WinUI 2 or 3?
malkia commentedon Oct 23, 2026
I can't reliably, but RDP-ing into a machine more likely causes it. I'm with 26H1 line of Releases (which is different than 26H2).