Windows 11 Update and Shut Down Now Powers Off Deterministically

Microsoft has quietly closed a small but persistent Windows annoyance: the Start‑menu option labeled “Update and shut down” will now, in the scenarios Microsoft targeted, actually power off the PC after applying updates instead of finishing in a rebooted and powered‑on state. This fix landed first in Windows Insider preview builds and was packaged into the October 28, 2025 optional preview cumulative update KB5067036 (OS Builds 26200.7019 and 26100.7019), restoring predictable shutdown semantics that many laptop users, admins, and power‑conscious customers have long demanded.

---

Background / Overview​

For several years a non‑trivial subset of Windows users reported a frustrating mismatch: choosing Update and shut down often resulted in the system installing updates and then returning to a powered‑on state (lock screen or desktop) instead of completing a cold power‑off. That behavior undermined a simple expectation — pick the convenient UI option and leave — and had concrete, measurable consequences: drained laptop batteries, disrupted maintenance windows, and automation failures for shops that relied on deterministic shutdowns. Community troubleshooting and anecdotal records trace reports across forums and feedback channels for multiple Windows 11 update cycles.
Microsoft documented the repair succinctly in the Insider release notes and the KB changelog: “Fixed an underlying issue which could lead ‘Update and shutdown’ to not actually shut down your PC after.” That exact wording appears in the Windows Insider blog posts for the September 29, 2025 preview flights and in the KB5067036 preview page published October 28, 2025. Those are the authoritative artifacts confirming the remediation and its deployment path. Why this mattered in practical terms:

• Laptops left overnight expecting to be off could remain powered on and drain battery.
• Scheduled maintenance or image‑deployed workflows that assume a shutdown could fail or leave systems in an indeterminate state.
• The UI trust model was weakened — when a labeled control doesn't do what it promises, users create workarounds that often reduce update compliance.

Those impacts turned what looks like a small UX bug into a genuine reliability and operational problem for many users and IT teams.

---

Technical anatomy — why “Update and shut down” is more complicated than it looks​

At first glance, the command sounds atomic: install pending updates, then power off. In modern Windows the path is multi‑stage and fragile at a number of handoff points. The key technical elements that explain why the option sometimes behaved like a restart are:

• Fast Startup / Hybrid Shutdown — When Fast Startup is enabled, Windows performs a hybrid shutdown that preserves kernel session state to accelerate boot. That hybrid path changes the semantics of “shutdown” and can interact poorly with offline servicing, producing different end states.
• Multi‑phase servicing — Many updates stage files while Windows is running and then perform offline commits during a shutdown/boot cycle. Some servicing operations require one or more reboots to reach a consistent committed state, and orchestration logic must track whether the user intended a final shutdown or is OK with intermediate reboots.
• Sign‑in / Finish‑after‑sign‑in flows — Windows can use saved credentials to sign in automatically to finish setup after a restart. If that path is blocked or not allowed, servicing logic might prefer a restart or change how it completes post‑update steps.
• Drivers and process handoffs — A driver or running process that must be replaced may force the servicing pipeline to select a restart to guarantee file integrity. OEM agents and third‑party management tools can also alter shutdown sequencing.

These interlocking systems create timing, state, and race‑condition scenarios that made the behavior intermittent and hardware‑dependent: some machines were never affected, others always were, and many behaved inconsistently. That is why reproducing and diagnosing the defect in lab conditions was hard, and why the fix required changes to the servicing orchestration rather than a simple UI label edit.

---

What Microsoft shipped and the timeline​

Microsoft followed a conventional staged path for this repair: validate in Insider flights → include in an optional preview cumulative update → stage for broader rollout after telemetry validation.
Key milestones:

• September 29, 2025 — Windows Insider posts for Dev (Build 26220.6760) and Beta (Build 26120.6760) explicitly listed the fix “Fixed an underlying issue which could lead ‘Update and shutdown’ to not actually shut down your PC after.” This was the first public admission of the remediation in preview notes.
• October 28, 2025 — Microsoft published the optional preview cumulative update KB5067036 (OS Builds 26200.7019 and 26100.7019) which included the same servicing change in its Windows Update changelog. The KB page details the update’s scope and the build numbers it produces.
• Late 2025 (staged) — Microsoft intends to fold the fix into mainstream cumulative updates after validating telemetry and ensuring no widespread regressions, consistent with its Insider → Preview → Patch Tuesday progression. Community posts flagged November as a likely time for the fix to reach general release rings, subject to telemetry.

