Post-login black screen with cursor after KB5094126 (Build 26200.8655) — fleet-wide, intermittent, SessionEnv set to Manual

Hello,

We are experiencing simmilar issues on Windows Server 2025 (virtual machine) after installing "2026-06 Security Update (KB5094125) (26100.32995)".

Black screen after logon (cursor only) -> the above suggestions are not working (ref. "WHAT I'VE CONFIRMED / RULED OUT").

• We are seeing event 7011 per logon on the affected servers:
  • "A timeout (30000 milliseconds) was reached while waiting for a transaction response from the AppReadiness service."
  • Out SIEM-log collection verifies that all affected servers, and only theese have this event.
  • They started the day after automatic patches, when first user tried to log on. No traces of these events further back in time.
• It affects both VM-console and RDP
• We have no third-party EDR/AV-software on affected machine the affected machines
• Repair of VMware tools (re-install displaydrivers) have a limited effect. After re-install the GUI appears after waiting for ~20 sec, but after booting the server again, it is back to permanent black (GUI does not appear after waiting).

Update with a more specific failure signature — this significantly narrows the issue from "black screen" to a concrete stall point.

Captured a live failure today on an affected machine (build 26200.8655) with every component proven healthy, then captured a clean boot for contrast. The differentiator is in the Microsoft-Windows-Shell-Core/Operational log.

FAILED COLD-BOOT LOGON (black screen, cursor only, OS fully responsive):

• Winlogon, profile load, DWM, and explorer.exe all healthy and Responding=True
• SessionEnv confirmed Automatic and Running (so not the earlier SessionEnv finding)
• User logged into their own profile, console session Active (verified via quser)
• Shell-Core log shows these logon tasks STARTED but never logged a "finished" event:
  • AppReadinessPreShellGroup (started, no finish)
  • AppReadinessPreRoamingGroup (started, no finish)
• All other shell logon tasks completed normally (ShellPrep, DefaultAssociations, BackupRestoreCoordinator → all started AND finished)
• Net result: shell waits on the AppReadiness pre-shell group, desktop never paints

Restarting explorer.exe did NOT release it. Restarting the AppReadiness service did NOT release it. Only a full reboot cleared it.

CLEAN BOOT AFTER REBOOT (same machine, desktop renders normally):

• Shell-Core log shows the full startup sequence completing — AppResolver scans start/stop/commit cleanly, Run-key enumeration finishes, and startup apps execute with matching Started/Finished (Event 9707/9708) pairs
• Shell presented normally, desktop painted

So this presents as an intermittent stall in the AppReadiness pre-shell logon group on cold boot, blocking shell presentation. It is NOT persistent — a clean reboot resolves it because the startup timing resolves differently.

This appears consistent with the behavior described in KB5072911 ("Explorer, the Start menu, and other XAML-dependent apps might not start or close unexpectedly on some enterprise devices"), which was referenced earlier in this thread.

Questions:

1. Is the AppReadinessPreShellGroup / AppReadinessPreRoamingGroup logon-task stall a recognized failure mode tied to KB5072911 or the post-June-CU shell-init changes on build 26200.8655?
2. If KB5072911 is the relevant known issue, is there an associated KIR Group Policy package we can deploy?
3. Is there a supported configuration to harden the AppReadiness logon-group timing (e.g., service start dependency or timeout adjustment) as an interim mitigation while a fix is pending?

Can provide the full Shell-Core/Operational log exports for both the failed and clean boots on request.

Thanks Ivy — this is helpful, and it confirms our own conclusion that SessionEnv config isn't the root cause but rather a symptom of a logon-timing variance after the update.

Two follow-ups:

1. The AI-generated first response referenced KB5072911 ("Explorer, the Start menu, and other XAML-dependent apps might not start or close unexpectedly on some enterprise devices"). That symptom description closely matches what we're seeing (explorer running but shell not rendering on cold-boot login). Is KB5072911 potentially related, and does it have an associated KIR we could apply? This seems like the closest official match.
2. On the endpoint-security suggestion — we run Sophos Intercept X as primary. Before testing with it disabled fleet-wide (which we'd be cautious about), is there a specific logon-path interaction Microsoft has seen between third-party AV and the post-KB5094126 shell-init timing? That would help us scope a controlled test on a single machine rather than broadly disabling protection.

We can provide full Winlogon/Application event logs and boot timing data. Given this affects users across our environment daily, we'd also appreciate guidance on whether this should be escalated for product-team review given there's no documented known-issue entry yet.

Thanks — understood there's no indexed known-issue entry for KB5094126 / 26200.8655 specifically.

Two follow-ups for anyone from the product team:

1. KB5089573 (May 26) was cited in community reports as introducing service-start-timeout and delayed-shell-init behavior that was rolled into the June CU. Is the post-login black screen / SessionEnv-unavailable-at-logon symptom potentially related to that same change? The symptom cluster (Winlogon 6003 "SessionEnv unavailable," 2-3 min delayed desktop, only on cold-boot first login) matches what others reported after that component.
2. Is there any KIR or release-health entry being tracked for delayed shell initialization on 25H2 build 26200.8655? Watching the release health dashboard but nothing referencing this yet.

Happy to provide full event logs and fleet service-state data.

Hello Fireplace Stone & Patio,

Thank you for contacting Microsoft Community.

Please find our responses to your questions below:

1. Is this a known issue with KB5094126 / Build 26200.8655?

At this time, this specific behavior is not currently documented as an official known issue in the KB article or Windows Release Health information for KB5094126.

2. Is there a KIR Group Policy package available for it?

At present, no such KIR package or corresponding Group Policy template has been made available for this specific issue.

3. Did this update change the SessionEnv service startup type or alter winlogon notification subscriber timing/ordering?

Based on your findings:

• The Event ID 6003 (SessionEnv subscriber unavailable) indicates a delay or timing issue in the Winlogon notification chain
• The Windows logon process depends on sequential components:
  • Winlogon → Userinit → Explorer (shell)

If one of the subscribers (such as SessionEnv) is not ready when required, it may delay completion of the user session initialization, which can result in a temporary black screen.

Since the issue persists even when SessionEnv is set to Automatic and running, this suggests that:

• The service configuration itself is not the root cause
• Rather, there may be a timing or dependency initialization variance introduced after the update

4. Recommended interim mitigation

While we continue monitoring for any official fix or guidance, we recommend the following interim actions:

• Continue using SessionEnv = Automatic. This remains a valid configuration and may help reduce frequency, even if it does not fully prevent the issue.
• Control or pause further rollout of KB5094126 (if applicable). This may help limit additional exposure while the behavior is under observation.
• Implement a temporary user-side mitigation (optional). For example, restarting the Explorer process after a short delay at logon may help restore the desktop more consistently in affected scenarios.
• Perform validation with endpoint security software. As timing‑related issues during logon can be influenced by third‑party components, testing with endpoint security temporarily disabled on a subset of devices may help validate whether there is any interaction.
• Wait for a newer cumulative update that contains the fix.

Hope you found something helpful here. Please let me know if you need further assistance.

If this answer could solve the issue, it's appreciated to accept the answer.

Thank you again for your patience and support!

Ivy Bui