AppReadiness Service and Black Screen

[OffColour1972]

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?

[#2]

@MatthewHurley Over the past month there have been two patches pushed in the cumulative updates addressing the Black Screen issue.  Most likely those will be the fix.  Crossing our fingers.  We are in production and have not seen it for the past 3 days.

[#3]

@Robert_Greenlee 

Hi,  I have just deployed wvd a month ago and was working fine up untill yesterday and now I am getting increasing black screens. What were the updates that you are referring to. my wvd is win 10 multi.

I have deployed a nigh on identical one a week earlier than this one and they are not seeing these issues. the only main difference is the problematic one users log in/out all day while the other they log in do 8 hrs and servers shutdown at night and same again the next.

[#4]

Our work Around was to set the AppReadiness service to Automatic. The default in Manual and we reboot 2 times a day.   we see 50-60 users a day.  Put a case in with Microsoft. We did.  @StevenR 

[#5]

So to resolve the issue you reboot twice a day, or are you just saying due to user levels you tend to see vm’s rebooting multiple times a day. I currently use a script to shutdown vms with no logged on users leaving an amount of available seats. Is this the same as your environment.

[#6]

@OffColour1972 

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

[#7]

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

[#8]

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

[#9]

@Robert_Greenlee It's been a few weeks now and we haven't had this issue since installing the updates mentioned

[#10]

@StevenR Thanks, I got passed this same thing with the public preview of the latest FSLogix installer yesterday from MS.  I installed this morning and will see how it all goes for the next few days.

Great to see they are actively working on resolving these issues.

[#11]

@OffColour1972 This video has the solution for that pain..................

https://www.youtube.com/watch?v=kTf6nF4Vnus&t=32s

[#12]

There has already been a windows update to resolve this.

[#13]

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

[#14]

I'd be interested to know how your still getting on in a week or two if thats ok?

I have another WVD environment that has all the same updates as the other WVD environments and its getting a black screen that last for 10-20seconds max (awaiting confirmation) which is far better than the stuck on black indefinitely.

[#15]

@StevenRCoincidentally - I, personally, ran into the blank black screen last night while trying to get into WVD for something else altogether.  It lasted between 5 and 10 minutes, not exactly sure as I was doing other stuff, but went back to the session and it was eventually fully logged in.  But the regkeys and/or patch update did not seem to play into this as A) well it happened so the update obviously did not have any effect on the issue we're experiencing and B) it lasted WAY longer than 30 seconds, so the regkeys made zero difference as well. 

But this still seems related to AppReadiness "hanging" since, I didn't do anything at all - my session eventually just "came to" and I was fully in - shell (explorer) loaded and I had a desktop, not just a blank black screen anymore.  While stuck in the blank black screen state, you can hotkey to open task mgr and run apps, to some degree FYI - but even launching explorer.exe will to get you to a shell - at least it seems until AppReadiness gives up ad finally lets you in completely.

I have not had a chance to dig in yet and research myself, but I did upload the FSLogix support tool output to the secure file exchange location for the case as Microsoft *thinks* this may be even loosely related to FSLogix, but I'm leaning more towards a new, unknown/undocumented bug in AppReadiness - but what do I know!  All I know is this is extremely random and intermittent, so obviously difficult to troubleshoot and figure out root cause, so who knows if we ever will...

[#16]

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!

[#17]

@Lee_E 

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?

[#18]

@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

[#19]

Has anybody resolved this yet?  It's March 4th, 2021.

We have a case open with Microsoft but after two weeks we're no closer to a solution.

Windows EVD 20H2 19042.804   (fully patched)

FSLogix 2.9.7654.46150

Black screen for 30-90 seconds at logon. 

Registry keys from here do not help, and some logons end up with a broken start menu and inability to authenticate to Office365

https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-desktop/windows-virtual-desktop-blank-sc...

[#20]

Hi @aaronmountford ,

Sorry to here that, if its happening every time it might be worth building another VM to add to the mix put it on win 10 2004 and use GPO/computer/policy/administrative/windows updates/(something) for business and set it to hold the version at 2004 while MS resolve the one that doesn't work, I am running the same versions as yourself and I am not seeing this issue. also how many users do you have on what size VM?

[#21]

Thanks @StevenR 

We actually have 4 in a pool (well currently 3 as one is out for troubleshooting).  Two are built from an image mid last year (20h1-evd-o365pp), and two from an image from late last year (20h2-evd).  Both receive updates as per our security policy.   The sizes are all Standard D4s v3.

We don't have a heavy load on them, peak usage on each would probably be 15-20 users but that's a guess.  Could be less.  Even with just 1 user we get this issue, so it's definitely not performance based.

The one thing we have determined is that disabling the FSLogix services removes the issue completely, although it introduces a bigger problem - group policy fails to apply if the FSLogix services are disabled.

For what it's worth we're using FSLogix with cloud-cache only (Azure Files).