Those artifacts give us the canonical dates, builds, and packaging for the change and explain how and when users can expect access to the fix.

---

Independent verification and cross‑checks​

The fix is corroborated by multiple independent outlets and community testing:

• Microsoft’s own KB page documenting KB5067036 confirms the improvement and lists OS build numbers.
• The Windows Insider blog entry (September 29, 2025) includes the same remediation text for the relevant preview builds.
• Coverage by wide‑read tech outlets and community boards (Windows Central, TechRadar, and others) reported the fix after confirming the Insider notes and preview packaging.
• Forum and community threads show real users testing the preview packages and reporting improved shutdown behavior when the update is applied.

Taken together, these sources form a consistent public record: Microsoft changed servicing logic in preview, then published the same change in KB5067036 for broader testing. The technical phrasing — “fixed an underlying issue” — indicates the remediation is orchestration‑level rather than cosmetic.

---

Strengths and practical benefits of the fix​

This remediation, while narrow in scope, delivers several immediate and observable benefits:

• Restored trust in a simple UI action. Users who previously avoided Update and shut down can start to rely on the option again where the fix is present, reducing the need for manual workarounds.
• Reduced battery drain for mobile users. Laptops left overnight are now less likely to remain powered on after an update cycle, which conserves battery and reduces thermal wear.
• Fewer failed maintenance windows. IT automation that assumes a deterministic shutdown after applying updates should see improved reliability once the fix propagates into the environment. This reduces administrative overhead and the need for complex scripts.
• A deeper, not cosmetic, remediation. The language Microsoft used indicates engineers adjusted servicing orchestration — carrying the “shutdown after update” intent through offline servicing and multi‑phase commits — which is a more robust engineering approach than merely changing text.

These improvements make a small but meaningful difference in everyday workflows and device sustainability.

---

Risks, regressions, and reasons for caution​

No significant fix ships without tradeoffs. There are clear, documented reasons to proceed cautiously before broad deployment:

• Preview updates are optional and staged. KB5067036 is an optional preview package. Microsoft typically uses these packages to gather telemetry and catch regressions; they are not automatically applied to all systems. Administrators should pilot the update before wide deployment.
• Collateral regressions have already appeared. Multiple outlets and users reported a separate regression in KB5067036 where Task Manager can duplicate itself and become difficult to close, spawning multiple taskmgr.exe instances and consuming resources. That issue was flagged in coverage by The Verge, Tom’s Guide and other outlets and has had user reports on Reddit. That demonstrates the real‑world risk: a fix to one orchestration path can interact with unrelated subsystems and cause new behavior.
• Hardware and driver variability persist. The original bug’s intermittent nature was tied to drivers, OEM software, and Fast Startup behavior. Even with the orchestration change, some combinations of firmware and drivers might still experience different outcomes until device‑level interactions are validated by telemetry.
• Microsoft has not published a detailed root‑cause postmortem. The company’s public changelogs note the behavioral fix but do not enumerate the exact race condition or code path fixed. Any claim about an exact internal cause should be treated as an engineering inference unless Microsoft releases a deeper analysis.

Those caveats explain why Microsoft stages the rollout, why admins should pilot the preview on nonproduction machines, and why users should be alert for new symptoms after installing optional packages.

---

Practical guidance — how to get the fix and how to test it safely​

For power users and IT administrators who want to adopt the remediation or validate it in their environment, follow this structured approach.

• Assess risk and pick test candidates
• Select a small, representative ring of noncritical machines (laptops and desktops with typical drivers and OEM firmware).
• Ensure you have a known good backup or snapshot plan for test machines.
• Install the preview safely
• Join the Windows Insider Program (Beta or Dev channel) or apply the optional preview update KB5067036 via Settings > Windows Update > Optional updates (if available). Note: preview packages are non‑security, optional updates.
• Validate the behaviour
• Reproduce the scenario: stage an update, trigger Update and shut down, and observe the final power state after the post‑install sequence completes.
• Test with Fast Startup enabled and disabled to see whether hybrid shutdown settings affect the outcome.
• Repeat across firmware variations and with common third‑party management agents installed.
• Monitor for regressions
• Watch for unrelated issues after install (for example, Task Manager duplication reported by early adopters). If you see regressions, gather diagnostics (ETW traces, reliability logs) and consider rolling the update back until a follow‑up patch arrives.
• Broaden deployment
• If tests are positive, expand the deployment ring and continue to monitor telemetry for device‑specific anomalies.
• If your environment relies on deterministic shutdown semantics today, consider scheduling the rollout during a maintenance period and maintain rollback procedures.
• Interim workarounds (if you need deterministic shutdown today)
• Use Update and restart, then manually shut down the machine once the restart finishes.
• Disable Fast Startup to reduce hybrid shutdown complexity: Control Panel > Power Options > Choose what power buttons do > Turn off fast startup. Note that disabling Fast Startup may lengthen boot times.

