Share via

RDP red color issue with Windows 10 ARM64 mstsc (Surface Pro X)

Marc-André Moreau 86 Reputation points
2020-08-26T18:48:57.263+00:00

I have been using mstsc (ARM64 native! thank you for that) on my Surface Pro X to RDP into a Windows 10 virtual machine. Both sides are using Windows 10 2004 with the latest updates, but this issue has always been present.

There appears to be an ARM64-specific color decoding issue in the RDP engine used by mstsc that affects red specifically. It is particularly bad when either PowerShell or the command prompt shows red text over a blue or black background, making it impossible to read in many cases.

Here is a screenshot show the problem on the RDP client side:

20654-mstsc-arm64-red-color-issue-corrupted.png

And here is a screenshot taken directly on the server using the snipping tool, to bypass the corruption introduced by RDP:

20607-mstsc-arm64-red-color-issue-original.png

Now due to my past work in FreeRDP implementing many of the RDP codecs, I have a few theories as to what could be happening here. First, the issue appears to be made particularly bad around limit values (full red, full blue, full black). The same cannot be observed with the intel 64-bit version of mstsc, so it most likely has to be a difference in one of the ARM64 SIMD accelerated functions dealing with one of the codecs or color conversion as opposed to their intel equivalent.

I know the first thing you will want to figure out is which codec is actually negotiated and used to draw the corrupted region of the screen. I would like a bit of help with that, as I don't really know what the best way would be to confirm the actual codec in use with modern mstsc. I suspect this is negotiating usage of the RDP8 graphics pipeline, which then uses a mixture of other codecs (RemoteFX, ClearCodec, NSCodec, etc.). One of these codecs is responsible for these pixels, and this is where we should look first.

I have tried using the Android ARM64 remote desktop application and it also doesn't show the same problem. I know that mstsc doesn't use the same internal engine as the mobile applications, so this is most likely a bug limited to just the ARM64 version of mstsc.

Remote Desktop
Remote Desktop
A Microsoft app that connects remotely to computers and to virtual apps and desktops.
4,358 questions

