Windows 11 Black Screens Hit Virtual Desktops After Sign-In

Microsoft says recent Windows 11 updates can leave some devices on a black screen after sign-in, with the desktop never loading on its own. The company lists Windows 11 24H2, 25H2, and 26H1 and marks the fault mitigated while a lasting fix is still in the works.

The reports cluster on Azure Virtual Desktop hosts that use FSLogix for user profiles. A home PC can open Task Manager. A signed-in virtual session that never starts the shell is a different outage.

Virtual Desktop Hosts Are the Ones Going Dark

The Windows 11 24H2 health list now carries black screen or desktop loading issues after sign-in. Microsoft says it has received reports from some virtual desktop environments. The same write-up says the failure has been primarily observed on Azure Virtual Desktop hosts using FSLogix, and that it appears more often with some existing user profiles.

That is a farm problem wearing a client SKU label. The affected platform list names only Windows 11 client versions 26H1, 25H2, and 24H2. Server editions are listed as none. Windows 365 is not named here, and a separate September Remote Desktop Services outage was explicitly called out as not affecting Azure Virtual Desktop or Windows 365.

Windows 11 26H1 is also a poor stand-in for “every PC.” Microsoft describes 26H1 as a hardware-optimized release sold as a preinstall on select new devices, not as a feature update for machines already in the field. For enterprise images, it still points admins at 24H2 and 25H2. Those are the session-host builds that actually show up in AVD and Horizon catalogs.

AFFECTED CLIENT BUILDS

Later monthly packages can still trigger the same shell failure. FSLogix’s own known-issues note names the September 8 security update KB5124008 as the Windows package that leaves explorer.exe crashing as the shell starts. Microsoft’s dashboard language is broader: the August 27 preview and subsequent updates.

Microsoft Logged the Fault on September 24

The known issue opened on September 24, 2026, at 18:47 PT and was last updated that evening at 19:41 PT. Status is Mitigated. Microsoft has not named a shipping build that restores explorer.exe on its own, and it has not given a date.

Three signs are on the dashboard. A black screen appears after sign-in and the desktop session does not load automatically. Users may be unable to reach the desktop until that session is started by hand. The Application event log may record Windows Explorer crashes.

FSLogix documented the same crash a day earlier. Its known-issues page, updated September 23, 2026, lists the state as in progress for 2210 hotfix 4 (2.9.8884.27471) and later, which covers current agents in the field.

THE BLACK SCREEN CALENDAR

1. August 27, 2026: The non-security preview updates KB5120998 (24H2 and 25H2) and KB5120996 (26H1) ship and become the originating packages on the dashboard.
2. August 31, 2026: FSLogix 26.08, version 3.26.826.17182, ships as the current agent train. Horizon shops later split on whether that build cleared the dark logon.
3. September 8, 2026: The September security update KB5124008 lands on 24H2 and 25H2. It fixes two other desktop bugs from the August preview and does not close this explorer crash.
4. September 23, 2026: The FSLogix known-issues list is updated for a black screen during sign-in after KB5124008.
5. September 24, 2026: Windows release health opens the client known issue and marks it mitigated.

Horizon operators were already swapping notes in the second week of September, after catalog updates that carried KB5124008. Microsoft’s public entry arrived after those farms had spent days starting explorer.exe by hand.

How Do You Start Explorer on a Black AVD Session?

Microsoft’s first workaround is a manual launch of explorer.exe. Press Ctrl+Shift+Esc to open Task Manager, choose Run new task, type explorer.exe, and select OK. That is a session rescue. It does not change the host image, and it does not protect the next logon on a pooled clone.

On a physical PC the shortcut is ordinary. Inside a remote desktop, Ctrl+Shift+Esc can hit the client PC instead of the virtual machine. Operators on Omnissa’s Horizon board described sending Ctrl+Alt+Del into the session, opening Task Manager there, then running explorer.exe. Once the shell is up, some profiles then log on normally later on the same host, which makes a farm look randomly broken across a workday.

THE TWO OFFICIAL PATHS