This sequence balances the desire for the fix with a conservative, operationally safe approach.

---

What to watch next​

• Watch Microsoft’s cumulative update schedule (Patch Tuesday) and the Windows release health dashboard for announcements that the fix has been promoted from preview to mainstream. The KB preview page explicitly notes the update’s staged rollout strategy.
• Track follow‑up advisories for the Task Manager duplication regression and other collateral issues; several outlets flagged the taskmgr behavior shortly after KB5067036’s release. Organizations should be prepared to delay adoption if they depend heavily on Task Manager behavior or have resource‑constrained machines.
• Encourage user‑level telemetry and Feedback Hub reports if you pilot the preview; Microsoft uses that telemetry to judge whether a preview fix is safe to promote.

---

Final analysis — a meaningful quality‑of‑life fix, deployed with appropriate caution​

Fixing the Update and shut down orchestration bug is an important, practical win for Windows reliability. It restores a straightforward UI expectation and removes an annoyance that had real battery and automation costs. The public evidence is clear: Microsoft documented the fix in Insider release notes on September 29, 2025 and packaged the same servicing change into the October 28, 2025 optional preview KB5067036 (OS Builds 26200.7019 and 26100.7019). Those published artifacts validate the change and the staged deployment path. That said, the preview release cycle has reminded us of the tradeoffs inherent in complex platform servicing. Early adopters reported an unrelated Task Manager regression tied to KB5067036, and Microsoft’s changelogs do not reveal low‑level root‑cause details. This combination argues for a measured rollout strategy: pilot, validate, monitor telemetry, and expand only when confidence is established. For everyday users the simplest outcome will be quietly positive — once the fix reaches their machine in a mainstream cumulative update, Update and shut down should do what it says on the tin. For administrators, the correct path is to treat KB5067036 as a pilotable preview: test it on representative hardware, verify deterministic shutdown behavior across configurations (Fast Startup on/off, common drivers, management agents), and wait for Microsoft to promote the fix to the general channel before mass deployment.
This change removes a persistent friction point in Windows Update’s UX and — when broadly validated — will save battery, reduce surprises, and restore confidence in a deceptively simple but widely used feature.

---

Source: HotHardware Microsoft Fixes A Frustrating Windows Shutdown Bug That's Lingered For Years

 

[ChatGPT]

Microsoft’s October preview patch that finally fixed the long-running “Update and Shutdown” restart bug has introduced a surprising new regression: closing Task Manager with the window’s Close (X) button can leave behind live taskmgr.exe processes that accumulate in memory and may degrade performance.

Background / Overview​

Microsoft published the optional preview cumulative update KB5067036 on October 28, 2025, shipping OS builds 26100.7019 and 26200.7019 for affected Windows 11 branches. The package bundles a range of UI and servicing changes — notably a fix that preserves the intended behavior of the Update and Shutdown option and a set of Start menu and taskbar visual updates that are being feature‑gated server side.
The fix to the shutdown orchestration addressed a persistent annoyance where selecting Update and shutdown sometimes resulted in an unintended restart rather than a true power‑off. That long‑standing servicing problem appears to be corrected in the preview, and Microsoft intends to include the same correction in the upcoming cumulative distribution once preview validation completes.
Within hours of the preview rollout, however, community testers and independent outlets began reporting a Task Manager lifecycle regression: closing Task Manager with the Close (X) button can leave an underlying taskmgr.exe process running; reopening Task Manager then spawns a new visible instance while the prior one remains resident. Repeating the open→close cycle multiplies the number of running taskmgr.exe processes.

---

What KB5067036 ships (high level)​

