If your Win11 25H2 laptop is randomly frozen in the morning, this is why. Microsoft shipped 25H2 26200.8246 that hard-freezes machines — and still won’t list it as a known issue

Question

If your Win11 25H2 laptop is randomly frozen in the morning, this is why. Microsoft shipped 25H2 26200.8246 that hard-freezes machines — and still won’t list it as a known issue

JJ IT 5

We are seeing repeatable hard freezes on Windows 11 25H2 build 26200.8246 (KB5083769) — systems lock solid when idle, no input response, forced power-off required, and no crash dump. This is not a “driver update” or “run SFC” situation; Windows never even logs a failure beyond Kernel‑Power 41 after we hard reboot.

Here’s the problem: the public messaging is consistently**“no known issues”** while the community reports the opposite. Multiple reports and tech coverage already documented that March’s cumulative update (KB5079473) caused freezes/instability while Microsoft’s page still claimed no known issues at the time. April’s KB5083769 release notes also don’t mention hard-freeze behavior, despite real-world reports.

This looks like a power-state/Modern Standby regression (idle/unattended correlation, inconsistent reproduction, lack of dumps). Disabling S0 helps but doesn’t fully resolve across a small set of machines.

Microsoft: please stop pretending this isn’t happening and publish it on Release Health with real mitigation guidance. Until then, we’re blocking new 25H2 rollouts.

If you’re seeing this too, respond with build #, hardware, and clean install vs upgrade.

JJ IT 5 Reputation points

2026-04-23T13:59:25.6133333+00:00
Reporting to Dell as we speak "We are requesting formal escalation of a stability issue affecting Dell laptops running Windows 11 25H2 (OS build 26200.8246 – April 2026 CU / KB5083769).

We have multiple identical Dell systems exhibiting hard system freezes when idle/unattended

We are asking Dell to:

Treat this as a software/OS escalation, not a single‑device issue

Escalate internally to Microsoft via Dell’s OEM channel as a potential Windows 11 25H2 S0/Modern Standby regression

Advise whether Dell has seen similar reports on this model or others

At this point, continued hardware swaps or re‑imaging to the same Windows build is not productive. We are pausing new Windows 11 25H2 deployments pending resolution or Microsoft acknowledgment.

Please confirm this case is being escalated beyond front‑line troubleshooting.

1 answer

Your answer

JJ IT 5 Reputation points

2026-04-23T13:59:25.6133333+00:00

Reporting to Dell as we speak "We are requesting formal escalation of a stability issue affecting Dell laptops running Windows 11 25H2 (OS build 26200.8246 – April 2026 CU / KB5083769).

We have multiple identical Dell systems exhibiting hard system freezes when idle/unattended

We are asking Dell to:

Treat this as a software/OS escalation, not a single‑device issue

Escalate internally to Microsoft via Dell’s OEM channel as a potential Windows 11 25H2 S0/Modern Standby regression

Advise whether Dell has seen similar reports on this model or others

At this point, continued hardware swaps or re‑imaging to the same Windows build is not productive. We are pausing new Windows 11 25H2 deployments pending resolution or Microsoft acknowledgment.

Please confirm this case is being escalated beyond front‑line troubleshooting.

Answer 1

Harry Phan 19,485 Independent Advisor

Hi Jerry,

The freezes you’re seeing on 25H2 build 26200.8246 with KB5083769 are consistent with a Modern Standby regression, and because the systems lock without generating dumps, this is not something you can remediate locally. Microsoft has not yet published Release Health guidance, so the only viable path is OEM escalation to Microsoft engineering. Dell confirming whether they’ve seen similar reports across models will help establish scope, but ultimately only Microsoft can deliver a servicing fix. Until that acknowledgment or patch is released, the safest course is to hold back 25H2 deployments on affected hardware and keep your escalation case open with Dell so it stays visible upstream.

Harry.

JJ IT 5 Reputation points

2026-04-23T14:45:10.5233333+00:00
Yes Harry, thanks.

Thanks — this response actually reinforces what we’re seeing, which is why we’re pushing for acknowledgment beyond generic troubleshooting.

To be explicit, we’re well past the “update drivers / run SFC” stage. We’ve already run the full OEM + firmware playbook across multiple affected systems and it did not resolve the issue:

BIOS re-applied / reinstalled (even when the installed and offered versions match) + BIOS defaults loaded

OEM Intel graphics driver reinstall (not Windows Update driver)

Intel PPM / power provisioning package reinstall (where applicable) Fast Startup is already disabled by policy. Hardware diagnostics show no faults.

