Jump to content
  • 7

Disconnected sessions not logging off

Matt Sherman


I've been struggling getting disconnected sessions to log off by themselves. Citrix support can't seem to find a solution either. I was able to recreate the issue.

It appears that if a user logs off the workspace portal without closing the applications first, the sessions hang. In a company of about 700 users, this happens A LOT. 


We are running VA/VD 7 1912 from the cloud


The situation is exactly like the one in this previous post.......... https://discussions.citrix.com/topic/397967-xenapp-sessions-not-terminating/

We found 2 process that were causing the issue and added them to the registry on all VDAs 



After that was done, the applications themselves (Outlook, Chrome, Excel, etc) started causing the sessions to hang. After ending the application, the sessions do successfully log off.


Citrix recommended the following changes to local policy, Computer Config/Windows components/remote desktop services/remote desktop session host/session time limits



These changes were unsuccessful.


If anyone has any suggestions other than the one listed that have been successful, PLEASE let me know. 


Manually killing up to 80 sessions every morning is started to take a toll on me :)  


Link to comment
  • Answers 60
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 3

The same issue here after updating from CU3 to CU4. Some users missing user name in Citrix Studio. When I check the particular server, user is there and seems to be active, but when I try to logoff the user directly from the affected server via Task Manager or by logoff command, it does nothing. Also no log in Citrix Profile Mgmt about logoff attempt. Only thing that helps is killing LogonUI.exe via Task Manager.


This issue seriously affecting also regular reboot of the VMs as they time out during reboot process as the reboot takes due to this logoff issue very long time and then they keep turned off.

  • Like 3
Link to comment
  • 2

I was excited to see the fix above but unfortunately it hasn't resolved our issue.  We have had this issue since going to CU4 and its driving us mad. We  get users complaining that their session starts to freeze up and then becomes unresponsive. There session cannot then be disconnected once this happens and there are the usual processes loginui.exe crss.exe and any sometimes apps they were using Outlook.exe Excel.exe etc. I'm completely hacked of with Citrix its just not good enough and they are not helping. Were not the only ones with this issue and its annoying because its only happened since we have upgraded.  Can anyone 100 % confirm  rolling back to CU3 fixes this ?


Thanks in advance.

  • Like 2
Link to comment
  • 2

For us replacing StatUI.dll which were delivered from Citrix for specific editions (2109, 2112 and 19.12 CU4) fixed the issue of stucking logons and hanging disconnected sessions.

Before we've got the fix from Citrix, rollback of the VDAs to CU3 fixed the issue. Our farm was still on CU4!


The only issue that still exists, are the randomly disconnections. After disable "HDX Adaptive Transport" the disconnections are less than with enabled "HDX Adaptive Transport", but still there.


We've opened for that a Citrix Case #80987505 - they are still investigating the logs.

  • Like 2
Link to comment
  • 0

Update- Last night Citrix support had me add the executable for the applications to that same registry string (outlook.exe, winword,exe,eplorer.exe, etc) and that failed miserably. Doing that generated so many connection issues this morning, I had to remove that from from all the VDAs 

Link to comment
  • 0

I take back my last posting. The disconnects still exists. The only issue that is fixed by removing VUEMUIAgent.exe from 



is the stucking on logoffs. We still have same issues as described in this article:



Link to comment
  • 0

Same problem here after updating from 1912 CU3 to CU4 on Windows Server 2019 (1809)

Reverting VMs with VDA service onboard to snapshot taken previously the update, problem disappears so I'm pretty sure the issue depends on something triggered by CU4. I suspect there is something wrong interfacing to RDP services. Still investigating.


