Forum Discussion
Azure Virtual Desktop - Black Screens on logins - What we've tried so far
TLDR - Azure Virtual Desktop Black Screens. Could be 2 Min long, could be much longer. Tried removing stuck profiles, spun up all new VMs to see if that would fix it, finally disabled an application service that was polluting the Event logs constantly with appcrashes. Hoping that maybe the event logs weren't able to keep up so we had a black screen while events caught up. Grasping at straws.
We started getting reports of black screens when users login to one of our AVD Host Pools. Our users are using FSLogix for profiles, but we've also seen the issue when logging via RDP with a local admin account. We tested and saw similar results where you login, FSLogix Prompt goes by, then to Preparing Windows, then black screen.
- In a normal login, this black screen will last 10-20 seconds before desktop comes available and user can begin their session.
- With this issue, we were seeing black screens that just stayed there until you forced a logout of your account.
We saw some profile issues with the VMs in the pool appearing to be stuck on a VM when it should be removed upon logoff with FSLogix and we saw some stuck local_username FSLogix profiles still in the users folder. Instead of finding the needle in a haystack, we spun up a new group of VMs and put the others in drain mode / excluded.
With the new VMs, logins from RD Client were working fine yesterday afternoon, evening and this AM. But later in the morning, we saw some issues with users getting a black screen lasting 90 sec - 2 min before desktop loaded in. I had it happen to me when logging in, but it seemed to go away once I tried a couple more times. I even directly RDPd into the host that I had the 2 min black screen for me and was able to get in quickly. So issue appears to still be showing, but not as bad.
We looked in event logs and saw that one particular application - the Aspen Multicase Web service was polluting the service event logs with appcrash errors every few seconds. So we've disabled that application service on all the VMs in the pool and logins have been normal since. We read event logs that were event 4625 (failed login) but the event said event logs couldn't keep up and needed to stop duplicate events...so we were thinking that this service was constantly writing to event logs, could the slow logins happen when the service is trying to run, failing and writing to event logs. the logs wouldn't be able to write the login info.
But every other change we made things seem fine afterward for a while, but then the black screen will come back for at least 90sec - 2 min.
Any suggestions on things we can try / look at that could be causing this?
281 Replies
No black screens today, such a relief. But Outlook/Onedrive issues for maybe 5 users out of 50. I’m not sure what fixes it, seems to be different things fix different users. No single fix has worked. I’m at the stage that I might re-build their windows profiles as it’s the same handful of people experiencing it. Not everyone. I’d like to get this resolved without having to rebuild the hosts from an image as we’ve a lot of custom software and fixes which we’ll have to re-install, god knows if I have them all documented🫣
- Installing KB5045594 seems to have resolved the black screen issue for most of my host pools.
However for one host pool today, users had Outlook and OneDrive connection issues even after installing KB5045594 (although no more black screen). Installed latest version of FSlogix but didn't help. I ended up uninstalling KB5046400 and KB5044029 and after a reboot no one had Outlook or OneDrive connection issues anymore. Can't say for sure which of those KB's was causing the issue, maybe host just needed another reboot?! but that's another host pool working again.. until MS breaks it again.- Did the same with one affected user and host. After installing KB5045594, reboot, then remove KB5044029 & KB5046400, reboot, the black screen was gone and Outlook, Onedrive and Teams started immediately. Looks good for now and will do this on all hosts in the host pool and then we will see next week if the workaround will do good.
I believe you can also repair using the Powershell Reset-AppxPackage commands
Get-AppxPackage -Name "Appname" | Reset-AppxPackage
- this thread has been quietttttt today. Any reports from anyone who installed the CU?
- We have left the KIR in place and installed the preview KB. We still had one instance of outlook and one instance of black screen. This is over 20 host servers in one pool.
- Preview update installed while the KIR is in place? That is good to know
JPlendo
does anyone know what should be done with the KIR before updating to KB5045594?- I tested the standard October update with the KIR applied and the update would not apply until I rolled back the KIR and rebooted. I have not verified this with the newly supplied KB but I am rolling back and rebooting before applying
JPlendo Windows 10 users, have any of you installed KB5045594 that was released a week or so ago? I know in previous posts in this thread some were told that KB would fix the black screen issue for Windows 10 machines.
Our issue is with Windows 11, but curious if anyone in Win 10 land tried that new patch?
- Yeah, there are posts in this thread that mention that KB being released by MS to fix the Windows 10 Black Screen. Check above in the pages of the thread, it comes up a couple times. Will it fix the issue? I have no idea as we are on Windows 11, but I wanted to know if anyone saw it / tried to install it to see if it helped?
https://www.neowin.net/news/windows-10-22h2-release-preview-and-beta-build-190455070-kb5045594-is-now-available/
Question for those who have blocked updates on AVD. How have you accomplished this?
My org deploys AVD session hosts either through the Azure portal hostPool wizard, or via ARM templates with New-AzResourceGroupDeployment.
When we deploy a session host, it has the enableAutomaticUpdates property set to true, and patchMode set to automaticbyOS. This means that Windows installs Auotmaitc Updates, even if it is disabled via a GPO. This is causing us some pain in relation to the AVD blackscreen issue and hosts unexpectedly installing updates.
- To address the black screen issue in Azure Virtual Desktop, my stable approach for now is to roll back to the previous update, specifically KB5039211, as the next update has not yet been released. Additionally, it is advisable to test any Known Issue Rollback (KIR) on a test host pool before deploying it in a production environment to avoid potential issues with other applications. For short-term stability, consider rebuilding environments from a Golden Image that does not include the problematic patch and disabling the Windows Update service temporarily and create a rings for updates. Always ensure to test all updates and patches in a controlled environment before rolling them out broadly.
- We have the same issues and no fix yet. So far, when a user has 365 app issues we do this:
1. %LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
remove the content of this folder. if the folder does not exist: create it.
2. empty all saved credentials in the credential manager.
3: log off and try to logon again, wait long enough on the black screen, keep trying - It lives in Windows 11 as well - we tried. I guess not enough companies use the virtual desktop environment to make this a priority fix. Our company is transitioning to a different ERP system by October 2025 that will no longer require the use of these Microsoft services. Maybe it will be fixed sometime before then?
- Do you know the KB in windows 11?
Is anyone dealing with Windows 11? We have black screen issues with Windows 11. Have been working with MS Support for 3 weeks now and support gets worse every day it seems. Every new engineer we get assigned acts like its a new case, doesnt see anything else that was done and doesnt know what logs / dumps we have provided.
So far, we have given the following and still we have no answer and they want more logs
- LiveDump
- Complete Memory Dump
- Explorer / SIHOST process Dumps
- Full ProcMon Boot Logging Trace
- TSS Logs
- CM Diag Logs
- WPR Trace
Yet a new engineer comes on every time seemingly wanting more logs. When we ask what the deal is with the logs we gave, we dont get straight answers. Angry does not convey how we feel right now. Their support could not possibly be any worse at this point and I'm fed up with it. Even our Tech Account Manager tells us they are gonna do something for us, then doesnt. When questioned they say they are getting the new engineer up to speed, then we dont heart from them for 4 more hours. Its a joke.
Anyway, first we were told
thread is waiting for Host Activity Manager (HAM) to Terminate a snapshot of all hosts in the specified package(Here is only one application package in the queue). Following are the details about the package.
In all cases we worked so far, the application to which HAM is waiting on is Microsoft.AAD.BrokerPlugin.
0: kd> !mex.t ffffcc0573383080
Process Thread CID UserTime KernelTime ContextSwitches Wait Reason Time State
svchost.exe (DcomLaunch) (ffffcc05654170c0) ffffcc0573383080 5b8.9c18 188ms 359ms 4600 WrAlertByThreadId 3m:56.156 Waiting
Hence it is not clear as what happened to the worker thread. To understand that we need more details.
1. Process dump of sihost.exe from the affected session.
2. Process dump of explorer.exe from the affected session.
We are tracking this issue in a Bug record internally. Application event log has following errors logged (this is consistent on all environments where this issue was observed)
Events ID 10 is present where the same issue is observed. Looks like this event is related to the black screen issue the users are experiencing. We are investigating this further.We provided more dumps and a COMPLETE memory dump only to be told then from the dump that out issue was
explorer isnt loading as its trying to load the shell process but cannot as all CPUs are tied up with other processes.
So they are completely ignoring, or just never even seeing the previous notes about the worker processes and AAD BrokerPlugin as the issue. Or they have no clue and are just stringing us along until they have something valid.
We are getting no where with this and the support level we are getting is pathetic.
Unfortunately the KIR caused us more problems then it fixed. When we applied it we saw an improvement in the black screen at log in, but it broke 365 apps for half our users. The black screen was affecting roughly 5% of our user base and moving them to a new sever always seemed to fix it, so we rolled back to before applying the KIR because 5% of our users calling in is much better than 50%. We have also been working with Microsoft but not making any progress. It would be really nice if they would admit there is an issue rather than referring us to a KIR that does not work. We have multiple host pools that support both full desktop and app delivery. All of the host pools are equally affected but for the host pools that have App Delivery what the users see is a never ending connecting screen and they end up with a disconnected session on the host that we have to clear from the admin panel before they can log in.
GlenW1530 we have had this issue for weeks, started with black screens, fixed that with the KIR and then 80% of users getting Office 365 auth issues and no access to outlook etc. The only thing that helped us was going from 16 users per host to 8 per host with 1 cpu per user i.e 8 core machine for 8 users. Someone else mentioned it here and it seems over 10 users appx starts to fail and cause this issue. We also disproved anything to do with fslogix as this happens even when excluded from fslogix.
Also autostart all vm's before users come online to ensure they are "warmed up", spread the logins with "Breadth First", and look out for the AADbroker failing in event viewer as if this breaks, it breaks for all users on the host.
michealscott Same experience - applying the KIR decreases the black screen on logon but increases M365 auth failures, correlated with Microsoft.AAD.Brokerplugin crash.
Just a heads up, after going through the exact same issue within our AVD Environments we have narrowed the issue down to the Sept 14th Security Update. This patch has cause merry havoc with the AppReadiness Service and how it interacts with FSLogix. I had a 2 hour conversation with MS on Friday concerning this issue, where at first they stated there was no issues with their patch.
For now I have found the easiest solution was to rebuild my environments from a Golden Image Which did not include the September Patch, and manually update to August 2024 Patch then disable the Windows Update service.
After we had done this, we have once again seen stability within our AVD Environment, and have decided to implement a Dev Environment to test all future patches MS Decides to foist on us before rolling it out to general production.
Rebuilding the hosts from a W10 21H2 image from MS, uninstalling any update released after July 2024 and disabling Windows Update to prevent new updates to be installed is exactly what we did on our Windows 10 Multiuser AVD hosts to resolve the issue 100%. Implementing the KIR and changing the registry keys mentioned in https://techcommunity.microsoft.com/t5/azure-virtual-desktop/appreadiness-service-and-black-screen/m-p/1795520/highlight/true#M3241 did not resolve the issue, it only caused the issue to occur less often.
Everything works, including Outlook, OneDrive and Teams (new version) and no more black screens at sign in at all.
