Windows 11 FSLogix Black Screen: How to Fix Desktop Loading After Sign-In

A Windows 11 black screen after sign-in is now a documented problem in some virtual desktop environments, particularly Azure Virtual Desktop hosts using FSLogix. Microsoft says the issue can leave users with a black display, prevent the desktop session from loading automatically, and produce Windows Explorer crashes in the application event log. The practical fix depends on whether you are an individual user trying to recover one session or an administrator managing multiple Windows 11 machines. 

Why the Windows 11 FSLogix black screen is happening

Microsoft traces the current issue to the August 27, 2026 preview update, KB5120998, and subsequent updates on Windows 11 24H2, 25H2, and 26H1. The problem has been observed primarily on Azure Virtual Desktop hosts that use FSLogix, Microsoft's technology for managing and attaching user profiles in virtual desktop environments. Existing user profiles appear to be affected more frequently, which helps explain why the same Windows image can work for one account and fail for another.

The important distinction is that this is not simply the familiar desktop-wallpaper problem that also appeared in the September update cycle. In the current issue, Windows can accept the user's sign-in but fail to load the actual desktop session. Microsoft lists a black screen after sign-in, inability to access the desktop until the session is started manually, and Windows Explorer crashes in application event logs as the main symptoms. 

First check whether your Windows build matches the affected versions

Before changing drivers, deleting a profile, or rolling back Windows, check which version and build you are running. The documented issue affects Windows 11 24H2, 25H2, and 26H1, with the original problem associated with the August 27 preview update and later updates. You can check the version by pressing Windows + R, entering winver, and pressing Enter. If the affected machine is an Azure Virtual Desktop host using FSLogix and the symptoms appeared after the relevant updates, the Microsoft-documented issue becomes a much stronger explanation than a generic display failure. 

Start Explorer manually when the screen is already black

If Windows has accepted the sign-in but the desktop never appears, the quickest test is to start Windows Explorer manually. Explorer is the Windows process responsible for presenting the desktop, taskbar, Start menu, and much of the normal shell. Microsoft specifically lists manually launching explorer.exe as a temporary mitigation for the current issue. 

1. Press Ctrl + Shift + Esc to open Task Manager.
2. Select Run new task. If Task Manager opens in its compact view, select the option to show more details first.
3. Enter explorer.exe.
4. Select OK and wait for the desktop to load.

If the taskbar, Start menu, and desktop appear after launching Explorer, that is useful evidence that Windows itself completed the sign-in but the desktop shell did not start automatically. It is not a permanent repair, however. Microsoft describes this as a temporary mitigation, so repeating the command at every affected sign-in should not be treated as the final solution. 

Use the Known Issue Rollback on managed PCs

Organizations managing Windows through Group Policy have a broader mitigation called Known Issue Rollback, or KIR. KIR lets Microsoft disable the problematic change without requiring the organization to remove the entire Windows update. For the current black-screen issue, Microsoft provides separate rollback packages for Windows 11 26H1 and for Windows 11 24H2 and 25H2. 

For Windows 11 26H1, Microsoft lists the KB5124006 260924_20071 Known Issue Rollback Group Policy. For Windows 11 24H2 and 25H2, it lists KB5124010 260924_20021 Known Issue Rollback. The administrator needs to install and configure the appropriate Group Policy, after which affected devices must be restarted for the mitigation to take effect. 

The important limitation is that KIR is not the same as a permanent fix. Microsoft says the policy disables the change associated with the problem until a future Windows update provides a resolution. That makes it useful for managed fleets where repeatedly telling users to launch Explorer is impractical, but administrators should continue tracking Microsoft's release-health documentation rather than assuming the rollback is the final state. 

Do not uninstall the September security update just because Explorer crashes

The timing of this problem makes update removal an understandable first reaction, but it is not the safest default. Microsoft's documentation says the issue originated with the August preview update and subsequent updates, while the September security update also contains important security fixes. The current mitigation is specifically designed to address the problematic behavior without simply removing Windows security protections. 

This matters even more on business systems. Windows 11's September servicing cycle has already included fixes for several unrelated regressions, including a Remote Desktop Services problem and a Hyper-V Linux virtual-machine folder-sharing problem. Microsoft resolved those issues through the September 14 out-of-band update, KB5129195, rather than asking administrators to remain on an older security baseline.

Check Event Viewer if launching Explorer only hides the symptom

If Explorer brings the desktop back but the problem returns at the next sign-in, check the application logs before making more changes. Microsoft specifically identifies Windows Explorer crashes in application event logs as one of the symptoms associated with this issue. That evidence is more useful than simply recording that the screen was black because it can help an administrator distinguish this known problem from an unrelated profile, application, or graphics failure.

Open Event Viewer and inspect Windows Logs > Application around the time of the failed sign-in. Look for Explorer-related application errors and compare their timestamps with the affected user's login. If the machine is part of an Azure Virtual Desktop deployment, record the Windows version, OS build, FSLogix configuration, affected profile, and exact time of failure before changing the image. That gives an administrator a reproducible case instead of a vague report that a user "got a black screen."

Test with a second profile before rebuilding the machine

Microsoft says the issue appears to occur more frequently with some existing user profiles. That does not mean an affected profile is corrupt, so deleting it should not be the first response. Instead, an administrator can compare the behavior with a controlled test account or another known-good profile while leaving the original profile intact. If one profile repeatedly produces the failure while another loads normally on the same host, that comparison provides useful evidence for further investigation. 

Keep the test controlled. Record the host, Windows build, profile-management configuration, and update state before changing anything, then reproduce the sign-in problem under the same conditions. A successful test profile does not prove that the user's profile is damaged, but it can help separate a profile-specific problem from a host-wide Windows problem.

Know when this workaround does not apply

A black screen is not automatically the FSLogix issue described by Microsoft. The documented problem is primarily associated with virtual desktop environments, especially Azure Virtual Desktop hosts using FSLogix. A normal Windows 11 laptop or desktop that goes black immediately after sign-in can have a different cause, and forcing the KIR policy onto such a machine would not be an appropriate general repair. 

Likewise, the separate Windows 11 issue involving a black desktop background is already resolved by updates released September 8 and later. That problem changes the background to a solid black color while Windows continues loading the desktop; it is different from a session that never loads the desktop at all. Microsoft has also documented a separate black-screen scenario caused by running Sysprep under the Local System account, so deployment history matters when diagnosing enterprise images. 

What to do while Microsoft works on the permanent fix

As of September 24, 2026, Microsoft lists the FSLogix-related black-screen issue as Mitigated, not resolved. For an individual affected session, launching explorer.exe from Task Manager is the immediate workaround. For enterprise-managed Windows 11 24H2 and 25H2 systems, the KB5124010 KIR policy is the documented fleet-level mitigation, while Windows 11 26H1 has its corresponding KB5124006 policy. Microsoft says a permanent resolution will arrive through a future Windows update. 

The useful lesson is to treat the black screen as a diagnosis problem rather than immediately treating Windows itself as broken. If Explorer can restore the desktop, the timing matches the affected update, the machine is an AVD host using FSLogix, and the application log shows Explorer failures, you have several pieces of evidence pointing in the same direction. Keep those details with the support case or internal incident record, apply the documented mitigation appropriate to your environment, and revisit the Windows release-health status when the permanent update becomes available.