This is just to recap and to try to pitch in somehow:

  • What I can see are disconnected user sessions that get disconnected just a few seconds later the logon. Users that face the problem, indeed, since they don't see any window app (we use Virtual Apps)  appearing on screen, try again untill the requested app regularly starts on a different VDA server.
  • These session do not respect the session timeout policies and stay on until manually killed ot server restarts.
  • Several users report the error: "The task you are trying to do can't be completed because remote desktop services is currently busy. Please try again in a few minutes. Other users should still be able to log on."
  • The orphaned sessions run exclusively system processes such as winlogon.exe, csrss.exe, LogonUI.exe, dwm.exe, fontdrvhost.exe,ctxgfx.exe that basically are processes running under the same user's istance ID but executed by other service accounts (SYSTEM,DWM-sessionID, UMFD-sessionID). To force session to close, I've to kill the associated LogonUI.exe.
  • In Events (Application and Services Logs / RemoteDesktopServices-xxx) , I find the following errors related to RDP's RemoteFX module. This errors no longer appears after reverting back to CU3. I'd even exclude that it can depend on the MS updates level. We're running CU3 and CU4 with the same Windows Server 2019 Cumulative Update (2021-12 Cumulative Update for Windows Server 2019 fo x64-based Systems - KB5008218).
    Event ID		Task Category		Description
    101			RemoteFX module		The network characteristics detection function has been disabled because of Reason Code: 2(Server Configuration)..
    142			RemoteFX module		TCP socket READ operation failed, error 64
    143			RemoteFX module		TCP socket WRITE operation failed, error 64
    226			RemoteFX module		RDP_TCP: An error was encountered when transitioning from StateUnknown in response to Event_Disconnect (error code 0x80070040).
    227			RemoteFX module		'Failed GetConnectionProperty' in CUMRDPConnection::QueryProperty at 2884 err=[0x80004001]
    228			RemoteFX module		Disconnect trace:CUMRDPConnection Disconnect trace:'calling spGfxPlugin->PreDisconnect()' in CUMRDPConnection::PreDisconnect at 4595 err=[0xc], Error code:0xC


  • Analizing these sessions with PS (Get-BrokerSession cmdlet), I noticed that all of them have the LogoffInProgress attribute set as True:
    IdleSince			09/01/2022 08:42:17
    ImageOutOfDate			False
    InMaintenanceMode		False
    IsAnonymousUser			False
    IsPhysical			True
    LaunchedViaHostName		ctxdc01.mydomain.com
    LaunchedViaPublishedName	My Computer
    LogoffInProgress		True	<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    LogonInProgress			False
    MachineName			MYDOMAIN\CTXVDA03
    MachineSummaryState		InUse
    MachineUid			4
    MetadataMap			System.Collections.Generic.Dictionary`2[System.String,System.String]
    OSType				Windows 2019
    PersistUserChanges		OnLocal
    PowerState			Unmanaged
    Protocol			HDX
    ProvisioningType		Manual
    ReceiverName			MYCLIENT1
    SecureIcaActive			False
    SessionId			-1
    SessionKey			8b0b191a-2c85-42d4-b929-bec3cc2ca4e8
    SessionReconnection		Always
    SessionState			Active
    SessionStateChangeTime		05/01/2022 08:42:11
    SessionSupport			MultiSession
    SessionType			Application
    SmartAccessTags			System.String[]
    StartTime			05/01/2022 08:41:27
    Uid				71454
    UntrustedUserName		MYDOMAIN\jdoe
    ZoneName			Primary
    ZoneUid				559932d5-c8f8-4657-b360-79d0de0ce600


Link to comment
  • 0

I just upgraded a customer from 1903 to 1912 CU4 and started seeing this issue. Initially it was reported as inability to logoff a user session. Fails to logoff from Director, Studio, Task Manager or logoff.exe.


I found this article, followed the process of identifying the LogonUI.exe PID and killing with Process Explorer. Once I did that the session logged off.  I also have a number of disconnected sessions with no username (presumably unable to logoff) across multiple VDAs.




I will open a Citrix support call tomorrow on this. By any chance care to share any existing case# you may have on this so they can cross-reference?

Link to comment
  • 0

We are experiencing this issue as well and unfortunately cannot pin it on a specific VDA upgrade. We are currenly running 2112, though, and we've tried adding the LogonUI.exe and winlogon.exe entries to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Sysprocs registry key.


I assume adding those entries to the (analogous?) Citrix LogOffCheckSysModules entry would be similarly fruitless, but I'll likely give it a shot soon nonetheless.


EDIT: Also, we have yet to find any rhyme or reason with who is affected by the issue, though, interestingly, there are plenty of users who have never experienced the problem.

Edited by Brian Black
Link to comment
  • 0

Thanks for the feedback. I did open a Citrix case and they pointed me to the standard LogOffCheckSysModules value https://support.citrix.com/article/CTX891671


I have switched our environment over to 1912CU3 to see if the behaviour persists. I am starting to wonder if there is some interaction with recent Windows updates. Our systems are Server 2019 currently patched to November 2021 level.


Also to note - in my environment it is 100% published desktops and no published apps.

Edited by Arthur Chan
Link to comment
  • 0

After rolling back to VDA2106 we have not seen the issue.


I did install out of band KB5010196 (https://support.microsoft.com/en-us/topic/january-4-2022-kb5010196-os-build-17763-2369-out-of-band-1a7a9a37-b154-4e73-92dc-1a2f65a4c0d1) This fixes some issues with RDP.


I do remember that some servers running VDA2109 and did not have this KB had the described issue of the server no longer responding (and RDP not working anymore). Could be related, could be coincidence.

Link to comment
  • 0

I'm seeing the exact same issue. Server 2019 with VDA 1912 CU4. Didn't have any issues with CU2. I could log off disconnected sessions without issue. I called Citrix Support to find they don't have a solution and weren't familiar with the problems.


I was on CU2 but going to go ahead and move backwards to CU3.


Citrix doesn't have a fix nor do they seem interested in figuring out what the VDA is doing.

Link to comment
  • 0

Do any of you utilize Imprivata by chance? What OS are you guys seeing this on? If you take one session stuck in Disconnected state, kill one process at a time, without stopping logonUI or any others which ones are left? If just native OS, that you may want to look in Process explorer to get more info if possible. 

Link to comment
  • 0

Thanks for popping in. No, my affected client is straightforward CVAD/S to on-prem VDA with just AD authentication. VDA is Server 2019 patched to Nov 2021. The only interesting system-level software is Crowdstrike for A/V. I didn't get a chance to try, but if left long enough the session goes into a state where there is no username attached (it appears in Studio as a disco session with no username). The session doesn't exist in quser but does in qwinsta. If we try and shut down the OS it doesn't succeed. Doing ctrl-alt-del at VM console results in no logon prompt so the OS is pretty borked at that point and we have to power off.

Link to comment
  • 0

We are also running a pretty vanilla Server 2019 VDAs hosting just virtual apps and patched to December 2021 level. I have not yet tried adding the registry keys to LogOffCheckSysModules.


We also see the servers fairly often refuse to finish shutting down, hung at Windows logon screen, seemingly unresponsive to ctrl-alt-del. I would like to try to correlate the act of manually killing all "ghost" disconnected sessions at the end of the day (by killing LogonUI.exe) to see if that allows the server to always shutdown gracefully.


I would also like to try disabling our A/V to see if that has any bearing.

Link to comment
  • 0

We had the same issue and was also replacing the StatUI.dll but totally different results:


VDA2109 Windows Server 2019 as OS, it fixed the issue, everything was fine

VDA2109 Windows Server 2016 as OS, login not possible anymore. Got only Client connection error in Director and the session was not build. EventViewer show, that the application login.exe crashed by every try to login.
After reverting the the MC and usinf the "original" StatUI.dll the login is fine again.
So, be careful by applying that patch. On my test member server everything was okay, after MC update over the night for 60 member server, i getting a lot problems......

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...