Windows 11 black screen after sign-in fix: AVD/FSLogix patch

Microsoft has resolved a known issue that caused black screens, desktop loading failures, and Explorer crashes right after sign-in on Windows 11. The company confirmed the Windows 11 black screen after sign-in fix is included in Windows updates released on October 13, 2026 and later, naming KB5127648 as an example, and said the fix shipped as part of October's Patch Tuesday cumulative updates (BleepingComputer). Microsoft is recommending that affected devices install the latest update rather than keep relying on the workarounds it issued earlier (Microsoft Support).

Microsoft's cited notice focuses specifically on Azure Virtual Desktop hosts running FSLogix, software that speeds up user-profile loading in virtual desktop environments, and says the problem has been primarily observed there rather than across Windows 11 PCs broadly (Microsoft Support). A separate Microsoft Q&A report describes a standalone-PC case with a similar-looking Explorer crash tied to an Intel graphics component, which is a different scenario worth keeping distinct from the AVD issue covered here (Microsoft Q&A).

What is the Windows 11 black screen after sign-in fix?

Microsoft's release-health dashboard lists the issue as resolved in Windows updates released on or after October 13, 2026, naming KB5127648 as an example of a qualifying update (Microsoft Support). The company's guidance states that installing an update from that date or later means no workaround is needed for this specific issue (BleepingComputer).

Before the October fix, the bug tracked across several specific updates. Devices running KB5120996 on Windows 11 26H1, KB5120998 on 24H2 and 25H2, and that cycle's Patch Tuesday builds KB5124008 and KB5122880 were all affected while a permanent fix was pending (BleepingComputer). Microsoft names KB5127648 as an example of the resolving update rather than providing a complete cross-version list, so administrators should verify the applicable update for their specific Windows 11 release instead of assuming any October patch automatically qualifies.

Who is affected by the Windows 11 FSLogix black screen issue?

Affected sessions show a consistent pattern: a black screen appears immediately after sign-in, the Windows 11 desktop fails to load automatically even though sign-in succeeded, and Application event logs record Explorer crashes (Microsoft Support). Some users could only reach their desktop by starting the session manually, which is the behavior Microsoft describes when it talks about Windows 11 desktop not loading after sign-in on affected hosts.

Microsoft's notice specifically identifies Azure Virtual Desktop hosts using FSLogix as the environment where this has been primarily observed (Microsoft Support). In a report published three weeks ago, consultant Justin Verstijnen wrote that the bug spans Windows 11 versions 24H2, 25H2, and 26H1, and that Windows Server isn't listed as impacted by this specific issue (Justin Verstijnen). He also observed that existing user profiles seemed to hit the bug more often than newly created ones, a pattern he noted rather than something Microsoft has formally documented (Justin Verstijnen).

Given that scope, home users on standalone PCs aren't who Microsoft's notice is addressing. A user in a Microsoft Q&A thread from around six weeks ago reported an Explorer crash involving an Intel graphics driver DLL on a personal machine (Microsoft Q&A). That report points to a different suspected cause and doesn't establish that the two incidents share a fix, so a black screen on a single PC still calls for its own troubleshooting rather than an assumption that this AVD-focused patch applies.

What caused the Windows 11 black screen Explorer crash

The reported trigger was a Windows change introduced with KB5120998 that could cause explorer.exe to crash during shell startup, according to Verstijnen's account of Microsoft's confirmation (Justin Verstijnen). Explorer.exe handles the taskbar, Start menu, and File Explorer, so when it fails to finish loading, the desktop session itself can remain active even though nothing visible appears on screen (Justin Verstijnen).

That distinction matters for troubleshooting: the failure sits in Explorer not completing shell startup, not in a dropped remote connection, which is why manually relaunching Explorer could bring the desktop back immediately instead of requiring a full reconnect (Justin Verstijnen). Verstijnen's report, published three weeks ago, notes that Microsoft confirmed the higher occurrence rate in FSLogix setups without publishing the underlying technical reason at that time, so why FSLogix profiles triggered the crash more often than standard ones remained an open question even as the fix shipped (Justin Verstijnen).

Explorer workaround and Known Issue Rollback for admins who can't update yet

Microsoft's documented workaround for an affected session is to open Task Manager with Ctrl+Shift+Esc, select Run new task, type explorer.exe, and click OK. That restarts the shell for the current session, though it may need to be repeated at a future sign-in if the device still hasn't been updated (BleepingComputer).

For managed fleets that can't deploy the October update right away, Microsoft issued Known Issue Rollback packages: KB5124006 for Windows 11 26H1, and KB5124010 for 24H2 and 25H2 (BleepingComputer). Deploying a KIR requires installing and configuring the matching Group Policy for the Windows version in use, then restarting the affected devices to apply the setting (BleepingComputer). Organizations managing devices through Intune instead of Group Policy can ingest the same rollback as a custom profile (Justin Verstijnen).

A KIR disables only the specific change causing the crash rather than removing the entire update, and Microsoft describes it as a stopgap: the policy disables the problematic change until a resolution ships in a future Windows update (BleepingComputer). Microsoft's guidance confirms the manual Explorer workaround is no longer needed once a device is running an update from October 13 or later, but the cited sources don't include a formal procedure for removing a KIR policy that's already deployed, so administrators should follow their own KIR deployment documentation for policy removal rather than assume it should be deleted immediately (Microsoft Support).

What to do now

AVD and FSLogix administrators should prioritize installing an October 13-or-later cumulative update on affected hosts, checking that the specific build is covered since KB5127648 is Microsoft's named example rather than an exhaustive list. Once that update is confirmed installed, the manual Explorer workaround becomes unnecessary, though any existing KIR policy should be retired through standard deployment tooling rather than deleted on assumption.

Systems that can't update immediately can use the Ctrl+Shift+Esc Explorer relaunch as an interim fix, or deploy the matching KIR package, KB5124006 for 26H1 or KB5124010 for 24H2/25H2, through Group Policy or Intune. Standalone PC owners seeing a black screen should treat it as a separate case worth its own diagnosis, since Microsoft's scoping for this fix points to AVD and FSLogix environments rather than individual machines.