• A servicing/orchestration fix that aims to preserve shutdown intent for the Update and Shutdown and prevent unintended restarts.
• UI and shell updates including a redesigned Start canvas, new All Apps views, and taskbar icon visual changes (feature‑flighted server side).
• Adjustments to Task Manager internals intended to improve process grouping and how the UI maps rows to underlying processes.

These changes are being delivered as a staged rollout; installing the preview supplies the updated binaries but server-side gating may delay visible feature exposure on some devices.

---

The original “Update and Shutdown” problem — why it mattered​

For many users and administrators, the risk that Update and Shutdown would restart instead of powering down was more than a minor UX bug. The symptom could:

• Break scheduled maintenance or shutdown‑at‑night workflows.
• Cause unexpected battery drain on laptops.
• Confuse administrative automation that expected a true shutdown semantics.

The orchestration fix in KB5067036 modifies the servicing decision flow so the final shutdown intent is preserved where appropriate, addressing interactions between Fast Startup/hybrid shutdown, multi‑phase servicing, and sign‑in/finish flows that previously tipped the final action toward a restart. Testers who installed the preview report the Update and Shutdown option now behaves correctly in scenarios that previously produced reboots.

---

The new Task Manager regression — symptoms and reproduction​

What users see​

• Open Task Manager (Ctrl+Shift+Esc).
• Close it using the window Close (X) button.
• Reopen Task Manager and inspect the Processes list.

If affected, you will see multiple entries for Task Manager, and the count increases each time you repeat the open→close cycle. The extra entries are not cosmetic — they are real taskmgr.exe processes listed in OS process tables and visible to Process Explorer, tasklist, or Get-Process. Independent reproductions measured each orphaned instance consuming roughly 20–30 MB of RAM in short stress tests; extreme contrived runs (opening/closing ~100 times) have produced totals near 2 GB of RAM consumed by orphaned Task Manager instances.

How to quickly verify whether your machine is affected​

• Press Windows+R → type winver and confirm your build (look for 26100.7019 or 26200.7019 if you installed KB5067036).
• Press Ctrl+Shift+Esc to open Task Manager.
• Close Task Manager with the Close (X) button.
• Reopen Task Manager and check Processes → Background processes; repeat a few times.

If the number of Task Manager entries increases after repeated cycles, the device exhibits the orphaned process behavior.

---

Measured impact and real‑world risk​

• Memory growth: community tests show orphaned taskmgr.exe instances typically consume ~20–30 MB each. On devices where a user or troubleshooting session opens and closes Task Manager repeatedly — or when thousands of endpoints are affected — this can accumulate into noticeable RAM usage and minor CPU polling spikes.
• Performance and battery: The combined memory footprint and periodic CPU sampling from orphaned instances can reduce responsiveness on low‑end devices and marginally impact battery life on portable machines.
• Visibility: Because preview rollouts are staged, the regression is not universal; it reproduces on some systems and not others, suggesting an environmental trigger (driver/service combination, feature gating, or hardware-specific interaction).

This is not a security vulnerability in the classic sense, but it is an operational regression that can degrade troubleshooting workflows and system responsiveness if left unchecked.

---

Technical hypotheses: what likely went wrong​

The update explicitly included a change to Task Manager’s process grouping — code that maps UI rows to underlying process trees and links app entries to their process data. The observed behavior — a Task Manager window closing while the process remains resident — strongly suggests a teardown or lifecycle regression in the close path:

• A background sampling thread, COM object, or performance counter handle may not be terminated or released on window close.
• A reference count or observer registration could be retained by the grouping subsystem, preventing process exit.
• A change in the grouping logic may have altered the order or conditions under which the cleanup path runs, leaving the process resident without a visible UI.

These are plausible, evidence‑based hypotheses drawn from the temporal correlation between the process grouping change and the observed orphan processes. They remain unconfirmed until Microsoft publishes a root‑cause analysis or engineering trace. Treat the teardown explanation as plausible but not definitive.

---

Immediate mitigations and safe workarounds​

If you installed KB5067036 and see the issue, there are conservative, practical steps to prevent resource accumulation and recover quickly.

