Black Screen at Logon After September 2026 Windows Update — Explorer.exe "Stack-Based Buffer Overrun"

Why does explorer.exe crash with a "stack-based buffer overrun" error and leave a black screen after a Windows update, and how do I fix it?

Some users on Windows 11 24H2 and 25H2 VDI/RDS sessions got stuck at a blank desktop after logon — the wallpaper and taskbar never appear — after installing Windows cumulative updates released from late August 2026 onward. Microsoft has fixed this in the October 13, 2026 cumulative update KB5127648. This article covers the fix, how to remove the interim mitigations once you have it, and the interim options for hosts that can’t be patched yet.

Resolution: Install KB5127648

Microsoft lists this in KB5127648 as “[Windows Explorer (Known issue)] Fixed”: the update “fixes an issue that affects Windows Explorer in multi-user environments”, where after sign-in “Explorer.exe might fail to start or repeatedly crash, causing a black screen.” Microsoft names Azure Virtual Desktop and FSLogix as examples; the same fix applies to the ProfileUnity, Citrix UPM, and Omnissa DEM reports. Microsoft’s release health entry says the issue was resolved by Windows updates released October 13, 2026 and later, and that devices on those updates don’t need a workaround.

KB5127648 is cumulative. It also contains KB5124008, the KB5129195 out-of-band update, and the KB5124010 September preview, so any later monthly cumulative update also includes the fix.

1. Install the update on the golden image

Install KB5127648 (or any later cumulative update) on the golden image, then seal and publish it to the pool the way you normally do (recompose, image update, or MCS/PVS update). For persistent desktops and RDS hosts, install it through your normal patching tool.

2. Confirm the build

On a session host built from the new image, confirm UBR is 9711 or higher:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' |
    Select-Object CurrentBuild, UBR

3. Validate on a pilot pool

Log on with test users who were affected before (large or complex Start/shell state reproduces it best), and confirm the desktop loads every time. Then confirm no new Application Popup (Event ID 26) entries for explorer.exe have been logged since the update:

$f = @{LogName='System'; ProviderName='Application Popup'; Id=26}
Get-WinEvent -FilterHashtable $f -MaxEvents 50 |
    Where-Object Message -like '*explorer.exe*' |
    Format-List TimeCreated, Message

4. Roll out, then remove the interim mitigations

Once the pilot is clean, roll the image out to the remaining pools, then follow Removing Interim Mitigations below.

Removing Interim Mitigations

After every host in a pool is on the fixed build, remove whatever interim mitigations you deployed for that pool:

