Why App Readiness Is Breaking AVD - And What Microsoft Won’t Tell You
Black screens on Azure Virtual Desktop (AVD) are more common than you might think. Users get stuck, staring at nothing, blaming the platform and your support teams.
Table of Contents
In Summary - TL;DR
- AVD Black Screens Often Stem from the App Readiness Service, which clashes with FSLogix and multi-session host behaviour.
- Login Delays and Session Failures Are Linked to AppX Validation, especially during reboots or profile container mounting.
- Disabling App Readiness Causes Side Effects, including broken Store apps, Edge login issues, and Outlook auth failures.
- Targeted Registry Keys Can Resolve Performance Issues without disabling core functionality; use the provided PowerShell script.
- This Is a Common AVD Problem And Not Just You, and it’s quietly affecting performance in many Windows 11 virtual desktop environments.
Introduction
Black screens on Azure Virtual Desktop (AVD) are more common than you might think. Users get stuck, staring at nothing, blaming the platform and your support teams. You tweak FSLogix, reboot the host, check session limits but nothing sticks. The real problem might be something you’ve overlooked, a quiet Windows service causing chaos during login.
App Readiness is supposed to help with application compatibility and Windows stability. However, in AVD environments, it's become a surprising source of login delays, profile issues and more importantly, those dreaded black screens.
In this blog post, I'll break down what the App Readiness service actually does, why it behaves so badly in AVD, and most importantly how to fix it. We'll also touch on Microsoft's stance, and what practical steps you can take today to improve your users experience.
Ready to fix an AVD issue that Microsoft isn't talking about yet? Let's go! 📱
What the App Readiness Service Actually Does
The App Readiness service sounds harmless enough. It's a background Windows service designed to help prepare user profiles by validating and staging modern apps, especially Microsoft Store and AppX packages during the login process.
That's usually fine on a users' laptop, but on a shared, multi-session workspace with containerised profiles like AVD? It's a very different story.
App Readiness is Responsible For:
- Assessing application compatibility after Windows updates.
- Supporting the deployment of updates by prepping app environments.
- Validating and staging AppX packages - think Store apps.
- Contributing to the overall reliability of Windows - the irony.
In other words, it's trying to help. But it wasn't built with roaming profiles, non-persistent virtual desktops or FSLogix in mind.
How App Readiness Disrupts AVD
First of all, App Readiness isn't inherently broken, and for local machines, provides some level of benefit. However, it's poorly suited to the way Azure Virtual Desktop environments operate. The service is designed for single-user Windows devices, not multi-session, containerised setups; especially when using FSLogix.
Common Symptoms in Affected AVD Environments
- Login delays ranging from 30 seconds to over 30 minutes.
- Black screens during logon that eventually time out or freeze completely.
- Inconsistent availability of Microsoft Store apps.
- FSLogix containers that struggle to mount cleanly.
The root of the issue lies in how App Readiness interacts with FSLogix and the profile mounting process. During login, App Readiness will attempt to re-evaluate all AppX packages, sometimes for every user, every time. On sessions hosts that serve multiple users, or reboot nightly, this behaviour causes the dreaded black screen issue.
The Risks Of Disabling App Readiness
It's tempting to just disable the App Readiness service and move on. After all, if it is causing login delays, black screens and you have finally found this blog - turning it off should do the trick?
Unfortunately, it isn't necessarily that simple. Disabling the App Readiness service may stop the black screen behaviour in some cases, but it also introduces a range of reliability issues that can (quietly) undermine the stability of your environment.
Let's Look At What Can Break
- Microsoft Store and modern UWP (Universal Windows Platform) apps may stop working.
- Edge may fail to sign in correctly, especially during the first login process.
- Outlook and Office apps may behave unpredictably or fail to prompt for modern auth.
- Windows Updates may result in post-update issues (not that you should be patching hosts individually).
- Overall system reliability can become harder to guarantee to your customers and users.
The key issue is that App Readiness doesn't just stage applications. It helps Windows move between update states, validate app compatibility and ensures the user environment loads correctly. Turning it off, removes that state management process.
Want to know how to fix it, whilst retaining the benefits of this service? Read on!
Real-World Solutions That Actually Work
The goal isn't to kill the App Readiness service. It's to make it work in a way that compliments your AVD environments, and doesn't get in the way of your users.
After working through this issue across multiple environments, here are the configuration changes that have delivered the most consistent improvements.
Apply These Registry Keys To Your Golden Image - Free Download!
These keys adjust how long App Readiness waits, how login delays are handled, and how FSLogix cleans up after itself. Add them during the image build so you can be sure it's a consistent across session hosts.
| Registry Path | Key Name | Value |
|---|---|---|
| HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer | AppReadinessPreShellTimeoutMs | 7530 (DWORD) |
| HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System | FirstLogonTimeout | 30 (DWORD) |
| HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System | DelayedDesktopSwitchTimeout | 30 (DWORD) |
| HKLM:\SOFTWARE\FSLogix\Apps | CleanupInvalidSessions | 1 (DWORD) |
Lessons From The Field
This issue isn't hypothetical. Over the past couple of years, I've seen the App Readiness service cause login issues in several customer AVD environments. From black screen lasting 30 minutes, to profile logins that never complete.
In every case, these environments were:
- Using FSLogix for profile containerisation.
- Built on pooled, non-persistent session hosts.
- Experiencing issues on Windows 11 multi-session across multiple customers.
Sometimes, the problem only appeared in a small percentage of logins, other cases it was most users. The frustrating part was the inconsistency, and led myself and others to believe it could be anti-virus, office add-ins, you name it, we thought it!
Here's what we've consistently found since:
- Disabling the App Readiness service might appear to fix things temporarily, but can create long-term instability.
- Applying the registry keys to control timeouts and FSLogix session cleanup significantly reduced login delays and defeated the black screen issues for good.
This is a clear example of how services built for physical and personal Windows devices do not always translate well to multi-session virtual environments like AVD.
Final Thoughts - It's Not Just You
If App Readiness has left you chasing down black screens, slow logins or unpredictable user experiences, you are most certainly not alone!
The good news? There’s a fix. You don’t need to disable the service entirely. With the right registry adjustments, you can bring performance back in line without sacrificing reliability.
You’re not doing it wrong. You're just working around something that was never designed with AVD in mind.
Want to discuss how to optimise App Readiness in further detail? Look no further!
Comments ()