• Manual shell: Open Task Manager, run explorer.exe as a new task, and recover that one signed-in session.
• Known Issue Rollback: Install the matching Group Policy package, set the policy, and restart every affected device so the bad change stays off until a later Windows update.
• Who it is for: KIR is written for enterprise-managed PCs. A personal device that is already on a black screen is pointed at Task Manager.

The rollback is the tool that actually belongs to a VDI shop, and it is not a one-click toggle. Microsoft says admins must install the package, then set the special policy under Computer Configuration, Administrative Templates, using the Group Policy name for that Windows version. Devices must be restarted before the setting takes effect. The policy disables the change that causes the issue until a fix ships in a future Windows update. Microsoft’s own primer on Known Issue Rollback for Windows devices is the mechanism those packages use.

Rollback Packages With Borrowed KB Numbers

Two MSI files are on the dashboard. Windows 11 24H2 and 25H2 share one. Windows 11 26H1 has its own. The filenames reuse KB numbers that already belong to September preview updates, including the optional packages that restore File History. An admin who searches only by KB can install the wrong artefact.

KIR FILES VERSUS PREVIEW UPDATES

The 24H2 and 25H2 rollback package is the file most AVD and Horizon images need. Its download name also mentions Windows Server 2025. The known issue still lists Server as none, so the filename is wider than the affected-platform table. The 26H1 Known Issue Rollback package is the matching MSI if a host is actually on that preinstall SKU.

Until the policy is installed, configured, and rebooted through the golden image, users keep authenticating into a session that has no shell. That is billable downtime for a virtual desktop fleet, and it is invisible on a status label that already reads mitigated.

The August Preview Also Wiped Wallpapers

KB5120998 was already a messy preview before the explorer crash was posted. Two other desktop faults from that August 27 package were opened and then closed with the September 8 security update KB5124008. This black screen kept travelling in later updates.

FROM THE SAME AUGUST PREVIEW

• Wallpaper reset: Desktop background settings failed to load and fell back to a solid black colour. Status is resolved in KB5124008, posted September 8, 2026, at 10:41 PT.
• Mouse customization: Custom cursors and cursor animations could revert on non-English Windows devices. Same originating preview, same September 8 fix.
• Explorer black screen: Same originating preview, still mitigated on September 24, with no named code fix.
• File History: A separate September 8 regression. Optional preview updates on September 22, KB5124010 for 24H2 and 25H2 and KB5124006 for 26H1, restore backups. That is not the KIR MSI that shares those KB numbers.

A further September mess, Remote Desktop Services hanging or dropping after KB5124008, was fixed by the out-of-band update KB5129195 on September 14, 2026. Microsoft says that RDS fault does not affect Windows 365 or Azure Virtual Desktop. Shops that applied the out-of-band package to Horizon gold images still reported black screens at logon, which matches that scope note.

Jokes about Windows quality filled the public thread after the dashboard entry. They treat a dark desktop as a consumer gag. The people who cannot open Start are the ones whose profile container is attached and whose shell never comes up.

Existing Profiles and a Coordinated Fix

Microsoft’s hedge about “some existing user profiles” is the line VDI operators already recognised. Horizon threads described new profiles sailing through and old FSLogix containers going black. One round of testing on FSLogix 26.08 looked clean, then other hosts on the same agent, and even a rollback to 26.01, still presented a black screen. A few admins rebuilt containers and copied data across. Others found that starting explorer once, then signing out, let later logons succeed on that profile.

That pattern is ugly on non-persistent clones. The next machine in the pool may be fine. The next may not. Helpdesk tickets look like user error. The Application log shows an explorer crash, which is the only hard artefact Microsoft and FSLogix both name.

After the installation of the September Windows update (KB5124008), users could experience a black screen during sign in. The black screen is a result of explorer.exe crashes during shell start up.

FSLogix known issues, Microsoft Learn

The same FSLogix page says the team plans to address it in a future release or a coordinated release with Windows. That wording sits next to Microsoft’s client note that explorer.exe crashes during shell start up are still in progress. Two product groups, one crash, no date.

Microsoft said it is working on a resolution and that it will be released in a future Windows update. Until that package is named, a VDI image either carries the KIR and a reboot, or it keeps handing users a signed-in black session and a request to start explorer.exe themselves.