msrdc continously restarting

[Kilill]

Windows build number:

10.0.19045.2311

Your Distribution version:

20.04

Your WSL versions:

WSL version: 1.0.0.0 Kernel version: 5.15.74.2 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2311

Steps to reproduce:

1. Upgraded windows to latest release
2. wsl --update
3. wsl

WSL logs:

stderr.log versions.txt weston.log wlog.log pulseaudio.log

WSL dumps:

No response

Expected behavior:

wsl should start and graphical linux progams should run

Actual behavior:

wsl start and shows command prompt and works as expected for a linux distro in text/terminal mode. but windows system is lagging, and almost all windows constantly repaiting. And ofc no graphicl linux progs works.

checking stderr.log i see this:

[10:51:31.376] <5>WSLGd: Run:104: pid 15 exited with status 9, /mnt/c/Users/kill/AppData/Local/Microsoft/WindowsApps/MicrosoftCorporationII.WindowsSubsystemForLinux_8wekyb3d8bbwe/msrdc.exe /v:82ACAEE4-02E2-4CE9-9812-B0592ABC85B8 /hvsocketserviceid:15489104-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\82ACAEE4-02E2-4CE9-9812-B0592ABC85B8\wslg C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.0.0_x64__8wekyb3d8bbwe\wslg.rdp 
Error: debug scope named 'rdp-audio' is already registered.
Error: debug scope named 'rdp-audio-in' is already registered.

[byjrack]

This issue is being caused by "Unicode Injection IME hook" that is "CxInjIme.dll". Once we added this hook "Unicode Injection IME hook" that is "CxInjIme.dll" to exclusion list we cannot see the msrdc crashes anymore with that WSL2/WSLg is just working fine.

1. Backup the registry key Computer\HKEY_LOCAL_MACHIN E\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Unicode Injection IME hook
2. Backup the registry key Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Citrix\CtxHook\AppInit_Dlls\Unicode Injection IME hook
3. Inside both the registry locations referenced above you will find a DWORD value called "flag"
4. Set the data for this value to 0
5. Reboot the VDA

Yup we found pretty much the same thing. I didn't find I needed to disable the 32b copy of the Hook in my testing, but always a chance I messed up some of my iterations.

Per Citrix there is an internal bug on the issue, but they had no details on the fix or how far it would be back-ported to when released.

[hideyukn88]

@Koki007365, @byjrack, thank you very much for information, we have been informing Citrix this issue using our internal channel and directly communicating with their engineering team, but unfortunately, we have not heard any updates from them yet, but we will continue to keep escalating, thanks!

[byjrack]

Actually just heard back on my case this afternoon. It looks like it's how UWP apps handle PATH lookups and some of the limitations of the sandboxing. I tested moving the Pica library to system32 and no more crashing.

Question is what will be the permanent fix by Citrix. This may be where the Microsoft team can provide some counsel on how to make UWP/Sandbox apps work well in this case. Having MS add that location to the manifest doesn't seem right so didn't know if there was something beyond sys32 Citrix could do to make their bits accessible to any UWP app without the UWP author needing to add it to manifest.

The crash happens when msrdc.exe try to call GetKeyboardType hook api which trigger process load PicaDdApi64.dll library and crash. PicaDdApi64.dll is located in C:\Program Files\Citrix\HDX\bin (which is added to the path environment variable upon VDA installation). msrdc.exe is a UWP app and UWP apps have restrictions on the locations that they are allowed to access. https://learn.microsoft.com/en-us/windows/uwp/files/file-access-permissions msrdc.exe is in “C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe” hiden directory which owner is TrustedInstaller . Looks Store Apps do not search Citrix directory “C:\Program Files\Citrix\HDX\bin\” even when has been added in Path environment.

Workaround: Copy PicaDdApi64.dll from C:\Program Files\Citrix\HDX\bin\ to c:\Windows\System32 which will be search for UWP.

[hideyukn88]

@byjrack, we have crash dump provided by other customers, and it shows the exception is raised from C:\Program Files\Citrix\HDX\bin\CxInjIme.dll. This happens when rdclientax.dll calls GetKeyboardType API, it's rerouted to CxInjIme.dll (instead of user32.dll). That said they are able to load a file C:\Program Files\Citrix\HDX\bin\CxInjIme.dll into msrdc.exe's process space for API hook, but not able to load PicaDdApi64.dll at same location? We will need to know how they load each of those files, thanks!

0:000> lmvm CxInjIme
Browse full module list
start             end                 module name
00007ff9`a6780000 00007ff9`a679e000   CxInjIme   (no symbols)           
    Loaded symbol image file: CxInjIme.dll
    Image path: C:\Program Files\Citrix\HDX\bin\CxInjIme.dll
    Image name: CxInjIme.dll
    Browse all global symbols  functions  data
    Timestamp:        Thu Aug 25 12:03:13 2022 (6307C771)
    CheckSum:         00029696
    ImageSize:        0001E000
    File version:     7.35.0.4
    Product version:  7.35.0.4
    File flags:       8 (Mask 3F) Private
    File OS:          40004 NT Win32
    File type:        2.0 Dll
    File date:        00000000.00000000
    Translations:     0409.04b0
    Information from resource tables:
        CompanyName:      Citrix Systems, Inc.
        ProductName:      Citrix XenApp & XenDesktop
        InternalName:     CxInjIme.dll
        OriginalFilename: CxInjIme.dll
        ProductVersion:   7.35
        FileVersion:      7.35.0.4
        FileDescription:  Citrix IME Hook DLL
        LegalCopyright:   (c) Citrix Systems, Inc.  All rights reserved.