• Repair-ShellXamlPackages.ps1 (Interim #2): disable or delete the Application Launcher (or User Defined Script) rule and redeploy the configuration. This script re-registers three AppX packages on every logon, which adds logon time and does nothing on a fixed host, so it should not stay in place.
• Watch-ExplorerShell.ps1 (Interim #3): optional. It’s harmless to leave running through the pilot as a safety net, but disable the rule once you’re satisfied, so it doesn’t hide a future, unrelated shell problem.
• Known Issue Rollback (Interim #1): the KIR only disables the change that caused the issue until a permanent fix is installed, and that fix is now in KB5127648. Microsoft hasn’t published specific removal steps for this KIR. Once every host the policy targets is on the fixed build, set the KIR policy to Not Configured at your next change window, then remove the ADMX/MSI. If the policy also targets Windows Server 2025 hosts, confirm they have the matching October 2026 Server cumulative update first.

Error Message

Affected sessions log an Application Popup event (Event ID 26) at logon, at or near the moment the desktop should appear:

explorer.exe - System Error
The system detected an overrun of a stack-based buffer in this application. This
overrun could potentially allow a malicious user to gain control of this application.

Why It's Intermittent

Reports vary from "every logon fails" to "most logons are fine, a few aren't" — both are consistent with the same underlying condition. Liquidware's crash-dump analysis of an affected session traced the fault to a stack buffer inside explorer.exe's own code, not to any Liquidware component. A stack buffer overrun of this kind typically fires only when the data being copied into that buffer exceeds a fixed size — so sessions are affected only when something in the user's shell/profile state (Start layout, pinned items, jump lists, and similar per-user shell data) is large or complex enough to cross that threshold.

That also explains why this shows up disproportionately in VDI/RDS environments running profile management software — ProfileUnity, FSLogix, Citrix UPM, and Omnissa DEM are all reported hitting this — the software isn't at fault, but roaming or rehydrating that same class of per-user shell state makes crossing the threshold more likely. It is not limited to Windows 11 25H2: 25H2 ships as an enablement package on top of the 24H2 servicing branch, so the same explorer.exe code — and the same regression — is present on updated 24H2 systems as well.

Cause

Windows cumulative updates released from late August 2026 onward appear to have introduced a regression in how explorer.exe consumes the modern shell/Start UI framework — the WinUI3/XAML packages MicrosoftWindows.Client.CBS, Microsoft.UI.Xaml.CBS, and MicrosoftWindows.Client.Core. This is the same package family behind the separate, generally self-recovering ShellHost.exe framework-loading failure documented in the related article below. In explorer.exe's case, a mismatch or stale registration state for those packages after the update appears to drive Explorer into a code path that overflows a stack buffer instead of failing gracefully.

Interim Mitigations (Unpatched Hosts Only)

The three options below were published while Microsoft’s fix was pending. They are kept here only for hosts that can’t install KB5127648 yet, such as an image frozen for a change freeze. Installing the update is the fix; these options only reduce the impact.

Interim #1: Microsoft’s Known Issue Rollback

Microsoft acknowledged the issue and released a Known Issue Rollback (KIR) — an official Group Policy–based mitigation, distributed as an MSI that registers ADMX templates you enable via Group Policy. Citrix documents this specifically for Desktop OS VDAs in CTX697101 — Issues with Microsoft Windows September 2026 Update, under "Black Screens on Login after installing KB5124008 / KB5120998 on Desktop OS VDAs." The relevant packages Citrix references are Windows 11 24H2, Windows 11 25H2 and Windows Server 2025 — KB5124008 260912_00472 Group Policy, and Windows 11 22H2 — KB5122880 260912_00473 Group Policy.

Microsoft’s release health entry also offered KIR Group Policies for enterprise-managed devices. A restart is required after the policy is applied. See Citrix’s article (linked above) or Microsoft’s Known Issue Rollback documentation for the MSI download and Group Policy steps for your OS version.

Interim #2: Shell Package Re-Registration

Re-registering the three shell UI packages at logon, before Explorer starts, reduced the issue on unpatched hosts. Deploy it as a ProfileUnity Application Launcher (or User Defined Script) rule with Timing set to After Configuration Execution, ahead of shell startup.

1. Get the script. Alongside the package re-registration, this version watches for explorer.exe with a sustained-alive check (so a brief flash-then-crash isn't mistaken for success), guards against overlapping runs, logs identity and elevation state, can log to a central share for easier fleet-wide troubleshooting, and de-elevates before relaunching the shell so the user doesn't end up with an elevated Explorer:

What the script does, in order:

1. Logs identity and elevation state, then re-registers the three shell UI/XAML packages (MicrosoftWindows.Client.CBS, Microsoft.UI.Xaml.CBS, MicrosoftWindows.Client.Core).
2. Watches for explorer.exe, distinguishing never-started, started-then-died, and stayed-running (so a brief flash-then-crash isn't mistaken for success).
3. If explorer isn't confirmed alive, relaunches it, de-elevating first if the script itself is running elevated.
4. Confirms explorer came up and logs the result.

2. Add it as a New Application Launcher Setting

1. Before adding the Application Launcher rule, open the script and adjust its param() defaults to match your environment — $LogShare (set it to a central log share, e.g. "\\yourserver\yourshare\dumps", or leave $null for local %TEMP%), $WaitSeconds, and $AliveConfirmSeconds. Since every session runs the same shared copy, editing the defaults once here covers everyone and keeps the Arguments field in the rule below simple — no long list of extra flags to type (and possibly mis-quote) in the console. You can still override any of them per-rule by appending flags after -File "..." if you ever need a different rule to behave differently.
2. In the ProfileUnity Management Console, open the applicable configuration, go to Application Launcher, and add a New Application Launcher Setting.
3. Set Filespec to C:\Windows\System32\cmd.exe and Arguments to /c powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -NonInteractive -File "\\yourserver\yourshare\scripts\Repair-ShellXamlPackages.ps1" — running PowerShell through cmd.exe /c this way is the general pattern for Application Launcher script rules. Point -File at the full UNC path to the script on a share reachable at logon, rather than a bare filename — that way there's nothing to separately stage locally (see the note on file distribution below).
4. Set Timing to After Configuration Execution and Frequency to Every Logon.
5. Check Run Asynchronously. By default ProfileUnity waits for the application to terminate before continuing; this script can run for up to WaitSeconds and would otherwise hold up logon while ProfileUnity waits on it.
6. Check Execute without Elevation — the preferred fix for the elevation warning above. Without it, the script's own built-in safety net still de-elevates before relaunching the shell, but checking this box avoids that extra step entirely.
7. Either reference the script directly from a network share (as in the -File path above — make sure that share is reachable and read-accessible for the user before shell startup, and use a highly-available path), or deploy the script itself via the configuration's file/module distribution and reference it by local filename instead.
8. Save and apply the configuration to a pilot desktop pool only first.

Interim #3: Watchdog-Only Script (No Re-Registration)

If you'd rather not re-register the AppX shell packages — for example, you're relying on the KIR above and just want a safety net, or package re-registration isn't necessary/desired in your environment — the same detection-and-relaunch logic is available on its own, without the package-registration step. Everything else (sustained-alive detection, re-entrancy guard, logging, and the same de-elevated relaunch described in the elevation warning above) works the same way.

Its log location is a plain parameter rather than a fixed path — point it at a local folder such as C:\Temp (the default) or a UNC share of your choice, as long as the account running the script has write rights there:

What the script does, in order:

1. Logs identity and elevation state (no package re-registration here — that's the difference from Repair-ShellXamlPackages.ps1 above).
2. Watches for explorer.exe, distinguishing never-started, started-then-died, and stayed-running (so a brief flash-then-crash isn't mistaken for success).
3. If explorer isn't confirmed alive, relaunches it, de-elevating first if the script itself is running elevated.
4. Confirms explorer came up and logs the result.

Deploy it the same way as Repair-ShellXamlPackages.ps1 above: before creating the rule, adjust the script's own param() defaults ($LogDir for central logging, $WaitSeconds, $AliveConfirmSeconds) rather than passing them as extra arguments — then set Filespec C:\Windows\System32\cmd.exe, Timing After Configuration Execution, Frequency Every Logon, with Run Asynchronously and Execute without Elevation both checked, and Arguments /c powershell.exe -ExecutionPolicy Bypass -WindowStyle Hidden -NonInteractive -File "\\yourserver\yourshare\scripts\Watch-ExplorerShell.ps1".

Recovering a Stuck Session

If a user is already stuck at a blank desktop:

1. Press Ctrl+Alt+Delete and open Task Manager.
2. Select File > Run new task, enter explorer.exe, and confirm.
3. The desktop should load normally for the remainder of that session.

This does not prevent recurrence on the user's next logon. The Repair-ShellXamlPackages.ps1 script above already includes this recovery step (it waits and force-launches explorer.exe if needed), so sites running it as an Application Launcher rule get this fallback automatically. On a host with KB5127648 installed this should no longer recur; if it does, see Still seeing the black screen.

Related Articles

• Microsoft KB5127648 — October 13, 2026 security update (OS Builds 26100.9711/26200.9711/26300.9711) (the fix)
• Citrix CTX697101 — Issues with Microsoft Windows September 2026 Update (the same black-screen-on-login issue on Desktop OS VDAs, and the Microsoft KIR)
• Microsoft KB5129195 — September 14, 2026 out-of-band update (OS Builds 26100.9457/26200.9457) (historical; superseded by KB5127648)
• ShellHost.exe System Error — "Overrun of a Stack-Based Buffer" Popup at Logon (the related, generally self-recovering variant of this same shell-package issue)
• ProfileUnity: How to Enable Debug Logging
• How to Collect Logs Using the Diagnostic Tool
• Enabling User-Mode Dumps in a ProfileUnity Configuration

Revision History