• Stop using the Close (X) button on Task Manager while the bug persists.
• Use Task Manager’s own End task option to terminate its process tree.
• From an elevated Command Prompt or PowerShell, run the force‑kill command to terminate all Task Manager instances at once:
• Command Prompt (run as Administrator):
• taskkill.exe /im taskmgr.exe /f
• PowerShell (run as Administrator):
• Get-Process -Name taskmgr | Stop-Process -Force (or)
• taskkill /im taskmgr.exe /f
• To inspect running Task Manager instances:
• tasklist | findstr taskmgr (Command Prompt)
• Get-Process -Name taskmgr (PowerShell)
• If orphaned instances have accumulated and are affecting responsiveness, run the taskkill command once and reboot to clear in‑memory state.
• If the optional preview is unnecessary for your environment, uninstall KB5067036 via Settings → Windows Update → Update history → Uninstall updates. Bear in mind that combined servicing packages and SSU/LCU semantics may complicate uninstalls; back up important data before making changes.

---

Guidance for home users, power users and administrators​

Home users and enthusiasts​

• If you value the Update and Shutdown fix now and have a spare/test device: consider installing KB5067036 and validate your workflows on that machine first.
• If stability matters more than preview features: defer the optional preview and wait for the cumulative Patch Tuesday distribution — the preview exists precisely to surface these edge cases.

Power users and IT support specialists​

• Avoid closing Task Manager using the Close (X) button while testing.
• Use taskkill or Task Manager’s End task to remove orphaned instances.
• Use Sysinternals Process Explorer to inspect per‑instance handles, threads, and loaded modules to identify what is keeping a specific taskmgr.exe instance alive.

Enterprise administrators​

• Treat KB5067036 as a preview: stage deployments and validate critical administrative workflows — including Task Manager — in pilot rings before broader rollout.
• If the issue appears across endpoints, open enterprise support cases with Microsoft and attach reproducible steps, winver output, process listings, and recorded reproductions (Feedback Hub’s Recreate is useful).
• Consider blocking optional preview updates on production devices and wait for a general cumulative update patch. Monitor Microsoft’s Release Health dashboard and the KB support page for known‑issue acknowledgments or out‑of‑band fixes.

---

Microsoft’s public posture and likely timeline​

At the time community reporting gained traction, Microsoft’s KB entry for KB5067036 confirmed the builds and described the fixes but did not initially list Task Manager duplication as a known issue. Community pressure and reproducible reports made the regression visible quickly; Microsoft acknowledged symptoms to at least one outlet and provided mitigation guidance while engineering investigates. Given Microsoft’s historical response patterns, a corrective patch is likely to appear either in the November cumulative update or as an out‑of‑band fix if telemetry and impact warrant it. Until a formal root‑cause and patch are published, expect recommended mitigations to be the primary defense.

---

Why this episode matters for Windows servicing and QA​

This sequence — a long‑standing servicing bug is finally corrected, and an unrelated regression is introduced — highlights several recurring truths about modern OS servicing:

• Small subsystem changes can have outsized lifecycle effects. Adjusting process grouping logic is conceptually minor but can alter object lifetime semantics and teardown order.
• Preview channels work. The purpose of optional preview updates is to surface these real‑world edge cases before broad rollout; the staged rollout allowed the regression to be discovered and reported rapidly.
• Operational risk vs. feature benefit tradeoffs. Users who need the shutdown fix now must balance that benefit against the operational risk of a Task Manager regression; enterprises should manage that tradeoff through staged pilot rings.
• Data collection and repro matter. Fast, repeatable reproductions (winver output, proc lists, recordings, ETW/ProcMon captures) help vendor engineering prioritize and fix regressions faster.

---

Checklist: What to do now (concise)​

• Confirm your build via winver (26100.7019 or 26200.7019 → KB5067036 installed).
• If you’re affected, avoid closing Task Manager with the Close (X) button. Use End task or taskkill /im taskmgr.exe /f.
• If you must install KB5067036 on production devices, stage and pilot first; collect repro artifacts.
• Monitor Microsoft’s release channels for an acknowledgement and fix; if the problem is widespread, expect a follow‑up patch.

---

Caveats, open questions and unverifiable claims​

• The root‑cause explanation — that the regression stems from process‑grouping changes leaving references that prevent taskmgr.exe from exiting — is a well‑fitted technical hypothesis based on symptom timing and community traces. However, it remains unverified until Microsoft publishes an engineering post‑mortem or a formal known‑issue description. Treat any definitive cause statements with caution until vendor confirmation is available.
• The measured memory numbers (≈20–30 MB per orphaned instance and contrived totals near ~2 GB) come from community stress tests and independent labs; actual impact will vary by environment and how often Task Manager is opened and closed. These figures are useful for scale estimation but are not a replacement for local verification.

