Forum Discussion
AppReadiness Service and Black Screen
The whole Appreadiness service and black screen issue has been floating around for a couple of years now, but it's now raised its head again in WVD, at least where we're using FSLogix.
We have two WVD setups, one with FSLogix and one with no profile solution.
On the FSLogix one we're consistently getting black screens at login (although Ctrl+Alt+End works and you can run, say, notepad from Task Manager) but it eventually comes to life after five minutes.
In the event viewer the following error is associated with each black screen:
"A timeout (30000 milliseconds) was reached while waiting for a transaction response from the AppReadiness service."
Standard multi-user Windows 10 enterprise from the markteplace with is 1903 (although Windows itself is offering 1909 as an upgrade which I'm guessing is WVD supported, but I've not seen anything confirming this).
Anyone else seen this or got a solution?
OffColour1972
Man 3 years later and the best solution is a powershell script to delete the app rep database that people have reported breaks the start menu with non-fslogix accounts ekkk. MS where are you with this issue come on.I'm running a mix of 2012 and 2016 server as RDS hosts in my own cloud and about a month ago started seeing this problem randomly across my various VM's. These systems have been in place for over a years before this with no issue.
We use fslogix 2.9.7838.44263 atm.
All of our systems have all available windows updates installed on them.
When this problem occurs it will happen on accounts that use Fslogix accounts and those that done (our internal admin group for example)
So far the only solution that is working for us is just rebooting the server when it happens.
Without understanding what the problem is exactly has what has been stopping me from implementing a task to reboot the server every night.
We have this issue too.
Windows Server 2019
6 load-balanced physical (non VM) RDS session host servers, issue occurs on all of them!
We are not using Azure or FSLogixProfile Disks are in use.
We have tried the mentioned reg changes in this thread it does not help.
Disabled AppReadiness system services stops the black screen logins BUT this has a knock-on that stops users being able to sign into Edge with their Microsoft account!Another knock-on of disabling appreadiness is Windows updates that requires a reboot also fail to install.
Anyone found a solution which doesn't involve disabling App Readiness?We have solved the problem.
It was a latency caused by the loading of the windows app base at each user connection.
Indeed, this database is loaded and read for each connection and its size increases which slows down the connection process (event viewer\Applications and Services Logs\Microsoft\Windows\AppReadiness\Admin)
You must therefore stop the service, delete the files located under %ProgramData%\Microsoft\Windows\AppRepository\StateRepository* and restart the service.
Be careful because the modification of the key of register will handicap the operation of the service and can in the long run make disfonctionnement largely Windows, the office suite, the maj Windows and cause problems to the user profiles.
https://msendpointmgr.com/2021/08/30/fslogix-slow-sign-in-fix-redux/- that link fixed our issue! > https://msendpointmgr.com/2021/08/30/fslogix-slow-sign-in-fix-redux/
PhilST530, thank you so much for taking the time to reply, much appreciated.
- Hello fellow black screeners, I see the issue still persists even that we are down to random 30-120 sec. delays. Many of you guys reports creating a support case with Microsoft - didn't anybody get to the root cause and a permanent fix for this?
OffColour1972 Basically I found the solution for the 20H2 users , just go to regedit , follow this directory > Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AppReadiness and set ALL of the values to 0 . This works for me 🙂
- I noticed the recent release of the AVD Collect Diagnostic script by MS Customer Support, has some settings for the '• Added check for various settings that are sometimes related to Black Screen logon scenarios' - it might be worth running and doing a diag check on your host - https://luke.geek.nz/powershell/avd-collect/
Thanks so much for this helpful post. It's September of 2021 now, but this issue must be a persistent one. A couple of weeks ago, our family computer began to exhibit this same issue as described here and confirmed by many others. We have six user accounts on our family computer. Upon login of any user account (except my youngest daughter interestingly enough), it would go to a black screen for five to eight minutes and just sit there. I could launch Task Manager and manually run Windows explorer, although it did nothing. I thought perhaps explorer was crashing upon logon. The only remedy was to wait until whatever background process completed. At which point the desktop would pop up as though nothing was wrong at all!
I originally suspected my expired Anti-Virus, and removed it completely, but that didn't resolve it. Installation of a new AntiVirus application (ESET) and a full system scan revealed nothing, nor changed anything. Removal of several other applications on the suspect list likewise did nothing.
I was definitely at a loss. So thank you for posting this! I also saw similar posts on other forums scattered across the Internet as far back as 2018. (it's all about figuring out the right search terms to use when searching)
FYI: the moment I disabled the AppReadiness Service, logon was instantaneous. No more black screen on any account. I was concerned that this disabled important Windows functionality, but so far nothing appears to be failing to work. And performance appears to be unaffected... in fact, things run faster.
According to Microsoft support, "App Readiness gets apps ready for use the first time a user signs in to this PC and when adding new apps."
So perhaps I will need to re-enable it for running updates or installing other applications... I'll see what the impact is with it disabled for a while.
So, starting yesterday, this issue has returned on a daily basis. It doesn't make it 24 hours before the issue starts again. I don't have a busy server, max 15 users at a time with only 3 using full desktop, so it shouldn't be happening this frequently. Restarting the AppReadiness service just causes more problems and the only way to resolve it is to reboot which means those who are working have to stop, making matters worse.
I've tired to re-open my case with MS as it's affecting or entire Finance team just as Payroll starts!
Hi Lee, since applying the updates MS advised I havent seen this issue on 3 separate deployments at worst they may get a 5-10 second black screen but that is fine as it carries on after that, I would recommend logging with Microsoft, alternatively you could update these to one of the VM's to 20H2 and monitor if any report issues on that if not migrate all to that. Also what HDD's are you running on your WVD's?
StevenR , The server is all patched, has the registry keys added and the latest FSLogix version installed too, it was fine until yesterday when this started again with no changes applied and rebooting cleared it for about 5 active hours. I only have the one VM to keep the costs down but I'm going to go with having two and shutting down one at a time in future. With only 5 or 6 users active at a time it never strains and works well, except for this particular issue. I am looking to build a new pool from scratch on 20H2 to ensure nothing came through the original image. I'll report back once that's built.
Thanks
Lee
OffColour1972 This video has the solution for that pain..................
https://www.youtube.com/watch?v=kTf6nF4Vnus&t=32s
- There has already been a windows update to resolve this.
Interestingly enough, we didn't start to experience this blank black screen issue until AFTER we installed the Sept 2020 cumulative which, as you and their docs point out, was supposed to FIX this issue:
- Addresses an issue that displays a black screen to Windows Virtual Desktop (WVD) users when they attempt to sign in.
https://support.microsoft.com/en-us/help/4571744/windows-10-update-kb4571744
AND, even though the update was supposed to make it so you don't need those "30 second" regkeys in place, we haven't seen the blank black screen issue since we put them in place. So pretty sure this is a related AppReadiness blank black screen issue, just perhaps not the same one that was supposedly fixed in the update...
we were asked to put the following reg keys in place just this past Fri night (20201016) as we were experiencing this AppReadiness issue randomly in our Prod WVD env:
As a workaround, please set the below registry for the App Readiness preshell task and first logon’s timeout window to 30s to avoid the black screen for the first user’s logon.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AppReadinessPreShellTimeoutMs
Data Type: DWORD
Value: 0x7530 --> 30000ms = 30s
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FirstLogonTimeout
Data Type: DWORD
Value: 0x1e -> 30s
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DelayedDesktopSwitchTimeout
Data Type: WDORD
Value: 0x1e -> 30s
Here's the explanation:
With the regkeys we do not wait on AppReadiness to load the Desktop Shell. The workaround should help to not run in Black Screen caused by the AppReadiness.
We did fixed the Black Screen issue with the KB4571744 in September 3rd. But may we hitting here different cause.
The best is to prepare the Windows 10 Client for Full Dump and create a dump after waiting 5 Minutes in black screen. This will help to go deeper in the analysis of the cause and problem resolution.
https://support.microsoft.com/en-us/help/4571744
We are not sure if this has helped or not yet as it is the first day these reg keys are in place and we'll have a bunch of people back in WVD, but I guess it kind of makes sense as we're now limiting the amount of time the AppReadiness service will run (30 secs) before allowing the session logon to continue, as far as I can tell anyway...
Jason Fritz Hi Jason,
I saw this post, and was wondering about adding these four keys:
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\AppReadinessPreShellTimeoutMs
- Data Type: DWORD
- Value: 0x7530 --> 30000ms = 30s
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\FirstLogonTimeout
- Data Type: DWORD
- Value: 0x1e --> 30s
- HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\DelayedDesktopSwitchTimeout
- Data Type: DWORD
- Value: 0x1e --> 30s
- HKLM\Software\FSLogix\apps\CleanupInvalidSessions
- Data Type: DWORD
- Value: 1
After making these changes, it seems like the login time is increased. Some users are also seeing a black screen for 10-20 seconds on all of their logins... Should we knock the timeout down to 15/20/25 seconds instead? Is there a problem with doing so?
For the record, we are on Windows 10 21H1 and are still intermittently encountering this issue in our environment with Horizon View.
Jason Fritz Thanks for these, I've applied them so that the we don't get stuck at the black screen, however I've found that the App Readiness service still causes other problems.
For our users they still have issues with anything requiring Modern Authentication to O365/Azure and Outlook stops connecting. I also have a case with MS but I can't get any info on the real fix and I also ended up discovering the Windows Search bug and another issue with FSLogix not correctly disconnecting VHD files correctly.
Lee_E Hi I wont take credit for this as I was handed this by MS
Also please create the following Reg Key on all session hosts and set Value to " 1 " after you upgrade to FSLogix 2009:
CleanupInvalidSessions
SET IN: HKLM\Software\FSLogix\apps\CleanupInvalidSessions
Available in FSLogix release 2009 or later
Type: DWORD
Default Value 1
At times a Windows Session may suffer an inelegant termination, in these cases FSLogix is not provided an appropriate event to trigger the dismount of the VHD(x) file for Profile Container and Office Container. By setting CleanupInvalidSessions to 1, additional FSLogix logic is triggered to make this scenario less likely. Setting CleanupInvalidSessions will cause the functionality to be utilized for both Profile Container and Office Container. KNOWN ISSUE: at this time CleanupInvalidSessions should not be used in conjunction with Cloud Cache when concurrent sessions (e.g utilizing ProfileType/VHDAccessMode) are in use.
Okay, as close as I can get to a solution. The other attempts helped but this is the solution so far...
In the event viewer under administrative events you will see ERROR relating to either App Readiness or App-Model Runtime both pointing to something like... "8wekyb3d8bbwe" saying that is corrupt or install failed.
You will also see the profile it is attempting to apply it too such as...
S-1-5-21-527237240-2025429265-725345543-1124
Go to the following key and confirm the name of the user with the issue, to be fair its probably all users.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-527237240-2025429265-725345543-1124
Next, go to the following key
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore
You will see entries relating to the above... "8wekyb3d8bbwe" make a backup and then delete all entries
Next, go to the following key
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\S-1-5-21-527237240-2025429265-725345543-1124 make a backup and delete the entry or all users if effecting everyone
You can then login and you will be on your desktop in around 10 seconds, I cant get it lower than 10 seconds at present. Everything continues to work as expected without any issues.
I have applied the above to a few machines now and it is the only thing that works at present!
OffColour1972 Using Windows 10, Version 2004, Multi-Session, WVD, FSlogix, and Azure files... all users started getting this after a few weeks use of WVD. True, if I disable app readiness service and reboot the login is quick and works as expected. However, Outlook and Office issues start arising and it has to be enabled again. All updates are installed but no fix found at present. Anyone else found a fix?
Sponge405 Can you say soemthing about the Outlook and Office issues you had after disabling AppReadiness? We also want to disable the service as users are unable to work while it is enabled. We've had this problem since Windows updates from July. We have noticed that the Settings button is unresponsive when AppReadiness is disabled
MatthewHurley Basically, Outlook kept asking for the password even though it was entered and correct and wouldn't update. Our issues maybe somehow linked to MFA since we use it throughout. The solution I found earlier only works if you script it every time you login otherwise the login creeps back up and you end up waiting again. Also, by removing the reg keys you end up removing downloaded apps from the store or causing other issues.
Sponge405 We reboot our VMs daily to save cost and still have the issue. But, since we know "App Readiness" is part of the problem. I ran a performance test on a VM and rebooted. The test linked Skype to using a lot of CPU and time on loading, even though we don't use it or even login to it. I downloaded Autoruns and stopped One Drive (since we don't use or login to that either) and Skype from loading at start up and from loading browser extensions just to be sure. I then rebooted the VM and the desktop appeared after a black screen for approx. 10 seconds rather than 1-3 minutes. I am not sure why this would affect app readiness unless it skips trying to configure registry keys etc. on start up for one drive and skype. Now I need to try and implement on mass.