[hideyukn88]

And it looks they are having same issue with other Microsoft RDP client products as well, https://support.citrix.com/article/CTX463527/ms-quick-assist-crashes-when-used-in-citrix-session.

[byjrack]

So word I am getting from Citrix is this will be resolved in the next CUs (2203 CU3 / 1912 CU8). It should be a change that doesn't require the exclusion workaround and allows for the Modern/embedded msrdc.exe to load the required libraries.

The most granular exclusion I have had success with is

Note the flag is a bitwise or of 0x200 to whatever is in your deployments Flag so for mine I went from 0x80000400 to 0x80000600 which was the 10th bit being flipped

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Unicode Injection IME Hook]
"Flag"=dword:80000600

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Unicode Injection IME Hook\msrdc.exe]

You can put a copy of Picadd in your sys32 as a different way of working around the issue, but that is a bit muddier in my mind and that next VDA upgrade you will have to clean up that copy manually so you don't get out of sorts on load ordering.

[punkboat]

Interestingly I've been experiencing this issue with WSL 1.3.11.0 - it does not occur in 1.2.5.0. I do not have Citrix installed.

[Bunie89]

I know this isn't the right place to ask but i've been having a similar issue to this (msrdp.exe rapidly restarting) and switching to MSTSC seems to be a functioning workaround for now. Are there any downsides to using mstsc (or upsides)? Also since im asking a dumb question, if there's any logs or information i could provide that would prove useful to this issue, i'd love to help. Thanks! Edit: To add a bit more information, the issue started after i upgraded from the WSL Stable the newer testing builds, my GUI apps worked fine under WSLG 1.0.51

[hideyukn88]

@Bunie89, thanks for info and that's very helpful. Basically mstsc.exe and msrdc.exe is almost same but there are several differences. One of major difference is that mstsc is updated as OS update while msrdc (in WSL) is delivered with WSL update, thus there is some newer functionality only available with msrdc. Also, there is some difference in security restriction as one is OS component and other is not. (Btw, we are currently evaluating a solution to run our msrdc.exe at same level of security restriction as OS's, and we know this fixes some known issues with WSLg). If you have a chance, please switch back to msrdc and share several log files from C:\Users\[your user name]\AppData\Local\Temp\DiagOutputDir\RdClientAutoTrace, please you pick timestamp close to the time when the issue occurred, thanks!

[NaterGator]

I was having this issue today with WSL2 while compiling some embedded target images inside WSL2; I have 34 similar logs all from the same cyclically repeating crash. Not sure what prompted the crashing to begin or why it self resolved, but while it was ongoing my system was pretty much brought to its knees.

Attaching logs from the first instance of the crash, the second to last, and the final crash. msrdc_logs.zip

I did notice I was hearing occasional popping from my speakers as things crashed and restarted; not sure if that's actually related to whatever was causing the crash or just an artifact of msrdc restarting and hooking into the audio subsystem again.

[WolfgangRamos]

So word I am getting from Citrix is this will be resolved in the next CUs (2203 CU3 / 1912 CU8). It should be a change that doesn't require the exclusion workaround and allows for the Modern/embedded msrdc.exe to load the required libraries.

The most granular exclusion I have had success with is

Note the flag is a bitwise or of 0x200 to whatever is in your deployments Flag so for mine I went from 0x80000400 to 0x80000600 which was the 10th bit being flipped

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Unicode Injection IME Hook]
"Flag"=dword:80000600

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\Unicode Injection IME Hook\msrdc.exe]

You can put a copy of Picadd in your sys32 as a different way of working around the issue, but that is a bit muddier in my mind and that next VDA upgrade you will have to clean up that copy manually so you don't get out of sorts on load ordering.

I had the same issue on my machine and it went away with an update to CITRIX version 2305. I don't see any restarts of msrdc anymore 😄 I am running:

> wsl --version
WSL version: 1.2.5.0
Kernel version: 5.15.90.1
WSLg version: 1.0.51
MSRDC version: 1.2.3770
Direct3D version: 1.608.2-61064218
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.3208

Thanks @byjrack for identifying CITRIX as (one potential) source of this issue.

[marstein]

I see this problem as well every wsl instance (I have 3, 2 docker-desktop and an Ubuntu) spawn msrdc.exe processes constantly taking focus. I have no Citrix installed. It's something else for me.

[michaelkebe]

@marstein It probably #841?

[MartinSoto]

Any hope that this gets fixed anytime soon? This is making me crazy and I need to use graphical applications so the "workaround" usually proposed won't work for me.

[GF-Huang]

Same issue, msrdc repeating crash when I launch WSL2 Ubuntu with these config:

[wsl2]
autoMemoryReclaim=gradual
networkingMode=mirrored
dnsTunneling=true

When I add guiApplications=false, crash event never show.

>wsl -v
WSL 版本： 2.0.14.0
内核版本： 5.15.133.1-1
WSLg 版本： 1.0.59
MSRDC 版本： 1.2.4677
Direct3D 版本： 1.611.1-81528511
DXCore 版本： 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows 版本： 10.0.22631.3155

[ACleverDisguise]

Any hope that this gets fixed anytime soon? This is making me crazy and I need to use graphical applications so the "workaround" usually proposed won't work for me.

I kill that guiApplications thing in the config and use VcXsrv instead. My GUI applications work fine.