---

Final assessment and recommendations​

KB5067036 delivers an important servicing correction: the Update and Shutdown workflow now behaves as users expect in the tested scenarios. That fix alone reduces a persistent operational headache for laptop users and administrators. However, the Task Manager close‑path regression introduced by the preview underscores why organizations should treat preview updates as test artifacts: they can contain both desired fixes and unintended regressions.

• For most home users and anyone running critical workloads: defer the optional preview and wait for the cumulative distribution that follows validation.
• For power users and testers: install the preview on non‑production devices, reproduce workflows (including Task Manager use), and report findings through Feedback Hub to accelerate a fix.
• For enterprise IT: keep KB5067036 in pilot rings, include Task Manager lifecycle tests in validation suites, and be prepared to rollback the preview where necessary.

The preview channel did its job by exposing an unexpected regression before a broad rollout. The appropriate reaction is measured: use the practical mitigations to protect end users, collect reproducible data for vendor triage, and await Microsoft’s patch cadence for a corrected build.

---

The Task Manager regression is an operational annoyance with measurable impact; the Update and Shutdown fix is a genuine quality improvement. Until Microsoft issues a confirmed root‑cause and a follow‑up patch, users should weigh the benefits of installing KB5067036 now against the mitigations required to avoid orphaned Task Manager processes.

---

Source: GIGAZINE An update has been released to fix the problem of Windows 'Update and Shutdown' failing, but now Task Manager cannot be closed

 

[ChatGPT]

If Task Manager on your Windows 11 PC keeps spawning invisible copies of itself after you click the Close (X) button, you’re dealing with a recently reported duplication bug tied to the optional October 28, 2025 preview update KB5067036; this regression causes multiple background taskmgr.exe instances to accumulate, each using roughly 20–30 MB of RAM and a little CPU, and can be stopped or reversed with several practical workarounds until Microsoft ships a patch.

Background / Overview​

The issue surfaced after the October 28, 2025 optional (preview) cumulative update identified as KB5067036, which brought UI tweaks and a change to Task Manager’s process‑grouping behavior across Windows 11 builds 26100.7019 and 26200.7019. Community testers and multiple independent outlets reproduced a consistent pattern: closing Task Manager with the window Close (X) leaves the process resident in memory, and launching Task Manager again creates an additional process rather than reusing the previous one. Over time the duplicates can add up and affect responsiveness—especially on low‑RAM machines.
This is an optional update (a preview package), not an automatic monthly security rollup, so many users can avoid exposure simply by deferring optional updates on production devices. For those who already applied KB5067036 and are seeing duplicates, there are quick containment steps and more robust remediation options described below.

---

What the bug looks like (quick repro)​

• Open Task Manager (Ctrl + Shift + Esc).
• Close Task Manager using the window Close (X) button.
• Reopen Task Manager repeatedly (5–10 cycles).
• Switch to Processes → Background processes or Details and look for multiple taskmgr.exe entries.

If you discover more than one taskmgr.exe entry after these steps, the device is demonstrating the orphaned Task Manager behaviour. You can also verify via command line: tasklist /FI "IMAGENAME eq taskmgr.exe" or in PowerShell: Get-Process -Name taskmgr.

---

Quick summary of the confirmed facts​

• The regression was reported after KB5067036 (October 28, 2025) and affects Windows 11 builds 26100.7019 and 26200.7019.
• Duplicate taskmgr.exe processes are visible under Processes → Background processes / Details and each instance typically consumes ~20–30 MB of RAM, with occasional small CPU use.
• The problem is reproducible by closing Task Manager with the X button and reopening it repeatedly.
• Microsoft’s KB for KB5067036 initially did not list this duplication symptom as a known issue; community testing surfaced the behavior and produced reproducible mitigation steps while Microsoft investigates.

---

How to check whether you’re affected (step‑by‑step)​

• Press Windows + R, type winver, and confirm your OS build (look for 26100.7019 or 26200.7019 if you installed KB5067036).
• Open Task Manager with Ctrl + Shift + Esc. Close Task Manager using the window Close (X) button.
• Reopen Task Manager and switch to Processes → Background processes, or open Details and search for taskmgr.exe.
• Repeat steps 2–3 several times. If the number of taskmgr.exe entries increases with each cycle, the device is affected.

If your device shows sluggishness or memory spikes correlated to these duplicates, use the immediate remediation steps below.

---

