Jump to content
Welcome to our new Citrix community!
  • 0

XenApp slow logon times, user get black screen for 20 seconds.

Andy White1709154166




We use XenApp 7.6 with Windows 2012R2 on VMware 5.5.


Logon times have become slow recently for users, they get a black screen just before their XenApp desktop shows up for about 20 seconds.  How do we find out the cause of this?  Most profiles are under 100mb.


If I turn all the GPOs off apart from the UPM GPO it's still slow, if I turn it off logons are fast.


The first user logon on the VDAs everyday is always slow (we reboot every night) even with the Citrix Profile Manger service off and all GPOs.



Link to comment
  • Answers 148
  • Created
  • Last Reply

Top Posters For This Question

Recommended Posts

  • 1



I spent a few more hours tracing this 'AppResolver Scan' process out and troubleshooting this issue. I found that the process is indeed directly tied to '%LOCALAPPDATA%\Microsoft\Windows\Caches'. Whether I include or exclude this directory in UPM I still have the same logon 'black screen' delay. The delay ALWAYS aligns with the 'AppResolver Scan' tasks in the 'Microsoft-Windows-Shell-Core/Operational' event log. My next step was to find out what is initiating this time consuming scan (which takes anywhere from 6-60 seconds for me) and how to stop it. I couldn't find any documentation on this process, so it was very difficult to troubleshoot. I kept looking through different things and eventually found something very promising in the UPM log...


2017-01-12;16:55:28.705;INFORMATION;SOP;citrixtestuser;2;460;Forcing Win8 Tile refresh by overwriting ResetCache value. Old value: 0


My thought here was that UPM might have been forcing the refresh by changing this value to something other than 0. To test this I created a little script that set that value to 0 in a loop for my test account on my test server and then I logged on. My hope was to set the value back to zero AFTER UPM changed it and BEFORE Explorer read it. The logon was fast with almost ZERO delay between ActiveSetup and Explorer presenting the start menu and desktop. I tested it a few more times with different accounts after fresh reboots and achieved the same result. I did notice that an 'AppResolver Scan' did still run, but AFTER the desktop and start menu had already loaded which I'm totally fine with. Everything else looked fine, pinning was still working, and shortcuts worked properly. I also tested excluding '%LOCALAPPDATA%\Microsoft\Windows\Caches' from UPM and the results were the same. This could possibly affect the native Windows 2012 R2/Windows 8 start menus, but I am using Classic Shell for my published desktops and it is not affected. In my opinion the Windows 2012 R2/Windows 8 start menu is unacceptable for users coming from a Windows 7 or Windows 10 world anyway.


The next step was to create a proper fix. I needed a way to set this value back to zero AFTER UPM, but before Explorer loads. Using the 'Run' registry value might not spawn the fix before Explorer and GPO scripts are in the same boat. Active Setup is the perfect candidate for this. I created a little Active Setup registry key that runs this command "REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache /t REG_DWORD /d 0 /f". I also excluded this Active Setup key from UPM so that it will run every time. This has made a tremendous difference for my published desktop logon times.




1.) Add Active Setup registry key/values (save the text below into a 'DisableUPMResetCache.reg' file):


Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\DisableUPMResetCache]
"StubPath"="REG ADD HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\StateStore /v ResetCache /t REG_DWORD /d 0 /f"

2.) Add UPM exclusions:


Directory - '!ctx_localappdata!\Microsoft\Windows\Caches'

Registry - 'SOFTWARE\Microsoft\Active Setup\Installed Components\DisableUPMResetCache'


3.) Didn't seem necessary, but remove the '%LOCALAPPDATA%\Microsoft\Windows\Caches' directories for affected user profiles.


If you block CMD/REG via GPO you may have to loosen that up, so this can run.




I am also using Classic Shell and I am seeing anything up to 45 seconds on the black screen.


Implemented the suggested changes to include the Stub entry and there is definitely an improvement but only on second login.

  • Like 1
Link to comment
  • 0

Hello, I'm not in work to check Director, but for profiles we ham a UPM server where they are all saved plus a little redirection to their home folders for the Desktop, favourites, documents, etc. My test user had the issue so I reset the profile and now out of 10 logins only once did it have the black screen issue, so it's much better. I don't want to reset everyone's profile.


I'm wondering if it is VDA related. All the VDA worker servers reboot at 2am every day, but the first user to log onto each VDA worker in the morning will definitely get the issue, the user after usually won't.


It's very strange, is there a hotfix or is it worth trying the latest VDA agent?

Link to comment
  • 0

7.6.0 had a 20 second logon delay bug that should have been fixed in 7.6.300 (and 7.6.2000).


Could be a faulty drive mapping in a group policy or logon script.


There are numerous logon time troubleshooting tools: ControlUp, UberAgent, LiquidwareLabs, etc.


Or simply run procmon while the user is logging in and see what's causing the delay.

Link to comment
  • 0

Do you have antivirus installed on the XenApp server? Trend Micro AV was causing my logons to take much longer until I made some adjustments.


Matt, have you made other adjustments than in https://www.citrix.com/blogs/2013/09/22/citrix-consolidated-list-of-antivirus-exclusions/ ? Can you share them with us?

Customer is running TM and performance is also really bad.Unfortunately he is using Worry free Business :(

Link to comment
  • 0

Alternativly I have try it with this in a powershell script as logon script and it worked for me, but without any warranty so use it on your own risk!


#WMI Query for the SID of the User which is logging in and put it in the SID Variable

$SID = (Get-WmiObject win32_useraccount -Filter "name = '$env:USERNAME' And domain='$env:USERDOMAIN'").SID

#Delete the SHC Key for the User
Remove-Item -Path REGISTRY::HKEY_USERS\$SID\SOFTWARE\Microsoft\Windows\CurrentVersion\UFH\SHC -Recurse

Link to comment
  • 0

Matt, have you made other adjustments than in https://www.citrix.com/blogs/2013/09/22/citrix-consolidated-list-of-antivirus-exclusions/ ? Can you share them with us?

Customer is running TM and performance is also really bad.Unfortunately he is using Worry free Business :(


Sure, specifically these are the changes I made. Everything in this article: https://success.trendmicro.com/solution/1095115-slow-login-on-citrix-environment-after-installing-officescan-osce


And I changed the Real-time scanning policy for the XenApp session hosts servers from "created/modified and retrieved" to "created/modified". Trend may have a hotfix for this issue, so it may be worth a call.

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...