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

Hello Fireplace Stone & Patio,

Thank you for your update.Based on the Shell-Core/Operational logs you provided:

• During the affected logon, the following logon task groups started but did not complete:
  • AppReadinessPreShellGroup
    • AppReadinessPreRoamingGroup
    • Other shell initialization tasks completed successfully.
    • Winlogon, user profile loading, DWM, and Explorer were all confirmed healthy.
    • Explorer.exe remained running and responsive, but the desktop was not rendered.
• The issue cleared after a reboot, and the subsequent successful boot showed the AppReadiness-related tasks completing normally.

These findings indicate that the system is no longer stalling in the SessionEnv phase. Instead, the evidence points to the shell initialization sequence waiting on the AppReadiness pre-shell processing to complete before presenting the desktop.

• Is this behavior associated with KB5072911 or Build 26200.8655?

The data collected indicates similarities in the overall symptom pattern, where the desktop presentation is delayed during the shell initialization phase. At this stage, the information gathered helps narrow the investigation toward the AppReadiness-related portion of the logon sequence. Further analysis would be required to determine whether this aligns with a previously documented issue or a separate condition.

• Is there a KIR available?

At present, we have not identified a published Known Issue Rollback (KIR) package that specifically addresses this AppReadinessPreShellGroup/AppReadinessPreRoamingGroup stall on Build 26200.8655. The issue is also not currently listed in the known-issues section of the June 2026 cumulative update documentation.

• Is there a supported mitigation to adjust AppReadiness timing?

We are not aware of any supported Microsoft configuration that modifies the timeout or scheduling behavior of the AppReadinessPreShellGroup or AppReadinessPreRoamingGroup logon tasks.

Given the evidence collected so far, the recommended next step would be to gather diagnostic data during the failure state, such as:

• Shell-Core/Operational logs from both failed and successful boots
• Explorer user-mode dump while the black screen is present
• AppReadiness-related event logs
• ProcMon boot trace if the issue can be reproduced consistently

These artifacts would help determine whether the AppReadiness task is waiting on a specific component, application package, or startup dependency.

Thank you for providing the detailed Shell-Core evidence. This significantly improves the focus of the investigation and gives us a much more specific failure signature to pursue.

Ivy Bui

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