Immediate fixes and workarounds (safe, effective)​

These are the recommended, low‑risk actions to remove orphaned Task Manager instances and prevent further accumulation while waiting for an official patch.

1) Kill all Task Manager instances (fast)​

Open an elevated Command Prompt or PowerShell and run:
taskkill /im taskmgr.exe /f
This forcibly terminates all running taskmgr.exe processes immediately. Use this when you have many orphaned instances or need a scripted, repeatable fix.
PowerShell equivalent:
Get-Process -Name taskmgr | Stop-Process -Force

2) End task manually (GUI)​

• Open Task Manager (Ctrl + Shift + Esc).
• In the Processes tab, expand Background processes, right‑click each Task Manager entry and choose End task.

This is slower if many instances exist, but it’s safe and available to users who prefer a GUI approach. Avoid using the Close (X) button until a patch is released.

3) Reboot (blunt but guaranteed)​

A restart clears all in‑memory orphaned processes. Use reboot if resource usage is impacting system responsiveness and you want a clean state quickly.

4) Use Sysinternals Process Explorer (diagnostic)​

Process Explorer provides better visibility into individual processes, threads, handles and loaded modules. It can be used to inspect orphaned taskmgr.exe instances and kill them without triggering the duplication behavior. This is a good tool for advanced troubleshooting.

---

How to uninstall KB5067036 (rollback the preview)​

If the duplication behaviour is unacceptable on production systems, you can uninstall the optional preview update.

• Settings → Windows Update → Update history → Uninstall updates.
• Find the entry for KB5067036 and choose Uninstall, then restart when prompted.

Important notes and cautions:

• Some packages may be combined SSU (Servicing Stack Update) + LCU; SSUs cannot always be removed independently, and combined-package uninstall semantics can be more complex. Follow the KB’s removal guidance and, for managed fleets, consult your patch management vendor documentation.

If the normal uninstall path isn’t available or the device won’t boot, use Advanced Startup → Troubleshoot → Advanced options → Uninstall Updates, or restore from a System Restore point where available.

---

Enterprise and IT admin guidance​

For organizations, the bug highlights why preview updates should remain staged to pilot rings. Recommended actions:

• Pause deployment of KB5067036 to broad production rings until Microsoft confirms a fix or provides mitigation guidance.
• Deploy detection scripts to find devices with more than one taskmgr.exe instance, e.g.:

tasklist /FI "IMAGENAME eq taskmgr.exe"
Then remediate with taskkill /im taskmgr.exe /f where necessary.

• If the issue affects many machines, collect diagnostics (winver screenshot, ProcMon trace, ETW traces, Process Explorer captures, and a short screen recording of reproduce steps) and open a support case with Microsoft attaching those artifacts. This accelerates triage.
• Validate the fix in a pilot ring that includes heavy Task Manager users (helpdesk, developers, monitoring teams) before a broad rollout.

---

Technical analysis: plausible root causes​

Community analysis and the behavior pattern point to a lifecycle/teardown regression in Task Manager’s shutdown path. Plausible causes include:

• A background monitoring thread or worker that isn’t being shut down correctly on window close.
• A held COM object or a performance‑counter handle (PDH/Perfmon/ETW) that prevents process exit.
• Changes to Task Manager’s process‑grouping logic that altered ownership or reference counting, leaving dangling references that stop full process termination.

These hypotheses fit the symptom (process persists without a visible window and sometimes polls counters), but they remain unverified until Microsoft publishes engineering traces or an explicit root‑cause statement. Advanced diagnostics to confirm include ProcMon traces, ETW captures and Process Explorer thread stacks for orphaned taskmgr.exe instances.

---

Microsoft’s response and timeline expectations​

At the time community reporting surfaced, Microsoft’s KB page for KB5067036 did not explicitly list the Task Manager duplication as a known issue; community repros and telemetry aggregation typically trigger a formal Known Issue Acknowledgement (KIA) and a follow‑up cumulative or out‑of‑band patch when Microsoft confirms impact and reproductions. Monitor the KB entry and Windows Release Health for any KIA or patch notes from Microsoft.
Historically, Microsoft has issued corrections for preview regressions in subsequent cumulative updates when the issue is validated. Given the visibility of this regression among power‑user communities, a vendor remediation is likely, though no firm date has been published at the time of these reports.

---

Optional tweaks and risky workarounds — caution strongly advised​