Yet on Windows 11 25H2 build 26200.8246 (KB5083769) we still get hard freezes during idle/unattended periods: frozen screen, no keyboard/mouse, forced power-off required. There is no BSOD, no dump, and Event Viewer typically shows only Kernel‑Power 41 after the forced shutdown—nothing actionable beforehand.

Disabling Modern Standby / S0 reduces frequency but does not eliminate it across systems. That’s not a fix — it’s a workaround that degrades power behavior and still doesn’t guarantee stability. The pattern (idle/unattended + no crash artifacts) strongly points to a Windows 11 25H2 power-state / idle transition deadlock, especially given that it disproportionately impacts clean installs vs upgrades.

Now the bigger issue:

“Roll back to 24H2” is not an acceptable answer for enterprises. Re-imaging fleets and pinning to older baselines because the current release is unstable is an operational waste and pushes organizations into a bad choice between stability and being current with security updates. Admins deploy Patch Tuesday updates because we’re expected to stay current and compliant — “just run an older release” is not a real mitigation strategy.

And frankly, the lack of transparency here is part of the problem. Microsoft’s official release health / KB documentation is not reflecting what admins are seeing in the field. The official Windows 11 25H2 Release Health page lists other known issues (e.g., Microsoft account sign-ins and WUSA scenarios) but nothing about widespread hard-freeze / idle lockups. Windows 11 25H2 known issues and notifications Likewise, the official KB5083769 release notes don’t mention a hard-freeze/idle lock issue. [KB5083769 (OS Builds 26200.8246 and 26100.8246)]

This is starting to look like a quality control problem in the Windows servicing pipeline. We’ve now had multiple cycles where community reports show serious stability issues while official “known issues” lag behind (or are absent early), which makes it hard for admins to trust the documentation when making rollout decisions. Coverage and forum analysis around KB5079473 specifically called out the disconnect between real-world freeze/instability reports and the lack of alignment in official status/notes early on. [neowin.net], [bing.com]

So — candidly — Microsoft’s QC is severely lacking recently. What’s going on? Because right now the practical outcome is: customers either deploy unstable current builds or stay on older baselines and hope that’s “good enough.” That’s not an acceptable operating model for business fleets.

What we need from Microsoft now is concrete action, not more generic steps:

Acknowledgment in Release Health / KB notes that this scenario is under investigation (so admins can make informed rollout decisions). [thewindowsclub.com]

Specific guidance on what instrumentation/logging Microsoft wants for S0/idle deadlocks (because these failures don’t generate dumps).

A mitigation/KIR if one exists internally.

Until then, we are pausing new 25H2 deployments because this behavior is unacceptable in production environments.Thanks — this response actually reinforces what we’re seeing, which is why we’re pushing for acknowledgment beyond generic troubleshooting.

To be explicit, we’re well past the “update drivers / run SFC” stage. We’ve already run the full OEM + firmware playbook across multiple affected systems and it did not resolve the issue:

BIOS re-applied / reinstalled (even when the installed and offered versions match) + BIOS defaults loaded

OEM Intel graphics driver reinstall (not Windows Update driver)

Intel PPM / power provisioning package reinstall (where applicable)
Fast Startup is already disabled by policy. Hardware diagnostics show no faults.

Yet on Windows 11 25H2 build 26200.8246 (KB5083769) we still get hard freezes during idle/unattended periods: frozen screen, no keyboard/mouse, forced power-off required. There is no BSOD, no dump, and Event Viewer typically shows only Kernel‑Power 41 after the forced shutdown—nothing actionable beforehand.

Disabling Modern Standby / S0 reduces frequency but does not eliminate it across systems. That’s not a fix — it’s a workaround that degrades power behavior and still doesn’t guarantee stability. The pattern (idle/unattended + no crash artifacts) strongly points to a Windows 11 25H2 power-state / idle transition deadlock, especially given that it disproportionately impacts clean installs vs upgrades.

Now the bigger issue:

“Roll back to 24H2” is not an acceptable answer for enterprises.
Re-imaging fleets and pinning to older baselines because the current release is unstable is an operational waste and pushes organizations into a bad choice between stability and being current with security updates. Admins deploy Patch Tuesday updates because we’re expected to stay current and compliant — “just run an older release” is not a real mitigation strategy.

And frankly, the lack of transparency here is part of the problem. Microsoft’s official release health / KB documentation is not reflecting what admins are seeing in the field. The official Windows 11 25H2 Release Health page lists other known issues (e.g., Microsoft account sign-ins and WUSA scenarios) but nothing about widespread hard-freeze / idle lockups. Windows 11 25H2 known issues and notifications
Likewise, the official KB5083769 release notes don’t mention a hard-freeze/idle lock issue. [KB5083769 (OS Builds 26200.8246 and 26100.8246)]