6 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Karlie Weng 15,916 Reputation points Microsoft Vendor
    2020-08-27T09:26:11.967+00:00

    Hi,
    Please try set limit on color depth and change graphics renderer in Group Policy to see if the problem still exists.

    Policy path:
    Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
    20736-image.png

    May I know more detailed version information about your RDP? as follows:

    20749-image.png

    How about using the new Remote Desktop client (MSRDC)? Will the issue persist?

    More about MSRDC:
    https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/windowsdesktop

    Best regards
    karlie

  2. Marc-André Moreau 86 Reputation points
    2020-08-31T19:41:39.81+00:00

    Hello Karlie,

    Sorry for the late reply. I did make some changes to the mentioned group policies, by setting the maximum color depth to 32bpp, and the "use hardware graphics adapters for all Remote Desktop Services Sessions".

    21526-gpedit-rdp-color-depth.png

    As for the mstsc version, here it is:
    21458-mstsc-version.png

    IIRC, the "use hardware graphics adapters for all Remote Desktop Services Sessions" GPO enables the usage of the hardware GPU when possible for accelerated graphics inside the RDP session, but this is not related to how RDP encodes the graphics.

    As for the maximum color depth GPO, I recall there used to be a problem where the default maximum color depth was not 32bpp in Windows 8.1 and broke RDP 7.1 RemoteFX negotiation in Windows 8.1 servers. Maybe this got fixed since then, but it didn't affect RDP8 clients like mstsc that didn't try negotiating RDP 7.1 by default.

    In any case, with default GPOs + those two GPOs modified, I still have the same issue. What I don't understand is that the intel 64-bit mstsc from other Windows environments does not have the same issue, only ARM64 has this problem. It is possible that the ARM64 mstsc negotiates a different codec, but I would need a way to confirm what I am actually getting over the wire. Back in the day, I had complex tooling to decrypt the RDP traffic, but I have nothing at hand right now that would let me know which codec is used in my RDP session.

    Is there a way to enable verbose system events in the client or server to figure out what I am getting? At the bare minimum, I would expect the RDP8 graphics pipeline over TCP (no multitransport here - this is TCP only, no UDP traffic would go through). However, the RDP8 graphics pipeline uses a mixture of RemoteFX, ClearCodec, NSCodec and variants of H.264 and it is difficult to truly know which one is used without looking at the decrypted packets. Just forcing the usage of another codec entirely may make the problem "go away" if it is limited to the one I am currently negotiating every time.

    As for the MSRDC client, I installed it, but it looks like the client that can only work with workspace URLs for publishing remote desktops. I don't have such an environment (no Remote Desktop Gateway, no Windows Virtual Desktop), this is just a regular direct TCP RDP connection to a Windows 10 VM. Can this client be used for direct connections? I didn't find the option.

    0 comments
  3. Karlie Weng 15,916 Reputation points Microsoft Vendor
    2020-09-02T06:38:05.63+00:00

    Hello there,
    Sorry that didn’t help :(

    1. About the system events, did you check these logs?
      Event Viewer – Applications and Services Logs -Microsoft-Windows-RemoteDesktopServices-RdpCoreTS_Admin
      Event Viewer – Applications and Services Logs -Microsoft-Windows-RemoteDesktopServices-RdpCoreTS_Operational
      Event Viewer – Applications and Services Logs -Microsoft-Windows-RemoteDesktopServices-remotefx-synth3dvsc
      Event Viewer – Applications and Services Logs -Microsoft-Windows-RemoteDesktopServices-remotefx-vm-kernel-mode-transport
      Event Viewer – Applications and Services Logs -Microsoft-Windows-RemoteDesktopServices-remotefx-vm-user-mode-transport
      Event Viewer – Applications and Services Logs -Microsoft-Windows-RemoteDesktopServices-SessionServices_Operational
      Event Viewer – Applications and Services Logs -Microsoft-Windows-TerminalServices-local sessionmanager
      Event Viewer – Applications and Services Logs -Microsoft-Windows-TerminalServices-remoteconnectionmanagement
      Event Viewer – Applications and Services Logs -Microsoft-Windows-TerminalServices-remoteconnectionmanagement

    2.How about installing Microsoft remote desktop software from windows store?
    Get started with the Windows Store client
    https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/window

    Best regards
    Karlie

    0 comments
  4. Marc-André Moreau 86 Reputation points
    2020-10-02T15:19:13.313+00:00

    Sorry for the late reply, the issue persists and it is really annoying as I often need to copy and paste text from terminals into a text editor to read it.

    I cannot use the Microsoft Remote Desktop client from the Windows store because I am unable to disable NLA, a workaround I need in order to connect to my Azure AD joined virtual machine. I am using a network tunnel to reach the VM and NLA with Azure AD just won't work in that scenario. I can successfully work around the problem with mstsc and a custom .rdp file, but this means that the Microsoft Remote Desktop client from the Windows Store is unfortunately not an option for me.

    This being said, I am pretty sure the issue is limited to mstsc (and the ActiveX) for Windows on ARM64 specifically. I know the newer clients are recommended (both WVD and "modern" clients), but AFAIK, mstsc + the ActiveX are not going away anytime soon, or at least I hope they don't. They are far too important in the industry to fall behind in terms of support. The issue should be easy to reproduce to anyone with access to a Surface Pro X and mstsc.

    While writing this, I had an idea: I work at Devolutions, the company behind Remote Desktop Manager. Our product uses the Microsoft RDP ActiveX but we don't have a native ARM64 build, which means it is a great way to force using the Intel 32-bit ActiveX on the same machine where mstsc for ARM64 is having issues. Guess what? I made a connection through Remote Desktop Manager and the colors are perfect :) mstsc has a check at startup to force using the correct build, so it is not possible for me to force using the 32-bit intel mstsc on the Surface Pro X in emulation mode, otherwise it would have been easy to confirm the same.

    Can you get anyone from Microsoft QA to confirm the issue? I am now quite convinced the problem is isolated to the ARM64 build of mstsc.exe / mstscax.dll, and it would not affect the intel builds.

    0 comments
  5. Marc-André Moreau 86 Reputation points
    2020-11-02T01:01:26.93+00:00

    Any update on this, if only to confirm the issue? I am pretty sure this is the kind of issue that should be easy to reproduce by anyone with a Surface Pro X, mstsc, and a machine to connect to.

    I can't be the only one facing this problem, and it is extremely annoying because every time an error is thrown in both the command prompt or PowerShell, it is usually red, and therefore unreadable to the point that I have to copy/paste the error in notepad to read it.

    I can speculate on what the issue is (fairly certain it is a bug affecting only ARM64 / NEON optimized color conversion code), but that is beside the point. The first step is to have someone other than me confirm that they can reproduce the issue, so we can at least acknowledge that there is an issue to begin with.

    I don't think there is anything specific to be done to trigger it, it happens on all Windows 10 and Windows Server 2019 VMs I have connected to from my Surface Pro X. Connecting to exactly the same machines from the intel build of mstsc always works flawlessly, no red color issue.