By David, , updated
A black screen on Azure Virtual Desktop (AVD) almost always means the connection worked but the user's Windows sign-in on the session host hasn't finished: the profile is still attaching, Group Policy or startup apps are still running, or the Windows shell failed to start. Find out whether it clears after a few minutes or never clears, and whether it hits one user, one host or everyone, and you'll know which of the causes below you're dealing with.
The short version: a black screen that clears by itself is a slow sign-in, so work through profile attach, Group Policy and startup apps. A black screen that never clears is a shell or profile failure: check the FSLogix log, then the host's Application log for AppX and AppReadiness errors. If only one device is affected, test the same user from the web client to rule out the client.
First, narrow it down
| Pattern | Most likely cause | Go to |
|---|---|---|
| Black for 30 seconds to a few minutes, then the desktop appears | Slow sign-in: profile attach, Group Policy, logon scripts, startup apps | Slow sign-in |
| Black until the user gives up, on any host | Profile container failing or locked | Profile problems |
| Black on one host, fine on others | That host: shell, AppX or a stuck service | Host-level problems |
| Black on all hosts from one image version | Something in the image or a recent update | Image and update problems |
| Black from one device, fine from another | The client device or its display settings | Client problems |
| Black on reconnect to a disconnected session | The existing session is hung | Log the session off |
Get the user's name, the time, the host and the device they connected from. With those four facts the rest is quick.
Slow sign-in: black screen that clears
Most black screens on AVD are a sign-in that takes too long. During that time the user sees black, and many give up and reconnect, which makes it worse. The usual causes:
- Profile attach. FSLogix has to find, lock and mount the user's VHDX on the file share. Slow or distant storage, a large container or a busy share all add seconds.
- Group Policy and logon scripts. Synchronous policy processing and scripts that map drives or install software run before the desktop appears.
- Startup apps. Everything in the Run keys and the startup folder starts at once on every sign-in, on a host shared with other users.
- First sign-in on a host. First-time profile setup and AppX provisioning take longer than a normal sign-in.
Why AVD logons are slow works through each of these with how to measure it.
Profile problems: black screen that never clears
If the FSLogix container can't attach, the user may get a temporary profile, an error, or a black screen that never resolves. Read the user's last entries in C:\ProgramData\FSLogix\Logs\Profile on the host they landed on. The common causes:
- The container is locked by another session that didn't sign out cleanly.
- The share or the container is full.
- The host can't reach the share, or the user lacks permission on it.
FSLogix troubleshooting decodes the log and covers each fix.
Host-level problems: the shell doesn't start
When one host shows black screens and others don't, look at that host's Application log at the time of the sign-in for errors from AppX deployment, AppReadiness or Explorer.
Microsoft has documented black screens at AVD sign-in caused by the AppReadiness service waiting on COM objects, and by an AppX service deadlock that stopped the shell starting (Azure Virtual Desktop sign-in screen is blank). Those were fixed in Windows updates, and the article is archived, but its lessons still apply: keep hosts on current updates, and treat a host that shows black screens after an update as an image problem, not a user problem. Microsoft listed registry timeouts for the AppReadiness pre-shell task as a workaround, and was explicit that they aren't a long-term fix.
On a pooled host, the fastest fix is usually to drain the host and replace it from the image. If replacements show the same problem, the image is the cause.
Image and update problems
If every host built from one image version shows black screens, compare that version with the last good one: a Windows cumulative update, a new agent or a changed startup app. Roll the pool back to the last good image version while you investigate.
Client problems
If the same user gets a desktop from Windows App in a web browser but black from their PC, the problem is on their device. Update Windows App, and check the display configuration they connect with, such as several monitors or an unusual scaling setting. Microsoft's basic Windows App troubleshooting starts the same way: latest version, then the web client (Basic troubleshooting for Windows App).
Reconnecting to a hung session
If the user had a disconnected session and gets black on reconnect, the session itself may be hung. Log the session off from the admin side and let them sign in fresh.
A black screen is a sign-in that hasn't finished. Measure where the time goes, profile, policy or shell, before changing anything on the host.
Where Atlas AVD helps
- Find the session fast. The Users page lists every session with its host pool, session host, state and last latency, with Shadow, Send message, Disconnect and Log off on each, so a hung session can be logged off without RDP to the host. Opening a user shows connection info, session details and their FSLogix profile.
- Fix the profile from the console. FSLogix Management offers Reset Profile, Detach Container and Mark for Rebuild, and warns when a file share reaches 85% capacity.
- Read the host's events without RDP. On hosts with Atlas Reach, the per-device Event Viewer shows the host's live event log, and Services shows what's stopped. Reach is free on AVD session hosts in synced host pools.
- Replace the host. Drain & Reclaim or a Re-Image builds a fresh host from your image. To hold a pool on the last good image while you investigate, pin it to that version and re-image.
- Slow sign-ins alerted. Alert rules cover slow logons and slow FSLogix attach, delivered to Teams, Slack or a signed webhook.
That's the real Atlas AVD console in our demo environment; the users and sessions are sample data.
FAQ
Why do I get a black screen when connecting to Azure Virtual Desktop?
Usually because the sign-in on the session host hasn't finished: the FSLogix profile is still attaching, Group Policy or startup apps are still running, or the Windows shell failed to start.
How long should an AVD black screen last?
A few seconds at most. A black screen that lasts a minute or more is a slow sign-in worth investigating, and one that never clears is a profile or shell failure.
Can FSLogix cause a black screen?
Yes. A locked, full or unreachable profile container can leave the user on a black screen or a temporary profile. Check the FSLogix profile log on the host.
Should I change the AppReadiness registry timeouts?
Microsoft listed them as a workaround for older Windows builds, not a long-term fix. Keep hosts updated first, and only test registry changes on a single host with a backup.
Why does only one user get a black screen?
Look at that user's profile container first, then their client device. Test them from the web client and on a different host.
Is a black screen the same as a connection error?
No. A black screen means the connection succeeded and the sign-in didn't finish. For errors before the desktop appears, see AVD connection errors, and for unhealthy hosts, session host needs assistance.
Last updated 9 November 2026. Microsoft details are drawn from Microsoft Learn as of November 2026: the archived Azure Virtual Desktop sign-in screen is blank and Basic troubleshooting for Windows App. Black screens have many causes and Windows updates change them, so test each change on a single host first.