This is starting to look like a quality control problem in the Windows servicing pipeline. We’ve now had multiple cycles where community reports show serious stability issues while official “known issues” lag behind (or are absent early), which makes it hard for admins to trust the documentation when making rollout decisions. Coverage and forum analysis around KB5079473 specifically called out the disconnect between real-world freeze/instability reports and the lack of alignment in official status/notes early on. [neowin.net], [bing.com]

So — candidly — Microsoft’s QC is severely lacking recently. What’s going on?
Because right now the practical outcome is: customers either deploy unstable current builds or stay on older baselines and hope that’s “good enough.” That’s not an acceptable operating model for business fleets.

What we need from Microsoft now is concrete action, not more generic steps:

Acknowledgment in Release Health / KB notes that this scenario is under investigation (so admins can make informed rollout decisions). [thewindowsclub.com]

Specific guidance on what instrumentation/logging Microsoft wants for S0/idle deadlocks (because these failures don’t generate dumps).

A mitigation/KIR if one exists internally.

Until then, we are pausing new 25H2 deployments because this behavior is unacceptable in production environments.
JJ IT 5 Reputation points

2026-04-23T14:46:44.8666667+00:00
For others affected — data points requested:

We’re seeing this consistently on Windows 11 25H2 (build 26200.8246) with hard freezes during idle/unattended periods, no BSOD, no dump, and only Kernel‑Power 41 after forced shutdown.

If you’re experiencing this, please reply with:

OS build (e.g. 26200.8246)

Clean install vs upgrade

Hardware model / OEM

Whether Modern Standby (S0) is enabled or disabled

This is disproportionately affecting clean installs vs upgraded systems and appears tied to idle / power‑state transitions, not hardware faults.

The more confirmations we can gather here, the easier this is to escalate properly.
JJ IT 5 Reputation points

2026-04-27T12:56:12.32+00:00

We’re also observing a very strong time-based pattern that reinforces this as an OS-level issue: nearly all affected systems freeze between 6:00–6:30 AM local time while sitting at the lock screen, with the clock frozen at the exact minute the system hung. Mouse and keyboard input are completely unresponsive, and the system remains in this state indefinitely until a hard power-off. This is not a black screen, display sleep, or GPU resume issue — the UI is still rendered, but the OS has stopped executing. The consistent timing strongly suggests a deadlock during scheduled maintenance and/or Modern Standby (S0) power-state transitions, not random hardware failure. Given the scale of changes and security fixes shipped in 25H2, Microsoft needs to confirm whether there were servicing, maintenance, or power framework changes in this release that could explain deterministic early-morning freezes on idle systems.

These failures generate no dumps or actionable logs, meaning they are effectively invisible to telemetry unless customers surface them manually — which makes public acknowledgment even more critical.
JJ IT 5 Reputation points

2026-04-27T14:32:12.96+00:00

Related evidence / cross-thread correlation (same build & CU): • KB5083769 (26200.8246) boot-loop thread on Microsoft Q&A (shows broader instability tied to the same CU): https://learn.microsoft.com/en-us/answers/questions/5862058/ • I posted this same idle/lock-screen hard-freeze pattern to ElevenForum’s KB5083769 thread to aggregate confirmations (admins there are seeing similar issues): https://www.elevenforum.com/t/kb5083769-windows-11-cumulative-update-build-26100-8246-24h2-and-26200-8246-25h2-april-14.46106/ [learn.microsoft.com] [askvg.com]

This is not a one-off; KB5083769 / 26200.8246 is showing multiple severe failure modes across systems.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
JJ IT 5 Reputation points

2026-04-27T14:37:26.86+00:00

Additional observation from our environment: on Windows 11 25H2 (OS build 26200.8246 / KB5083769), we are seeing full system freezes during idle or unattended periods. Systems remain at the lock screen with the clock no longer advancing, no keyboard or mouse response, and no crash dump generated. Recovery requires a hard power-off, with only Kernel-Power 41 logged afterward. This behavior is different from a boot loop or black screen and points to a possible power-state or maintenance-related deadlock introduced with this update.

Share via

If your Win11 25H2 laptop is randomly frozen in the morning, this is why. Microsoft shipped 25H2 26200.8246 that hard-freezes machines — and still won’t list it as a known issue

1 answer

Your answer