A few community posts and user threads mention third‑party tooling (for example, ViVeTool) or registry tweaks to enable or disable feature gates that may alter the behaviour of updated components. These approaches come with real risk:

• Tools like ViVeTool are maintained by third parties and alter hidden feature flags; they can produce unexpected behaviour and are not officially supported by Microsoft. If you consider this route, backup your system and registry first, and test on non‑production hardware. (Community reports vary on effectiveness; treat these as experimental).
• Shared .reg files reported on GitHub or forums can contain keys under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FeatureManagement\Overrides... — editing or deleting registry keys without a clear, authoritative source is dangerous. Always export a registry backup before making changes and prefer officially documented remediation.

Flag: Any specific ViVeTool IDs or registry paths claimed to “fix” the duplication should be treated as unverified unless confirmed by multiple trusted vendors or Microsoft itself. Use them only if you accept the risk and can revert changes.

---

Risk assessment — who should be most cautious​

• Home users with modern hardware: low to moderate risk. The issue is annoying but typically manageable with a reboot or the taskkill command.
• Low‑RAM or older laptops: measurable risk. Many orphaned instances can consume significant memory and cause swapping and stuttering.
• Power users, developers, IT pros who open/close Task Manager frequently: high nuisance and potential productivity impact; avoid optional previews on machines used for production troubleshooting.
• Enterprises and managed fleets: operational risk if KB5067036 rolls out broadly. Stage the preview to pilot rings and gather telemetry before broad deployment.

---

Best practices and practical recommendations​

• Defer optional preview updates on production systems. Optional preview builds are intended for testing and can introduce regressions.
• If you already installed KB5067036 and rely on Task Manager heavily, stop using the Close (X) button; instead, use End task inside Task Manager or the taskkill command when needed.
• Script detection and remediation for managed fleets (tasklist + taskkill) until Microsoft publishes a fix.
• Collect precise artifacts if the bug is affecting many clients and open a Microsoft support case — ProcMon, ETW, Process Explorer captures and a short repro video are the most useful.
• Maintain restore points or system images before installing optional updates so you can rollback cleanly if necessary.

---

What we still don’t know (and what to watch)​

• Official engineering root cause: community diagnostics point at teardown/teardown-path issues, but Microsoft has not publicly confirmed the exact object (thread, COM, PDH handle) that prevents taskmgr.exe from exiting. Until Microsoft publishes details, the teardown explanation is a best‑fit hypothesis.
• Distribution scope: because preview updates are staged and feature flags may be server‑gated, not all devices that received KB5067036 will show the same behaviors. Expect variability in repro rates across OEMs, configured software, and drivers.
• Patch timing: Microsoft usually addresses validated regressions in follow‑up cumulative updates or out‑of‑band patches; watch the KB page and Release Health for an official Known Issue Acknowledgement and remediation notes.

---

Checklist — quick actions you can take right now​

• If you don’t need preview features: skip KB5067036 on production machines.
• If already installed and affected: run (Admin) taskkill /im taskmgr.exe /f to clear orphaned processes, or in PowerShell Get-Process -Name taskmgr | Stop-Process -Force.
• Avoid closing Task Manager with the Close (X) button until a fix is published; use End task or Alt+F4 (test if Alt+F4 closes Task Manager cleanly on your device).
• For persistent production issues, uninstall KB5067036 via Settings → Windows Update → Update history → Uninstall updates and escalate to your patch‑management policy.

---

Final assessment​

This Task Manager duplication bug is an irritating but manageable regression introduced by a preview update. It highlights the tradeoffs of early access channels: preview packages let Microsoft and the community catch edge cases before broad deployment, but they can also produce real user‑facing regressions in widely used tooling like Task Manager. The practical mitigations are straightforward—kill the orphaned processes, avoid closing with the X, or roll back the optional update—and Microsoft’s history with similar regressions suggests a corrective update will follow once the vendor confirms repro and impact. Until then, conservative update practices and the simple command‑line or GUI workarounds above will keep desktops responsive and predictable.

---

Conclusion: If you rely on a stable desktop for work, defer optional preview updates like KB5067036; if you’re already affected, reclaim resources quickly with taskkill /im taskmgr.exe /f, avoid the window Close (X), and monitor Microsoft’s KB and Release Health for an official patch.

---

Source: Make Tech Easier How to Fix the Windows 11 Task Manager Duplication Bug - Make Tech Easier