Microsoft has quietly fixed a long‑running annoyance in Windows’ power menu: the Start menu option
“Update and shut down” — which in some configurations behaved like “Update and restart” — now behaves as labeled in recent Windows Insider preview builds and the October 28, 2025 optional cumulative preview (KB5067036).
Background
For many users the power‑menu choice
Update and shut down is a convenience: install pending updates while you walk away, then return to a powered‑off, patched machine. Instead, a nontrivial,
intermittent subset of systems applied updates but then rebooted or returned to the sign‑in screen — effectively leaving devices powered on and causing drained laptop batteries, missed maintenance windows, and brittle automation. Community reports and Microsoft’s Insider notes documented the issue across preview flights before the company moved to remediate the behavior.
This was not merely a cosmetic mismatch between a label and its result: the behavior had measurable operational impacts. Battery life was affected for mobile users, scripted workflows and scheduled maintenance expecting deterministic shutdowns failed, and end users adopted workarounds (for example, always using
Update and restart) that reduced convenience and sometimes undermined update compliance.
What Microsoft shipped and when
Microsoft implemented the correction in the Windows Insider channels (Dev and Beta) and folded the same servicing change into an optional preview cumulative update published October 28, 2025 as
KB5067036 (producing OS build strings in reporting such as 26100.7019 for 24H2 and 26200.7019 for 25H2). The Insider release notes for late September 2025 first included the terse confirmation:
“Fixed an underlying issue which could lead ‘Update and shutdown’ to not actually shut down your PC after.” That phrasing — deliberately focused on behavior — indicates a servicing orchestration change rather than a simple relabeling of the UI.
Microsoft’s staged rollout pattern was followed: validate in Insider flights, expose the change via the optional preview KB for Release Preview testing, then promote the fix during the regular Patch Tuesday cumulative update cycle once telemetry confirmed the change was safe for broader deployment. Multiple independent outlets and community testers reported reproductions of the fix after the preview release.
Technical anatomy — why a two‑word menu item was so flaky
At first glance this sounds trivial: a labeled menu option did not match the observed behavior. The truth is more complex because the shutdown‑while‑updating workflow crosses several subsystems and decision points in modern Windows servicing:
- Multi‑phase servicing — Modern cumulative updates often stage payloads while the OS is running and then perform offline commits during shutdown and early boot. Some components insist on one or more reboots to safely swap files; that multi‑phase nature makes the final power decision conditional.
- Fast Startup (hybrid shutdown) — When Fast Startup is enabled, Windows writes session state to disk to speed subsequent boots, producing a hybrid shutdown semantics that can alter whether the system uses a cold power‑off or a restart path; this interacts poorly with offline servicing in certain configurations.
- Sign‑in finishing flows — Options like “Use my sign‑in info to finish setting up after an update” trigger post‑reboot configuration steps that can change whether Windows finishes offline commits immediately, affecting whether the device powers off.
- Driver/firmware handoffs and running processes — If a driver or process requires a restart to replace in‑use files safely, the servicing stack may prefer to restart to guarantee integrity rather than power down, again creating branching behavior.
Because these variables (firmware, driver versions, Fast Startup state, the particular update payload) vary widely across the installed base, the symptom was
intermittent and hard to reproduce consistently — which made diagnosing and fixing the root orchestration behavior more time consuming than a pure UI fix.
How to verify the fix on your PC (practical checklist)
If you want to confirm whether your machine has the remediation, follow this practical sequence:
- Check your build number: press Win+R → type winver → press Enter. Compare your build against reported preview build strings (for example, families around the 26100/26200 preview builds after KB5067036).
- Install the optional preview: open Settings → Windows Update → look for Optional updates available and apply the October 28, 2025 optional preview (KB5067036) if you want the fix now for testing. Alternatively download the MSU from the Update Catalog and apply it on a test machine.
- Test the scenario: with a non‑critical pending update staged, choose Update and shut down and observe whether the machine powers off fully after completing offline commits. If it powers off, the fix has taken effect for that test path.
- If you prefer to wait for a mainstream rollout, monitor the next Patch Tuesday cumulative — Microsoft stages preview fixes into regular monthly updates after validation.
Notes and caveats: always apply preview or optional updates in a test or pilot ring first. These packages can include unrelated feature changes or servicing updates that produce regressions in some environments. Back up important data before testing, and collect logs/Feedback Hub entries if you observe problems.
The collateral: regressions and the Task Manager issue
Fixing one behavior can sometimes introduce others, especially when an update bundle touches multiple subsystems. The October preview that included the Update‑and‑Shutdown correction (KB5067036) was later associated with a surprising regression affecting Task Manager: closing Task Manager via its window Close (X) button could leave orphaned taskmgr.exe instances running, allowing multiple live instances to accumulate and consume memory. This regression was reported in early November preview adopters and caused Microsoft to address the problem in a subsequent cumulative update (November Patch Tuesday rollout) identified as
KB5068861, which included a repair for Task Manager’s close behavior.
That sequence is textbook of a complex OS servicing lifecycle: a targeted servicing change (update orchestration) was delivered inside a larger preview bundle that also carried other modifications — with the downstream consequence that a UI change or regression in Task Manager surfaced for early adopters. Microsoft validated the Task Manager fix in Insider flights and then folded it into the mainstream cumulative.
Practical mitigations while waiting for the Task Manager patch included using
End task or taskkill (taskkill /im taskmgr.exe /f) rather than the window Close (X) to ensure the process fully terminates, temporarily avoiding accumulation of orphaned processes. Enterprises were advised to keep preview updates confined to pilot rings until validators confirmed no regressions affected critical operations.
What this reveals about Microsoft’s servicing model — strengths and trade‑offs
Microsoft’s handling of this incident highlights both the strengths and the risks of its modern servicing approach.
Strengths:
- Staged validation pipeline — Insider flights → optional preview KB → Patch Tuesday. This path allows engineers to gather telemetry across diverse hardware and configurations before broad rollout, which is especially important for environment‑sensitive servicing fixes.
- Behavior‑first changelogs — Microsoft’s terse wording focused on observable outcomes (“Fixed an underlying issue…”) rather than exposing internal implementation details that might confuse end users, while still communicating the operational intent.
- Rapid follow‑up — When collateral regressions appeared (Task Manager), Microsoft validated and shipped a follow‑up cumulative that addressed the problem. The combination of preview telemetry and a monthly cumulative cadence facilitates swift remediation cycles.
Trade‑offs and risks:
- Preview bundles mix servicing with UX changes — Packaging a servicing fix with unrelated feature or UI changes can raise the chance of interactions and regressions, as happened with Task Manager. That means early adopters accepting preview KBs must be prepared for side effects.
- Intermittent, environment‑dependent bugs are expensive to locate — The root orchestration bug’s intermittent nature made it harder to reproduce and therefore required broad real‑world validation to gain confidence that the fix worked across device permutations.
- Messaging vs. transparency balance — Microsoft’s concise release notes help communicate intent but do not always supply granular root‑cause analyses. For admins and power users who need to assess risk, that lack of low‑level detail can complicate deployment decisions.
Recommendations for users and administrators
Given the fix and the observed preview regressions, here are concrete, actionable recommendations:
- For mainstream home users:
- Wait for the fix to arrive via the regular Patch Tuesday cumulative update if you value maximum stability. The staged approach reduces the chance of encountering the Task Manager regression or other side effects.
- If you prefer early access, install the optional preview (KB5067036) on a non‑critical or spare machine first and test Update and shut down behavior. Back up data beforehand.
- For IT administrators and power users:
- Pilot the preview in a representative ring, validating deterministic shutdown behavior across your hardware matrix (Fast Startup on/off, common drivers, management agents).
- Monitor telemetry and Feedback Hub reports from pilot systems and block broader rollout if you detect regressions (for example, Task Manager duplication) that affect operations.
- If you need deterministic shutdowns today and cannot risk preview packages, use a safe workaround: choose Update and restart and then manually shut down after login, or temporarily disable Fast Startup to reduce hybrid shutdown complexity. Note that disabling Fast Startup may increase boot times.
- Keep device drivers and firmware updated; some manifestations of the bug were tied to driver/firmware interactions that influenced the servicing decision tree.
- Diagnostic steps if a machine still misbehaves after installing the fix:
- Collect logs (WindowsUpdate.log, CBS logs, and SetupEv) and open a Feedback Hub report to expedite vendor triage.
- Reproduce the scenario with the same update payload and configuration to give MSR/Support a reproducible case.
Critical assessment — what’s fixed, what remains uncertain
The public evidence — Insider release notes and the KB preview entry for KB5067036 — establishes that Microsoft shipped a servicing correction addressing the orchestration that decided whether to power off after applying updates. Independent community testing and multiple outlets corroborated that the behavior was corrected in many previously afflicted configurations.
That said, two important caveats deserve emphasis:
- Claims that the bug persisted as a continuous, unbroken decade‑long failure are hard to substantiate. Community complaints concentrated more visibly from 2021–2025, and while user gripes spread over multiple years, asserting an exact decade without vendor telemetry is hyperbolic; treat such timeline claims cautiously.
- The fix targets the orchestration layer, but the global incidence rate (percentage of devices affected) is not publicly disclosed; Microsoft’s internal telemetry remains the source of truth for prevalence. Community reproductions are useful but cannot substitute vendor metrics for scope. If a particular fleet continues to see problems post‑patch, the cause may still be configuration‑specific (drivers, firmware, third‑party agents) rather than a failure of the shipped correction.
Longer term lessons and implications
This episode surfaces broader lessons about large, heterogeneous operating systems and the relationship between user expectations and servicing complexity:
- A seemingly small promise — the label on a power‑menu item — can have outsized consequences for trust and operations. Users expect deterministic behavior from basic controls; when those expectations fail, trust erodes quickly.
- Packaging servicing fixes inside preview bundles that also introduce UX changes increases testing efficiency but raises the risk that unrelated changes will interact in unexpected ways. Rigorous pilot testing and telemetry analysis are essential countermeasures.
- For administrators, the event reinforces well‑worn operational practice: treat preview releases as test artifacts, maintain representative pilot rings, and rely on staged rollouts rather than immediate mass adoption. When in doubt, prioritize stability over immediacy for critical fleets.
Conclusion
The fix for
Update and shut down restores a basic promise: when Windows says it will install updates and power off, the machine should actually power off. Microsoft documented the remediation in Insider release notes and bundled it into the October 28, 2025 optional preview KB5067036, with subsequent Patch Tuesday distribution and follow‑up fixes addressing collateral regressions such as the Task Manager close issue.
For everyday users, the eventual mainstream cumulative will likely deliver the quality‑of‑life improvement quietly and without drama. For administrators and enthusiasts, the correct posture remains pragmatic: validate preview fixes in representative test rings, monitor telemetry and feedback, and adopt the update widely only after confidence is established. The small fix matters because predictability in everyday UI flows matters — and restoring that predictability is a meaningful win for millions of Windows users.
Source: Windows Report
https://windowsreport.com/windows-insider-bug-thats-lingered-for-years-is-finally-getting-fixed/