Windows 11 KB5067036 Task Manager Duplicates Bug Explained

A weird regression in a recent Windows 11 preview update is leaving behind “ghost” Task Manager processes every time users close the app with the window Close (X) button, so that each reopen spawns another running taskmgr.exe instance — a behaviour confirmed by community testing and reproduced across multiple systems.

Background​

The issue is tied to an optional, non‑security preview update released on October 28, 2025 — identified as KB5067036, shipping OS builds 26200.7019 and 26100.7019 for Windows 11 versions 25H2 and 24H2. Microsoft’s support page for the update lists a range of functional and UI improvements but does not include a specific known‑issue entry describing Task Manager leaving processes running after being closed. This is not the first time Task Manager has shown odd behaviour after preview updates. A different October 2024 preview (KB5044384) introduced a bug that caused Task Manager to display zero counts for Apps, Background Processes, and Windows Processes when Group by Type was enabled — a problem Microsoft resolved in subsequent cumulative updates (notably KB5046617). That earlier incident demonstrates both the recurrence of Task Manager regressions after servicing changes and the fact that Microsoft has previously issued fixes when the problem was confirmed.

---

What users are seeing (symptoms and reproduction)​

• Symptom in short: open Task Manager (Ctrl+Shift+Esc), close it with the window Close (X) button, then open Task Manager again and inspect the Processes list. A second “Task Manager” process appears in the process list; repeating the open → close cycle increases the number of taskmgr.exe instances.
• Real process, not just UI artifact: independent testers and community members report the orphaned processes show up in the process table, persist in the system until explicitly terminated, and consume memory (tests have recorded roughly 20–25 MB RAM per orphaned taskmgr.exe in stress tests). That accumulation can add up — one reporter opened and closed Task Manager ~100 times as an experiment and observed ~2 GB of RAM consumed by the orphaned instances in total.
• Where they appear: affected Task Manager instances often show under Background processes (not as a top-level App entry), so casual users who look only at the main App list may miss them. Community threads and test videos show users finding multiple taskmgr.exe entries in either the Processes or Details tabs.
• Is it universal? No. The bug appears reproducible on many machines where the preview has been applied, but not every device is affected — suggesting an environmental trigger such as a driver, third‑party service, or feature‑flag gating combined with the staged rollout mechanism Microsoft uses for preview items. Several community threads show mixed results: some machines behave normally while others reliably reproduce the duplication.

---

Technical context: why this might be happening​

Modern Windows applications (including Task Manager) use a lifecycle of window messages and internal shutdown handlers to tear down UI and terminate process threads. A regression that affects the close or cleanup path — for example, a change in how Task Manager groups processes or hooks performance counters — can leave threads, COM objects, or references alive and prevent the process from exiting cleanly. When a new Task Manager instance launches, the old process remains resident and shows up as an additional taskmgr.exe entry. This pattern is consistent with the kinds of lifecycle regressions introduced when UI subsystems are modified.
Diagnostically, the likely culprits are:

• A close handler that fails to post WM_QUIT / WM_DESTROY correctly (or an asynchronous cleanup that never completes).
• A new grouping or monitoring thread that keeps a handle open to a system resource or service, preventing process termination.
• Interaction with third‑party code (security suites, monitoring tools, shell extensions) that hooks into Task Manager or the window manager and prevents normal shutdown.

Those are hypotheses aligned with standard forensic steps used by sysadmins: capture process create/exit events (ETW), take ProcMon traces filtered for taskmgr.exe, inspect thread stacks of orphaned instances, and review loaded DLLs/handles to find references keeping the process alive. Community guidance emphasizes collecting these artifacts before filing a reproducible report with Microsoft.

---

Verified facts and cross‑checks​

• KB5067036 exists and was published on October 28, 2025 (OS builds 26200.7019 / 26100.7019). This is confirmed on Microsoft’s official support pages for the update.
• Independent reporting from technical news outlets and community testing reproduces the Task Manager duplication behaviour and documents resource use per orphaned instance (20–25 MB in tests). Two independent outlets and large community threads have published reproductions and test videos.
• Microsoft’s release notes for KB5067036 list changes to Task Manager’s grouping behavior as a fix, but the vendor has not (as of the latest public update of the KB page) enumerated the duplicate‑process symptom as a known issue. That absence suggests either the company has not yet confirmed the regression publicly for that specific symptom or is investigating. Readers should check the Windows Release Health dashboard and the KB entry for any subsequent known‑issue acknowledgement or out‑of‑band patch.
• A prior, separate Task Manager problem (KB5044384 — October 2024 preview) caused misreported process counts under Group by Type and was later resolved by cumulative updates (KB5046617). That historical precedent confirms Task Manager is a component that has experienced preview‑update regressions before and that Microsoft can and does remediate them.

Note: where community tests report specific resource numbers or reproducibility rates (for example “30% of our VMs showed the issue”), treat those as experimental results from single organizations and not as broad telemetry; such figures are valuable but not necessarily representative of Microsoft’s overall install base unless corroborated by large-scale telemetry or Microsoft statements. Some community claims remain unverified at scale and should be treated with caution.

---

Immediate mitigations and practical workarounds​

For most users the simplest mitigation is to avoid the window Close (X) button and instead use explicit termination commands that remove all Task Manager instances. Options include:

• Use Task Manager’s own End task command to terminate the Task Manager process tree before closing the window. This ensures the process fully exits rather than lingering.
• Kill all Task Manager instances from the command line:
• Open an elevated Command Prompt or PowerShell.
• Run: taskkill /im taskmgr.exe /f
  That forcibly terminates every taskmgr.exe process.
• Use PowerShell to inspect and end instances:
• Get-Process taskmgr
• Stop-Process -Name taskmgr -Force
• Use jump‑list End Task: Windows 11 has an End Task jump list option (right‑click the taskbar icon) which can kill misbehaving apps quickly; this feature is hidden by default in some builds and can be enabled in Settings > Advanced (toggle the End Task option) on systems where the option exists. Community reporting highlights this as a useful, under‑used shortcut. Note: UI locations and names may vary by build and OEM customizations.
• Reboot: If multiple orphaned instances have accumulated and resource use becomes noticeable, restart the PC. That clears all in‑memory processes and restores a clean state.
• Uninstall the preview: If you installed KB5067036 and want to avoid optional preview risk, you can uninstall the update from Settings → Windows Update → Update history → Uninstall updates. Be aware that combined SSU+LCU packages may have more complex rollback semantics; follow Microsoft’s guidance if you plan to remove a servicing update.

Important operational note for admins: because KB5067036 is delivered in a gradual rollout, not every device that receives the package will observe all the new features — and some features are gated server‑side — which complicates reproduction and staged‑deployment decisions. For enterprises, pause or stage the deployment and validate with pilot groups that include users who rely on troubleshooting tools such as Task Manager.

---

Step‑by‑step: how to check if your PC is affected​

• Press Windows+R, type winver, and confirm your OS build (look for 26100.7019 or 26200.7019 if KB5067036 was installed).
• Open Task Manager (Ctrl+Shift+Esc).
• Click the Close (X) button.
• Reopen Task Manager, switch to the Processes tab, and expand Background processes.
• If you see more than one “Task Manager” entry and the count increases each open/close cycle, your machine exhibits the orphaned process behaviour.

If you confirm the behaviour, use taskkill /im taskmgr.exe /f or End Task to clear instances and avoid pressing the window Close (X) until Microsoft publishes a fix.

---

Impact assessment: performance, stability and risk​

• Resource use: each orphaned Task Manager process is small individually (tens of megabytes), but they accumulate quickly with repeated open/close cycles. A few dozen instances could consume hundreds of MB or more, which is noticeable on low‑memory devices and laptops. Tests reporting ~20–25 MB per instance imply that extreme repetition (100 opens/closes) could create gigabytes of waste, but that’s a contrived scenario more likely to affect heavy power‑users or automated scripts that spawn Task Manager.
• CPU / polling: if orphaned instances retain monitoring threads that poll hardware or performance counters, background CPU work can increase, translating into intermittent stutters, battery drain, and reduced responsiveness for foreground apps — several community reports describe measurable game stutters or system hiccups correlated with many orphaned taskmgr.exe processes. These effects are consistent with orphaned processes that continue to execute monitoring loops.
• Operational risk: for IT teams, even a superficially small UI regression can increase support volume, complicate patch windows, and create rollback decisions. The pattern of multiple, unrelated regressions in the same servicing period (previous WinRE and IIS/localhost regressions were reported in the same timeframe) increases the operational cost of a single servicing cycle.

Caveat: community‑sourced performance measurements are useful as indicators but are not a substitute for Microsoft telemetry. Until Microsoft confirms the root cause and publishes telemetry‑based impact, exact rates and device coverage remain estimates. Treat the most severe resource‑consumption scenarios as plausible but low‑probability for typical consumer workflows.

---

What Microsoft has done — and what remains​

Microsoft published the KB5067036 support page listing the update’s fixes and improvements on October 28, 2025, but the KB entry does not explicitly list the Task Manager duplicate‑process behaviour as a known issue at the time of writing. Community reports have been filed on Feedback Hub and discussed widely on forums and Reddit, and independent tech sites have reproduced the behaviour and published reproducible steps and demonstrations. That combination — community repro + public KB without a direct acknowledgement — typically precedes a vendor investigation and, if confirmed, a known‑issue acknowledgement (KIA) and patch or an out‑of‑band fix. Check Microsoft’s Release Health dashboard and the KB page for updates. Historically, Microsoft has resolved related Task Manager issues — recall the KB5044384 / KB5046617 sequence in late 2024 — which means a timely remediation is plausible if the problem reproduces in Microsoft’s telemetry and engineering tests. However, the timeline for a fix can vary based on root cause complexity, required code‑signoff for servicing branches, and the rollout model (preview vs security cumulative).

---

Recommendations (home users, power users, IT administrators)​

• Home users and power users:
• If you rely on stability over preview features, avoid installing optional pre‑release preview updates (uncheck “get the latest updates as soon as they’re available” if you don’t want preview content) and wait for the next cumulative/security update that includes validated fixes.
• If you already installed KB5067036 and see the symptom, use taskkill /im taskmgr.exe /f or reboot to clear orphaned instances and avoid pressing the window Close (X) until the issue is resolved.
• Consider using Sysinternals Process Explorer as an alternative when you want fine‑grained process control (it won’t trigger the Task Manager duplication and lets you inspect handles and threads). Community recommendations frequently suggest Process Explorer as a robust troubleshooting alternative.
• IT administrators and enterprises:
• Pause broad rollout of optional preview updates and restrict them to pilot groups that include helpdesk and developer users who often use Task Manager.
• If the update is already in production rings and the behaviour is widespread, stage a rollback for affected clusters following Microsoft’s uninstall guidance for combined packages, and open a support case with Microsoft including ETW traces and ProcMon captures.
• Update internal acceptance tests to include lifecycle scenarios like open/close cycles for system utilities (Task Manager, Explorer) — these are simple tests that catch regressions in close/exit paths.

---

QA lessons and broader takeaways​

This regression is an object lesson in update risk management for complex OSes:

• Small UI changes (process grouping refinements, performance UI changes) can interact unpredictably with lifecycle code and third‑party hooks.
• Preview and gradual rollout models reduce exposure but complicate reproducibility and user expectations when features are gated server‑side.
• Inclusion of basic lifecycle tests in automation (open/close, restart, graceful shutdown) is essential: the “close” path is exercised by every user and must be part of regression suites.
• Communication is key: Microsoft’s previous handling of Task Manager issues shows that timely known‑issue acknowledgements and clear guidance reduce confusion and support load. Until Microsoft publishes a KIA or fix, users and admins must rely on documented mitigations and restart/rollback choices.

---

Final notes and how to stay informed​

If you're tracking whether your device is affected:

• Confirm the installed build (winver) and KB number (KB5067036 for the October 28, 2025 preview).
• Check the Windows Release Health dashboard and the KB support page for any known‑issue entry or follow‑up patch that addresses Task Manager behaviour.
• Monitor community threads (Feedback Hub, Reddit, Windows forums) for reproducible test cases and remediation experiences; share ETW/ProcMon captures with Microsoft support if you open a case — those artifacts accelerate triage.

This regression is irritating and surprising because Task Manager is one of Windows’ most fundamental utilities, but the problem — while potentially disruptive in pathological cases — has practical mitigations (End task, taskkill, reboot, uninstall preview) and a reasonable precedent for a vendor fix based on history. Until Microsoft publishes a confirmed root‑cause and patch, treat the issue seriously on sensitive systems (especially low‑memory laptops and production endpoints) and apply the containment and rollback steps outlined above.

---

In short: a recent optional preview update (KB5067036) has introduced a Task Manager close‑path regression that can leave multiple taskmgr.exe processes running; avoid closing Task Manager with the X, use End task or taskkill to clear instances, consider uninstalling the preview if you need guaranteed stability, and watch Microsoft’s release pages for a formal fix.

---

Source: Neowin Odd Windows 11 bug duplicates Task Manager process instead of closing it

Microsoft’s latest optional preview for Windows 11, KB5067036, has delivered a visible Start menu refresh and other small improvements — and, for a subset of users, a nagging regression that leaves Task Manager processes alive after you click the window Close (X) button, spawning multiple resident taskmgr.exe instances that quietly consume RAM and CPU until explicitly killed.

Background​

Windows servicing windows often include optional, non‑security “preview” cumulative updates that blend functional tweaks, quality fixes, and staged feature rollouts. KB5067036 was published on October 28, 2025 as a preview (OS builds 26200.7019 and 26100.7019) and advertises a redesigned Start menu, updated battery indicators, File Explorer improvements and fixes to Task Manager grouping logic. Microsoft’s official support notes list the changes but — at the time community reporting spiked — do not enumerate a Task Manager close‑path regression as a known issue. That combination — a preview release plus staged server‑side gating for some features — is intended to give Microsoft wider telemetry while limiting user exposure. The downside is predictable: preview code sometimes hits real‑world edge cases only revealed once a larger, more diverse audience exercises it. The Task Manager symptom is an example of such an edge case: it’s reproducible on many affected machines but not universal, which points to environmental or staged‑flag triggers.

---

What users are seeing (symptoms and reproducibility)​

A simple reproduction​

• Press Ctrl+Shift+Esc to open Task Manager.
• Click the window Close (X) button.
• Reopen Task Manager and open the Processes view.

If you see more than one “Task Manager” entry — and the count increases each time you repeat open → close — your device is exhibiting the orphaned taskmgr.exe behaviour. Independent tests and community reports reproduce this by repeating the open/close cycle just a few times.

How it manifests​

• Each orphaned taskmgr.exe is a real process listed in Process Explorer, Task Manager’s Details tab, or via Get‑Process/tasklist. They frequently appear under Background processes.
• Typical memory usage per orphaned instance in community tests is modest (~20–30 MB), but repeated opens can accumulate into hundreds of megabytes or more — one lab reproduction reported ~2 GB after 100 open/close cycles. That accumulation can matter on low‑RAM systems.
• Some users report visible CPU polling effects, battery impact, UI stutters, and slower app launches when many orphaned instances accumulate. These effects are consistent with orphaned processes that continue monitoring system counters.

Scope and variability​

This isn’t a universal failure — many machines receive and run the preview update without incident. The mixed results across machines suggest an environmental trigger (drivers, third‑party hooks, specific telemetry or feature flags) or a staged server-side enablement interacting with local configuration. Treat community percentages and lab repro counts as early telemetry, not as representative telemetry across Microsoft’s entire install base.

---

Why it likely happened (technical hypothesis)​

The KB notes specifically mention a fix to Task Manager’s process grouping behavior — a plausible origin for a regression in Task Manager’s lifecycle code. Modern Task Manager performs two kinds of work: the UI thread that draws windows and a background monitoring thread or threads that sample performance counters, query performance objects, and marshal data to the UI. If a change to grouping logic altered object ownership, reference counting, or background thread lifetime, the close handler might tear down the window but leave a monitoring thread or referenced COM object alive, preventing process termination. When you reopen Task Manager, a new process can start while the prior monitoring thread remains resident, appearing to the user as a duplicated Task Manager.
Diagnostic evidence that supports this hypothesis includes:

• Orphaned taskmgr.exe entries appearing as Background processes (indicating UI was torn down but process persisted).
• Historical precedent: Task Manager regressions after preview servicing are not unprecedented — previous preview updates produced Task Manager oddities that were fixed in follow‑up cumulative updates.

Caveat: until Microsoft publishes a post‑mortem or a known‑issue acknowledgement that describes the exact root cause, the technical explanation remains a well‑fitted hypothesis based on how Windows lifecycle code typically fails. Treat it as informed conjecture pending vendor confirmation.

---

Immediate mitigation — fast, safe steps for users​

If you already installed KB5067036 and see the symptom, these mitigations are quick and reliable.

• Stop using the window Close (X) button to exit Task Manager. Instead, use:
• Task Manager’s End task to terminate the process tree for Task Manager, or
• An elevated Command Prompt / PowerShell and run:
  taskkill /im taskmgr.exe /f
  This forcibly terminates all taskmgr.exe instances at once.
• PowerShell alternatives:
• Get‑Process -Name taskmgr | Stop‑Process -Force
• Get-Process taskmgr (to inspect running instances first)
• Use Sysinternals Process Explorer for fine‑grained inspection and killing if you prefer. It exposes handles, threads, and loaded DLLs to help identify what’s keeping the orphaned process alive.
• If many orphaned instances have accumulated and the system feels sluggish: run the taskkill command, then reboot to completely clear in‑memory state. If problems continue, consider uninstalling KB5067036 (instructions below).

These mitigations are blunt but effective: they prevent resource accumulation while you await a supported fix. Community reports emphasize these actions as the practical containment options today.

---

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

• Press Windows+R, type winver, and confirm the build (KB5067036 corresponds to builds 26200.7019 / 26100.7019).
• Open Task Manager (Ctrl+Shift+Esc).
• Close with the X and then reopen.
• Inspect Processes → Background processes. If multiple “Task Manager” entries appear and increase each cycle, your device is affected. Alternatively run in an elevated command prompt:
  tasklist /FI "IMAGENAME eq taskmgr.exe"
  or in PowerShell: Get‑Process -Name taskmgr.

If you confirm the behaviour, use taskkill /im taskmgr.exe /f or End task to clear instances and avoid pressing the Close (X) until Microsoft issues a fix.

---

How to uninstall KB5067036 (rollback the preview)​

If the preview regression materially impacts productivity, you can remove the optional update — but be aware combined SSU+LCU packages require care:

• Open Settings → Windows Update → Update history → Uninstall updates.
• Find the Windows update that matches KB5067036 and choose Uninstall. Reboot when prompted.

Important operational note: KB5067036 is a combined servicing stack update (SSU) plus LCU in some packaging variations. The SSU portion is not removable via wusa.exe. If the combined package was installed, DISM /Remove‑Package with the LCU name may be required to remove the LCU portion. Follow the KB article’s removal guidance for the exact package semantics. If the uninstall option is unavailable or the device won’t boot normally, use Advanced Startup → Troubleshoot → Advanced options → Uninstall Updates, or restore from a System Restore point if one exists.

---

For power users and IT teams: diagnostics & reporting checklist​

If you are an IT pro, helpdesk engineer, or developer who needs to escalate the issue constructively to Microsoft, collect the following artifacts — they accelerate triage:

• Winver screenshot and the exact build number.
• ProcMon traces filtered for taskmgr.exe capturing process create/exit events.
• ETW traces for process/thread lifetime.
• A short screen recording that demonstrates open → close → reopen and the increasing taskmgr.exe count.
• Tasklist / Get‑Process output showing multiple taskmgr.exe entries.
• Process Explorer capture showing loaded modules, handles, and thread stacks of orphaned taskmgr.exe instances.

Open a Feedback Hub entry using the “Recreate” feature (attach traces and the recording) and, for enterprise customers, open a Microsoft support case and attach the artifacts. Include hardware, driver inventory, and any third‑party security or monitoring software that could be hooking performance counters. The more precise your repro and the artifacts you attach, the faster Microsoft can triage.

---

Administrative guidance: rollout, staging, and remediation at scale​

• Pause or stage preview deployments to pilot rings that include helpdesk and developers who frequently use Task Manager. Avoid installing optional preview updates broadly on production devices.
• If machines in production are affected, enforce remediation scripts (a one‑line taskkill) via management tooling (Intune, SCCM, or your RMM) to clear instances and prevent resource accumulation while awaiting a vendor fix. Add a health check that reports multiple taskmgr.exe instances so remediations can be automated.
• Update acceptance test suites to include lifecycle tests (open/close cycles) for system utilities — these are simple tests that often catch close/exit regressions during preproduction validation.

---

Risk analysis — what this incident exposes​

Strengths:

• KB5067036 does include tangible improvements (Start menu redesign, battery icon updates, File Explorer enhancements) that will benefit many users once the staged rollout completes. Microsoft’s notes list these across Copilot+ and general Windows 11 experiences.

Risks and operational cost:

• Preview updates can expose production users to regressions. The Task Manager duplication is a low‑probability but high‑annoyance regression for power users and helpdesk teams. Regressions of this type increase support volume and rollback considerations for IT teams.
• The mixed nature of staged rollouts and feature gating complicates reproduction and triage, since two identical devices can behave differently depending on server‑side flags and installed feature flights.

Caveats:

• Community experiments (percentage of VMs affected, exact memory per instance) are valuable early signals but should be treated cautiously until vendor telemetry or a broad independent study verifies them. Some community reports cited ~20–30 MB per instance and test runs giving 30% reproduction in a small VM set — these are useful but not representative of global impact without Microsoft telemetry.

---

What Microsoft has said (and what to watch)​

Microsoft’s KB article for KB5067036 documents the update’s features and explicitly states “Microsoft is not currently aware of any issues with this update” at publication, but community reporting soon surfaced the Task Manager duplication symptom across forums and independent tech outlets. Historically Microsoft has used the Windows Release Health dashboard and KB updates to publish known‑issue acknowledgements and out‑of‑band fixes; given the visibility of this regression among power‑user communities, an acknowledgement and a remediation package are plausible once Microsoft verifies repro and impact. Check the KB page and Windows Release Health for updates.

---

Practical checklist — what to do right now​

• If you don’t need preview features, delay installing optional updates. Disable “get the latest updates as soon as they’re available” if you prefer stability.
• If KB5067036 is already installed and you notice duplicates: avoid the Close (X), use End task, or run taskkill /im taskmgr.exe /f to clear instances. Reboot if necessary.
• If you run critical infrastructure, pause rollout and stage the update only to pilot groups that include support staff. If the issue is widespread, stage a rollback following Microsoft’s uninstall guidance for the combined packages.
• Collect repro artifacts (ProcMon, ETW, Process Explorer captures) and file comprehensive Feedback Hub reports or support cases to accelerate remediation.

---

Final assessment​

KB5067036 brings useful UX polishing and bug fixes to Windows 11’s Start menu, File Explorer, and Taskbar, but the Task Manager duplication regression is a stark reminder that even small lifecycle‑path changes can ripple into core tooling. The community has identified reliable mitigations (avoid the Close button, use End task, or run taskkill), and Microsoft’s prior history with Task Manager regressions suggests the vendor will remediate once sufficient telemetry and reproducible reports are collected. Until Microsoft issues a confirmed fix, the prudent approach for most users is straightforward: skip optional preview updates on production systems, use the kill/End task workaround if affected, and deploy preview packages only in a staged pilot that includes power users and support staff.
This incident also yields practical lessons: simple lifecycle tests (open, close, restart) should be part of both vendor and enterprise acceptance suites; comprehensive artifact collection speeds vendor triage; and staged rollouts should weigh feature exposure against operational risk for management tooling that depends on core utilities such as Task Manager.

---

If you are experiencing this behavior right now: run taskkill /im taskmgr.exe /f to reclaim resources, avoid closing Task Manager with the X until a supported patch is available, and follow official Microsoft channels for the KB5067036 support article for any subsequent fixes or known‑issue updates.

---

Source: BizzBuzz Windows 11 Update Bug: Task Manager Won’t Close – Fix It Now

The latest Windows 11 preview update has introduced a baffling Task Manager regression that can leave multiple invisible copies of taskmgr.exe running after you click the window “X,” creating a slow, hard‑to‑diagnose resource leak for affected users and raising fresh questions about preview rollout practices and QA for lifecycle code paths.

Background​

Microsoft published the October 28, 2025 optional preview cumulative update, identified as KB5067036 (OS builds 26200.7019 and 26100.7019), as a non‑security update for Windows 11. The package bundles visible UI changes — notably a redesigned Start menu and taskbar battery refinements — alongside multiple reliability and quality fixes. Within days of the rollout, community testers and independent publications began reporting a reproducible regression: closing Task Manager using its window Close (X) control sometimes fails to terminate the process. Instead, the previous taskmgr.exe instance remains resident in the background and additional launches spawn fresh instances, so repeated open→close cycles accumulate “ghost” Task Manager processes. Multiple groups have reproduced the behavior and documented the symptom and its practical impact.

What users are seeing — the symptom in plain terms​

• Open Task Manager with Ctrl+Shift+Esc.
• Click the top‑right Close (X) button to dismiss the Task Manager window.
• Reopen Task Manager and open the Processes view: you may now see more than one “Task Manager” entry.
• Repeat the open→close cycle and watch the count grow; each orphan is a real taskmgr.exe process consuming system resources until explicitly killed.

Independent tests show each orphaned taskmgr.exe typically consumes modest memory (reports commonly cite ~20–30 MB per instance) and may perform periodic polling of system telemetry, creating cumulative CPU churn if many copies pile up. In contrived tests where Task Manager was opened and closed dozens or hundreds of times, testers reported multi‑hundred‑megabyte to multi‑gigabyte memory use from the orphaned processes — noticeable on low‑end or memory‑constrained devices.

Why this matters​

Task Manager is a fundamental troubleshooting and management tool used by helpdesk staff, developers, and power users. A regression that silently allows multiple background instances to accumulate undermines diagnostics and can degrade system responsiveness, battery life, and perceived stability. For service teams that rely on Task Manager as a first‑line tool, this issue raises operational risk and support overhead. Community threads show frustrated users and admins reporting the issue across consumer and preview channels.

---

Technical context and likely cause (what the evidence suggests)​

The KB release notes explicitly mention changes intended to improve Task Manager’s process grouping and how app entries map to underlying processes. That same subsystem touches process enumeration, UI mapping and lifecycle handling — a plausible nexus for a regression in the close/shutdown path. Community forensic analysis and developer hypotheses point to the shutdown flow being interrupted by retained references (timers, worker threads, COM objects, or open handles) that keep a taskmgr.exe process alive even after the UI window is destroyed. When a new Task Manager window opens, it launches a fresh process while the old one remains resident. Important caveat: Microsoft has not (at the time of reporting) published a vendor post‑mortem with the exact root cause and engineering fix description. The explanation above is an informed hypothesis consistent with typical lifecycle regressions and community diagnostics; it should be treated as plausible but unconfirmed until Microsoft publishes a formal engineering statement.

How to verify whether your machine is affected​

1. Press Windows+R, type winver, and confirm the OS build (look for 26100.7019 or 26200.7019 if KB5067036 is installed).
2. Open Task Manager (Ctrl+Shift+Esc).
3. Click the window Close (X) button to close Task Manager.
4. Reopen Task Manager and open Processes → Background processes (or Details).
5. If you see more than one “Task Manager” and the count increases each time you repeat open→close, your device is exhibiting the orphaned taskmgr.exe behavior.

Alternatively, inspect active processes from a command line:

• PowerShell: Get-Process -Name taskmgr
• Command Prompt: tasklist /FI "IMAGENAME eq taskmgr.exe"

These commands show the number of resident taskmgr.exe processes without relying on the Task Manager UI itself.

---

How to safely exit Task Manager (mitigations and fixes you can use now)​

Until Microsoft issues an official patch, avoid using the Close (X) button to exit Task Manager on affected builds. Use one of the following safer methods to terminate Task Manager instances:

1. End Task from within Task Manager
   • Open Task Manager (Ctrl+Shift+Esc).
   • In Processes, select the Task Manager entry (or entries) and click End task. This terminates the process tree cleanly.
2. Restart File Explorer (desktop refresh)
   • In Task Manager, locate Windows Explorer under Processes, right‑click and choose Restart. This often clears orphaned Task Manager entries while refreshing the desktop shell.
3. Force‑kill all Task Manager instances from an elevated prompt
   • Open Command Prompt (Admin) or PowerShell (Admin).
   • Run: taskkill /f /im taskmgr.exe
   • PowerShell alternative: Get-Process -Name taskmgr | Stop-Process -Force
     This forcibly kills all taskmgr.exe processes at once and is the fastest way to clear many orphans.
4. Use Sysinternals Process Explorer as an alternative monitoring tool
   • Process Explorer will not trigger Task Manager’s close path and provides fine‑grained control for killing individual processes and inspecting handles/threads. It’s a good temporary replacement for heavy diagnostics.
5. Reboot or uninstall the optional preview
   • If performance is materially affected, rebooting clears in‑memory processes. If you prefer not to live with the risk, uninstall KB5067036 via Settings → Windows Update → Update history → Uninstall updates, following the KB guidance for combined SSU/LCU semantics if necessary.

Practical note: Some community testers report that End task itself may leave one residual instance in certain ordering scenarios, so the taskkill approach is the most brute‑force but reliable remedy. Always run these commands with care and, when possible, collect diagnostics before rebooting if you plan to open a formal support case.

---

Operational impact — who should care and what to do​

• Home users and power users: If you selected optional preview updates for early features and are comfortable with staged risk, you can remain on the preview ring but avoid closing Task Manager with the X and use the mitigations above. If stability is paramount, uninstall the preview until Microsoft confirms a fix.
• Help‑desk and support teams: Task Manager is an essential tool. Include Task Manager open/close lifecycle checks in your acceptance tests for preview updates, and advise helpdesk staff about the safe procedures (End task, taskkill) so they don’t inadvertently escalate a performance ticket due to ghost taskmgr.exe processes.
• Enterprises and IT admins: Treat KB5067036 as a preview release — stage it in pilot rings that include helpdesk machines and diagnostics users before broadly deploying. If the behavior appears across endpoints, consider rolling back the preview in affected clusters and open a Microsoft support case with repro artifacts. Preserve rollback/restore plans and ensure update governance blocks preview channel options on production devices until the package stabilizes.

---

Diagnostics checklist — what to collect before filing a support case​

If you need to escalate the issue to Microsoft or your vendor support, collect these artifacts to speed triage:

1. Winver screenshot showing exact build and KB number (look for 26100.7019 / 26200.7019).
2. A short screen recording demonstrating the open → close → reopen sequence and the increasing taskmgr.exe count.
3. ProcMon trace filtered for taskmgr.exe capturing process create/exit and handle activity.
4. ETW traces for process create/exit events and performance counter polling.
5. Get‑Process / tasklist output showing multiple taskmgr.exe entries, and Process Explorer handle/DLL lists for orphaned processes.
6. Environment inventory: third‑party security suites, shell extensions, GPU and chipset driver versions, and any monitoring tools that might hook process lifecycle APIs.

Attach these artifacts to a Feedback Hub entry (use the Recreate feature) or an enterprise support ticket to accelerate Microsoft’s engineering triage. Community threads show that detailed reproducible traces greatly reduce time‑to‑fix for lifecycle regressions.

---

Analysis: strengths, risks, and QA lessons​

Strengths in the KB release​

KB5067036 contains meaningful user experience improvements and quality fixes: a modernized Start menu with scrollable All apps, more informative battery icons, File Explorer convenience improvements, and other functional patches that address known pain points. These are legitimate, positive changes for Windows 11 users, particularly for Copilot+ PCs where discoverability and on‑device AI features matter.

Risks and immediate concerns​

• The Task Manager close regression is a classic example of how a focused fix to a subsystem (process grouping and UI mapping) can ripple into lifecycle code and break an essential path. The bug is subtle because it may not appear on all machines, which complicates detection and increases the odds it reaches users during a staged rollout.
• Silent accumulation of background processes can degrade battery life and responsiveness without immediate visibility for users who don’t inspect Background processes or run tasklist/Get‑Process checks. That makes the issue particularly insidious on low‑memory laptops or busy helpdesk endpoints.
• Preview updates are intentionally more permissive in their staging, but the incident underscores the need to prioritize close/exit lifecycle testing in automation and manual validation suites — the “close” path is exercised constantly and must be part of regression checks.

QA lessons to carry forward​

• Add explicit open/close lifecycle tests for system utilities (Task Manager, Explorer, Settings) to continuous test pipelines.
• Increase coverage for process teardown, COM object cleanup, and performance counter handle release in unit/integration tests.
• Make rollout telemetry and Feedback Hub repro artifacts easier to correlate with engineering traces so high‑impact regressions can be triaged faster.

---

Recommended immediate response plan (concise)​

1. Confirm whether KB5067036 is installed (winver).
2. If affected and you rely on Task Manager frequently, avoid closing with the X and adopt taskkill /f /im taskmgr.exe or End task until Microsoft publishes a patch.
3. For production systems, pause preview updates and only permit them on pilot devices with helpdesk users. Review and update rollback procedures for quick remediation.
4. File a Feedback Hub entry with reproducible steps and attach diagnostic artifacts; escalate with Microsoft support for enterprise customers.

---

What to expect next (timeline and vendor behavior)​

Preview updates exist to surface precisely these kinds of environment‑specific regressions. Historically, Microsoft has issued out‑of‑band or next‑cumulative fixes for high‑impact regressions when reproducible reports and telemetry accumulate rapidly; the community consensus is that a patch is likely once Microsoft confirms the issue from telemetry and repro cases. However, until Microsoft publishes a known‑issue acknowledgement (KIA) or an engineering update, treat the root‑cause discussion as speculative. Monitor the official KB page and Windows Release Health dashboard for updates.

---

Final assessment and pragmatic advice​

This Task Manager regression is annoying and potentially impactful, but it is also the kind of bug preview updates are designed to catch before broader distribution. The practical mitigations are straightforward: don’t use the X to close Task Manager, use End task or taskkill, and uninstall the preview if you require stable behavior immediately. For IT teams, the incident is a reminder to treat preview channels as exactly that — preview — and to include essential management utilities in acceptance test plans. For everyday users: if you rely on Task Manager regularly, apply the safe exit methods described here and monitor the Windows Update history and Release Health pages for a corrective patch. For admins: stage the update, gather repros and diagnostics from affected endpoints, and use those artifacts to accelerate vendor triage if rollbacks are required.
The fix is likely to be a targeted correction to Task Manager’s teardown logic and should arrive in a cumulative or out‑of‑band servicing update once Microsoft confirms and reproduces the failure mode — but until then, the mitigations above are the simplest route to a stable desktop experience.

---

The Task Manager duplicate processes bug is an awkward reminder that even small UI or grouping changes can break the most basic lifecycle paths in a complex operating system; careful staging, rigorous lifecycle tests, and fast triage of reproducible traces remain the best defenses against regressions that quietly eat resources.

---

Source: Techweez Windows 11 Preview Update Triggers Strange Task Manager Glitch

Microsoft’s optional October preview update (KB5067036) delivered a redesigned Start menu and other UI tweaks — and, for a subset of devices, a troubling Task Manager regression that can leave multiple taskmgr.exe processes running in the background after you click the window “X”.

Background / Overview​

Windows 11’s KB5067036 (OS builds 26200.7019 and 26100.7019) was published as an optional, non‑security preview on October 28, 2025. The package includes Start menu and Taskbar improvements along with fixes to Task Manager’s process‑grouping behavior. Microsoft lists the update as a staged rollout and notes that, at publication time, it was not aware of any known issues in the package. Shortly after rollout, community testers and independent outlets began reporting a reproducible issue: closing Task Manager with the top‑right Close (X) button does not always terminate the running taskmgr.exe process. Reopening Task Manager in that state spawns another instance, producing multiple resident taskmgr.exe processes that persist until explicitly terminated. Independent reproductions indicate the symptom is real (not a UI artifact) and can accumulate measurable memory and CPU usage in pathological cases.

---

What the bug looks like — a concise symptom guide​

• Open Task Manager with Ctrl+Shift+Esc.
• Close the Task Manager window using the Close (X) button.
• Reopen Task Manager and look at Processes → Background processes.
• If affected, you’ll see more than one “Task Manager” entry; repeat the open → close cycle and the count can increase each time.

Community reproductions show the orphaned entries are listed as live processes (taskmgr.exe) and consume memory until killed or the system is restarted. One lab test repeated open/close cycles ~100 times and reported aggregated memory use on the order of gigabytes — an extreme stress test, but a clear demonstration that repeated opens can accumulate resource usage. These measurements come from community testing and are not Microsoft telemetry; treat them as experimental indicators rather than definitive per‑device metrics.

---

Official status and timelines​

Microsoft’s KB article for KB5067036 confirms the builds and features and reiterates the staged rollout approach, but as of the KB’s published text Microsoft did not list this Task Manager duplication as a known issue. Staged rollouts and server‑side gating mean not all devices will show the same feature set or behavior immediately, which complicates reproduction and reporting. Watch the Microsoft Release Health dashboard and the KB support page for updates and any known‑issue acknowledgement or out‑of‑band patch. Community reporting tends to surface these regressions fast; historically Microsoft has issued corrective updates in follow‑up cumulative updates or out‑of‑band patches when a regression is confirmed and impactful. Given that KB5067036 is a preview (optional) update, many users can simply defer installation on production systems until Microsoft verifies fixes.

---

Why this likely happened (technical analysis)​

A plausible and evidence‑based hypothesis is that a Task Manager change in KB5067036 — specifically the process‑grouping logic — altered the shutdown or teardown path so that window destruction does not fully stop background monitoring threads, COM objects, or other references. In modern Task Manager, the UI thread and one or more background threads sample system counters and marshal telemetry; if the close handler fails to stop or release those background resources, the process can remain resident without a visible main window. Launching Task Manager again spawns a fresh process, while the prior one lingers — producing the duplicate/resident entries seen by testers.
This class of lifecycle bug is consistent with prior preview update regressions and with the KB’s stated modification to grouping behavior. However, the exact root cause (which internal object or thread is retained) requires vendor engineering traces, ETW captures, and ProcMon traces to confirm. Until Microsoft publishes an explicit post‑mortem, treat the shutdown‑path explanation as a well‑fitted hypothesis rather than a confirmed diagnosis.

---

Immediate user mitigations — practical, safe steps​

If your machine exhibits the behavior, the community and support guidance converge on a small set of blunt but reliable mitigations:

• Use Task Manager’s own End task instead of clicking the Close (X) button. Select the Task Manager entry in Processes and click End task to ensure it terminates its process tree.
• Kill all Task Manager instances from the command line (fast and effective):
  1. Open an elevated Command Prompt (or PowerShell).
  2. Run: taskkill /im taskmgr.exe /f
• PowerShell alternative:
  1. Get-Process -Name taskmgr | Stop-Process -Force
• Use Sysinternals Process Explorer if you want per‑instance handles, threads, and loaded modules to investigate what is keeping a specific instance alive.

If many orphaned instances have accumulated and system responsiveness is affected, run the taskkill command once and reboot to clear in‑memory state. If the optional preview is not required, uninstalling KB5067036 is another option (see Uninstall section below).

---

Step‑by‑step verification: check if you’re affected​

1. Press Windows+R, type winver, and confirm your OS build number matches one of the KB5067036 builds (26100.7019 or 26200.7019) if you installed the preview.
2. Press Ctrl+Shift+Esc to open Task Manager.
3. Close Task Manager with the Close (X) button.
4. Reopen Task Manager and inspect Processes → Background processes.
5. If you see multiple “Task Manager” entries and the number increases after repeated open/close cycles, your device demonstrates the orphaned process behavior.

Alternative command‑line verification:

• Command Prompt: tasklist /FI "IMAGENAME eq taskmgr.exe"
• PowerShell: Get‑Process -Name taskmgr

These commands list active taskmgr.exe instances so you can verify whether the processes persist after closing the window.

---

Uninstalling KB5067036 (rollback guidance and caveats)​

If you installed KB5067036 and need to revert to a prior state:

• Settings → Windows Update → Update history → Uninstall updates.
• Find the update that matches KB5067036 and select Uninstall, then reboot when prompted.

Important caveats:

• KB5067036 is delivered as a combined Servicing Stack Update (SSU) plus LCU in some packaging variations. The SSU portion of a combined package is not removable with wusa.exe; to remove the LCU portion you may need DISM /Remove‑Package with the LCU package name. Use DISM /online /get-packages to see installed packages and their names. Microsoft documents this behavior in the KB.

If the system will not boot normally, use Advanced Startup → Troubleshoot → Advanced options → Uninstall Updates, or restore from a System Restore point if available. For enterprise image‑based rollbacks, follow established deployment rollback processes.

---

Enterprise impact and recommended actions for IT teams​

Task Manager is a core diagnostic utility used by support teams, developers, and automated tooling. A regression that affects a diagnostic tool can increase support load, lengthen MTTR, and introduce confusing telemetry.
Recommended enterprise steps:

• Pause optional/preview update deployment for production rings until vendor confirmation and a fix are available.
• Validate KB5067036 in a pilot ring that includes users who rely on Task Manager and other diagnostics. Include lifecycle tests that exercise open/close cycles, process termination, and telemetry collection.
• If the update is already in production and the issue is widespread, consider rolling back affected clusters and opening a Microsoft support case with reproducible artifacts.
• Collect and attach the following diagnostics when filing a case: winver screenshot, ProcMon traces filtered for taskmgr.exe, ETW traces for process create/exit, Get‑Process/tasklist outputs, and a short screen recording showing the reproduction. These materials accelerate engineering triage.

---

Deeper forensic tips for power users and support engineers​

If you want to help pinpoint the exact cause for Microsoft engineering:

• Reproduce the bug on an isolated VM and capture:
  • ProcMon trace filtered for taskmgr.exe.
  • ETW traces for process/thread lifetimes.
  • Process Explorer snapshots (Handles view, Threads, and DLLs) for orphaned taskmgr.exe instances.
  • A short video demonstrating open → close → reopen with process listings before and after.
• Compare thread stacks for the orphaned taskmgr.exe instances to identify the active modules keeping the process alive.
• Collect installed driver and third‑party software inventories; environmental triggers (shell extensions, performance monitoring tools, security hooks) can influence repro rate.

---

Risk assessment — how bad is this, really?​

• Scope: The issue is not universal. Many users installed KB5067036 without incident; the symptom reproduces on a subset of devices, indicating environmental or feature‑flag gating.
• Severity: For average users the problem may be a mild annoyance — a few extra processes consuming tens of megabytes each. For power users, low‑RAM devices, or automated environments that repeatedly open Task Manager, the accumulation can become material and affect battery life, responsiveness, or trigger UI stutters in gaming or real‑time workloads. Community tests report per‑instance memory in the 20–30 MB range, with contrived tests producing multi‑gigabyte totals after extreme repetition; treat these numbers as lab results, not Microsoft telemetry.
• Operational risk: For IT teams, the more serious risk is the erosion of trust and additional support costs when a core diagnostic tool behaves unexpectedly after a preview servicing cycle. Preview updates are designed to catch this sort of issue before broad deployment — that’s their purpose — but pilot validation must include lifecycle actions for diagnostic tools.

---

Why this matters to users and to Microsoft​

Small changes in UI or grouping code can cascade into lifecycle regressions when reference counting, thread shutdown, or COM object management changes. Task Manager is invoked frequently by both casual users and IT professionals; a simple close action (clicking the X) is a high‑frequency, low‑surface‑area operation that must be robust. This incident underscores two lessons:

• For users: Optional preview updates can introduce regressions; if you value stability, do not install preview updates on production systems. Create backups and system restore points before experimenting.
• For vendors: Lifecycle paths and high‑frequency user actions must be included in automated regression suites. Staged rollouts limit blast radius, but the testing pipeline must explicitly exercise fundamental actions (open/close, shutdown, uninstall) across a range of configurations.

---

Recommended best practices (concise checklist)​

• Home users and power users:
  • Avoid installing optional preview updates on mission‑critical systems.
  • If already installed and affected, use taskkill /im taskmgr.exe /f or Get‑Process/Stop‑Process to clear instances and reboot.
  • Consider uninstalling the preview if stability is more important than preview features.
• IT administrators:
  • Pause rollout to broad production rings until Microsoft confirms a fix.
  • Include Task Manager and other diagnostic tools in acceptance tests for preview updates.
  • If affected, collect diagnostic artifacts and open a support case with Microsoft.
• Reporters and community testers:
  • Provide reproducible steps, ProcMon traces, and short screen recordings when filing Feedback Hub entries or Microsoft support cases. These materially speed engineering triage.

---

How to safely kill orphaned Task Manager instances (cheat sheet)​

1. Open Command Prompt as Administrator.
2. Run: taskkill /im taskmgr.exe /f — forcibly terminates all taskmgr.exe instances.

PowerShell variant:

1. Open PowerShell as Administrator.
2. Run: Get‑Process -Name taskmgr | Stop‑Process -Force.

GUI method (slower when many instances exist):

• Open Task Manager → Processes → locate Task Manager entries under Background processes → select each and click End task.

---

What Microsoft has said (and what it hasn’t)​

The KB release notes for KB5067036 enumerate the update’s enhancements and state the builds and rollout model. At the time the KB was published it did not list Task Manager duplication as a known issue, and Microsoft’s Release Health page is the place to watch for an official acknowledgement or patch. Community channels have filled the gap with reproducible workarounds while engineering investigates. Expect Microsoft to investigate and, if the issue is confirmed and widespread, to publish a fix in a future cumulative update or an out‑of‑band patch.

---

Final assessment and closing advice​

KB5067036 brings visible UI and usability improvements to Windows 11, but the Task Manager duplication reports highlight the risk preview updates carry: fixes in one subsystem can produce lifecycle regressions in another. The good news is the problem has clear containment steps (End task, taskkill, uninstall), and preview updates exist precisely to let Microsoft and the community find and fix these edge cases before broad availability. For most users, the pragmatic approach is straightforward:

• If you rely on system stability, skip optional preview updates until Microsoft publishes follow‑up fixes.
• If you already installed KB5067036 and see the Task Manager symptom, run taskkill /im taskmgr.exe /f to clear orphaned instances, avoid using the Close (X) for Task Manager, and monitor Microsoft’s Release Health and the KB entry for an acknowledgment and a patch.

The community has reproduced and documented the behavior; now the path forward is for Microsoft to confirm root cause, release a corrective package, and close the loop with transparent engineering notes. Until that happens, the containment steps above restore performance and stability quickly for affected systems.

---

Conclusion: the Task Manager duplication bug is an annoying but manageable regression in a preview update — one that underscores best practices for both users and IT teams when dealing with optional servicing. Use the command‑line kill or End task to reclaim memory, defer optional previews on production endpoints, and expect Microsoft to patch the regression once sufficient telemetry and reproductions are available.

---

Source: Red Hot Cyber Windows 11 Task Manager Bug: How to Fix It

A recent Windows 11 optional preview update has produced a bizarre and attention‑grabbing regression: instead of closing when you click the window’s X, Task Manager sometimes remains alive in memory — and every time you open the UI again a new, additional Task Manager process is left running in the background. The result is a rapid accumulation of orphaned taskmgr.exe processes consuming memory, contributing small CPU spikes, and potentially degrading performance and battery life over time. The bug is tied to the October 28, 2025 non‑security preview update (KB5067036, OS Builds 26200.7019 and 26100.7019) and has been reproduced by multiple community and independent testers; Microsoft’s KB entry for that update currently lists no known issues for the release, and at the time of publication there was no public vendor acknowledgement of the Task Manager duplication symptom.

Background​

Windows updates are often multi‑layered: security patches, cumulative fixes, servicing stack updates (SSUs), and optional preview packages that carry non‑security feature and quality changes. In late October 2025 Microsoft shipped an optional preview (non‑security) update that increments Windows 11 to OS Builds 26200.7019 (25H2) and 26100.7019 (24H2) and includes UI and behavior changes — notably a set of Task Manager fixes intended to improve how apps are grouped with their processes.
Preview updates are routinely distributed in waves and frequently enable certain features server‑side only for a subset of devices. That staged delivery reduces the blast radius when regressions appear, but it also means some affected systems will see changes earlier than others. The Task Manager regression described here surfaced quickly because Task Manager is a frequently used diagnostic and control tool — the very tool users reach for when something else on the PC misbehaves.

---

What’s happening: symptoms and reproduction​

The behaviour reported by dozens of users and reproduced in community tests follows a consistent pattern:

• Open Task Manager using Ctrl+Shift+Esc (or the taskbar/Quick Link menu).
• Click the close button (the X) in the top right of the Task Manager window.
• The window disappears from the screen, but the underlying process (taskmgr.exe) remains active in Windows.
• When Task Manager is opened again a fresh taskmgr.exe process is created and shown; the previously orphaned process remains running in the background.
• Repeating the open/close cycle leaves successively more running Task Manager processes, each consuming a modest amount of RAM and occasionally showing 0–2% CPU usage during periodic polling.

Key observable facts from community tests:

• Each orphan taskmgr.exe instance typically reports roughly 20–25 MB of memory in standard configurations. That’s small per process, but multiples add up quickly.
• CPU usage per orphan instance is often negligible or low (commonly 0–2% in tests), but dozens of such instances can create meaningful aggregate load, causing stutters and battery drain on laptops.
• Rebooting clears the accumulated orphan processes; they are not persistent across restarts.
• The behaviour is reproducible on systems that received the October 28, 2025 preview package, though not every device with the update exhibits the problem — consistent with staged feature rollouts and hardware/software variation.

This is not a security exploit; it’s a functional regression that leaves legitimate Windows processes running when the user intended to close them. Still, it’s a frustrating diagnostic paradox: Task Manager itself becomes a source of background load and user confusion.

---

Why this likely happened (technical analysis)​

Official release notes for the preview update mention a fix intended to correct how Task Manager groups apps with their processes. That suggests the update modified Task Manager’s internal logic for mapping windows or application entries to process identifiers and for lifecycle handling when UI windows are closed.
Hypotheses consistent with the observed behaviour:

• The update changed Task Manager’s close‑window handler so that the UI surface is destroyed while the process stays alive (a mismatch between window teardown and process termination).
• Grouping logic or an added process‑monitoring thread may have been altered to avoid killing grouped children; the unintended side‑effect is preventing taskmgr.exe from responding to normal exit conditions.
• The bug may only appear under particular conditions in the OS’s feature‑flight logic or when certain configuration flags are enabled server‑side (explaining inconsistent repro across devices).

These are reasoned inferences based on the update’s stated scope and the symptoms reported; the exact root cause requires Microsoft’s internal diagnostics (and until Microsoft confirms, the precise line of code or regression introduced cannot be stated with certainty).

---

Scope and impact: how bad is this?​

At a glance the resource footprint per orphaned Task Manager is small, but cumulative effects are important to understand:

• Memory: ~20–25 MB per instance. Ten orphaned instances = ~200–250 MB; 100 instances = 2–2.5 GB. On memory‑constrained machines or long uptimes, this can be significant.
• CPU: Intermittent polling can produce small short spikes (0–2% per instance in tests), which add up when many processes exist. For laptops, continuous tiny CPU use contributes to measurable battery drain.
• Stability: Multiplying system processes that poll hardware or performance counters can exacerbate scheduling jitter, leading to UI stutters, frame drops, or responsiveness issues in I/O heavy scenarios.
• User confusion & trust: Task Manager is the first stop for many users to identify runaway apps. When that tool becomes unreliable, it undermines user confidence and complicates troubleshooting.

There’s no evidence this bug enables privilege escalation or persistence in the classic malware sense. That said, a buggy system utility can obscure detection of malicious activity or create confusion that attackers could exploit socially — for example, by pointing victims away from standard diagnostics. Those are secondary, plausible risks rather than direct outcomes of the bug itself.
Caveat: community testing reports vary. Not every device with the preview update reproduces the issue, and reports are skewed to users who frequent tech communities and test optional builds. The problem appears real and reproducible for many, but its incidence is not universal across the entire Windows install base that received the preview package.

---

Immediate user mitigation: practical workarounds​

If you suspect your PC is affected, here are quick detection and remediation steps — follow them in the order presented for safety and clarity.
How to verify you’re affected (quick check)

• Press Ctrl+Shift+Esc to open Task Manager.
• Click the X to close it.
• Open Task Manager again.
• In the Processes tab, expand Background processes and check whether more than one “Task Manager” entry exists (and whether the count grows each time you repeat the open/close cycle). If yes, you’re affected.

Fast ways to stop the orphaned processes

• End task via Task Manager UI:
• Open Task Manager.
• In Processes, find the Task Manager entry (there may be multiple).
• Right‑click the Task Manager process and choose End task until all Task Manager entries are ended.
• Kill all instances from Command Prompt:
• Open an elevated Command Prompt (right‑click Start, choose Command Prompt (Admin) or Windows Terminal).
• Run: taskkill /im taskmgr.exe /f
  This force‑terminates all running Task Manager processes.
• PowerShell approach:
• Open PowerShell as Administrator.
• Run: Stop-Process -Name taskmgr -Force
  Or to be explicit: Get-Process taskmgr | Stop-Process -Force
• Reboot: a full restart clears all instances and returns the system to a known clean state.

Important notes:

• Using End task inside Task Manager is the safest immediate approach; avoid ending random system processes.
• Repeatedly opening Task Manager and closing it with the X will continue to create new orphaned processes until the underlying update is uninstalled or Microsoft issues a fix.
• If you need a temporary quick action, the taskkill or PowerShell commands remove all active instances at once.

If you want to avoid triggering the bug

• Avoid closing Task Manager with the window X while the issue is unresolved. Use the internal End task action on the entry for Task Manager first, or log out/reboot when possible.
• Do not repeatedly open and close Task Manager for stress testing; each open/close may leave another instance behind.

---

How to undo the update or avoid preview packages​

Because the regression is tied to an optional preview package, users who did not intend to run preview code should disable automatic preview delivery and, where necessary, uninstall the problematic LCU.
Consumer path to avoid previews:

• Settings > Windows Update > toggle off Get the latest updates as soon as they’re available. This prevents preview/non‑security packs from being pulled automatically.
• If you rely on Windows Update for drivers and other optional items, review Optional updates manually and decline the preview package.

Uninstalling the combined package (notes and caveats)

• The preview package KB5067036 is delivered as a combined SSU + LCU in many cases. Microsoft’s update guidance states that removing the LCU may require using DISM /Remove‑Package with the LCU package name (the combined package may not be removable via the classic wusa /uninstall because the SSU component is part of the package).
• For non‑experienced users: the safest approach is to use Settings > Windows Update > Update history > Uninstall updates and follow the UI if available. If the UI won’t remove a combined package, enterprise‑grade steps (DISM) may be necessary.
• Power users and administrators who must remove the LCU can:
• Use DISM /online /get-packages to enumerate installed package names.
• Identify the LCU package name matching the KB.
• Run DISM /online /Remove-Package /PackageName:<exact-package-name> /norestart
  Exercise caution: removing servicing updates can have side effects; back up important data and understand the environment before proceeding.

Enterprise controls

• Use Windows Update for Business, WSUS, or Intune to block or stage optional updates. Administrators can set deferral policies, pause updates, or prevent preview offerings from reaching managed fleets.
• The Group Policy or MDM policy Manage preview builds and branch readiness level settings allow admins to prevent preview builds from being applied broadly.
• For managed devices: do not rely on user toggles. Use the Windows Update for Business policies and pilot rings to validate and protect production systems.

---

Reporting, monitoring, and waiting for a vendor fix​

• File feedback: use the Feedback Hub to report the bug and include repro steps and system configuration (build number, whether the device is on the staged rollout, hardware details).
• Monitor official channels: check the Windows release health dashboard and the KB article for an eventual known‑issues acknowledgement or an out‑of‑band patch.
• Microsoft typically folds preview fixes into the next cumulative/normal rollout after validation; depending on severity, an out‑of‑band patch may be issued more quickly.

---

Risk assessment for different user groups​

Home users

• Impact: annoyance, potential performance and battery life degradation if Task Manager is repeatedly opened during a long uptime.
• Recommended action: use the workarounds above, toggle off preview updates if you did not mean to receive them, and reboot to clear orphaned processes.

Power users and hobbyists running preview channels

• Impact: higher; these users may be more likely to experience the regression due to opting into new updates earlier.
• Recommended action: treat preview builds as test candidates — keep system images, avoid installing on machines used for critical tasks, and be prepared to roll back.

IT administrators and enterprises

• Impact: limited if controlled processes for updates are in place. But if preview/optional updates slip into managed machines, the bug could create help desk churn and user confusion.
• Recommended action: rely on controlled deployment, enforce deferral/pause policies, and use pilot rings to catch regressions early. Prepare scripts and triage guidance for help desk staff to quickly kill orphan processes and roll back updates if necessary.

---

Broader analysis: what this says about servicing and release practices​

The incident is a reminder of the tension in modern software servicing: rolling out UI and behavior fixes in optional previews reduces the risk of breaking the entire user base, but it also exposes real users to regressions that are hard to detect in limited lab testing. Task Manager is a particularly sensitive surface because it’s both a diagnostic tool and a UI element that directly interacts with process lifecycles.
Positive aspects in Microsoft’s process:

• Preview updates let a broad set of users validate changes and surface platform-level regressions.
• The staged rollout model prevents hitting every device at once and allows rollback or targeted fixes when issues are identified.

Areas of friction and risk:

• Preview updates sometimes blend into consumers’ normal update flows when toggles like Get the latest updates as soon as they’re available are enabled. Users who think they are just getting quality fixes may inadvertently run preview code.
• Release notes can be brief or omit newly introduced regressions. When the vendor’s KB lists no known issues yet users see reproducible problems, it creates a gap between user experience and official guidance.
• Combined SSU + LCU packages complicate rollback for non‑technical users; when SSUs are bundled in a combined package, standard uninstall routes may not work and DISM removals require more advanced skills.

---

Practical takeaways and clear recommendations​

• If you didn’t opt into preview updates, switch off Get the latest updates as soon as they’re available in Settings to avoid optional non‑security preview installs.
• If you see multiple Task Manager entries after closing the window, kill all instances with taskkill /im taskmgr.exe /f or Stop-Process -Name taskmgr -Force and reboot.
• If the preview update is not required, consider uninstalling it or waiting until Microsoft releases a patched cumulative update. For managed environments, block optional preview packages with Windows Update for Business policies.
• Keep regular backups or system images if you like to test early builds; doing so reduces the risk of disruption from preview regressions.
• Report the problem using the Feedback Hub and watch the Windows release health pages for official acknowledgement and patch availability.

---

Conclusion​

The Task Manager duplication bug is an awkward, highly visible regression: a tool designed to help users find and kill misbehaving apps instead becomes, under certain update conditions, the source of persistent background processes. The underlying preview package addresses legitimate issues for process grouping and other UI improvements, but a regression in lifecycle handling makes Task Manager’s close action stop doing what users reasonably expect.
Until Microsoft issues a fix, the problem is manageable: it’s detectable, the orphan processes are removable, and conservative update settings prevent accidental exposure. Nevertheless, the incident underlines a persistent truth of modern OS maintenance — rolling out small, targeted fixes at scale inevitably risks surprising edge cases — and it reinforces the value of cautious update practices for non‑critical systems and strict update controls in managed environments.

---

Source: Ars Technica Windows 11 Task Manager bug makes the app’s “close” button do the exact opposite

Microsoft’s latest optional preview for Windows 11 appears to have introduced a baffling regression: the Task Manager’s close button can fail to terminate the app, leaving behind one or more live taskmgr.exe processes that accumulate each time you open and close the utility. The bug was tied to the October 28, 2025 preview update KB5067036 (OS builds 26200.7019 and 26100.7019) and has been reproduced by independent outlets and community testers, producing measurable memory and occasional CPU pressure on affected machines.

Background​

What shipped in KB5067036​

KB5067036 is an optional, non-security preview cumulative update that Microsoft published on October 28, 2025. The official release notes list a number of UI and reliability changes — a redesigned Start menu, updated taskbar battery icons, File Explorer improvements and a stated fix to Task Manager’s “process grouping” behaviour — and note the update is being distributed via a phased (gradual) rollout. Because the package is a preview update, features and fixes may be staged and not enabled uniformly across all devices.

How the problem surfaced​

Within hours and days of the preview’s rollout, community users and several tech outlets documented a reproducible anomaly: closing Task Manager with the top-right “X” sometimes does not terminate the underlying process, and reopening Task Manager creates another visible instance while the previous one remains running in the background. Multiple independent reproductions and short stress tests showed each orphaned taskmgr.exe occupying roughly 20–30 MB of RAM; one contrived test that repeatedly opened and closed Task Manager ~100 times ended up with hundreds of orphaned instances and roughly 2 GB of RAM consumed by them.

---

What’s actually happening (technical symptoms and reproduction)​

Symptom checklist — how to reproduce​

• Press Ctrl+Shift+Esc to open Task Manager.
• Close it using the window Close (X) button.
• Reopen Task Manager and switch to Processes → Background processes.
• If your device is affected, you’ll see more than one “Task Manager” entry and the count increases each time you repeat open → close.

Because the leftover entries are real processes (they show up in Process Explorer, tasklist and PowerShell Get-Process output), this is not a cosmetic UI glitch — the processes remain resident until explicitly terminated. Community reproductions documented small periodic CPU spikes when orphaned instances poll performance counters, in addition to their memory footprint.

Why this looks like a teardown regression​

Task Manager runs background sampling threads and UI threads; closing the window normally triggers a teardown path that should release all resources and allow the process to exit. The KB’s notes mention a change to process-grouping logic, and the observed behavior — a process with no visible UI remaining resident after close — strongly suggests a lifecycle regression in the close/teardown path: a background thread, COM object, or a referenced handle that isn’t released, preventing process termination. That’s a well‑fitted hypothesis based on the symptoms, but it is not an official root-cause confirmation from Microsoft. Treat the teardown explanation as plausible yet unverified until vendor engineering releases more diagnostic detail.

---

Independent verification — who reproduced it and what they saw​

Multiple outlets and community testers reproduced the issue within days:

• Windows Latest ran a fleet test and reported the bug on roughly 30 of 100 virtual machines they used for testing, with per-instance memory use of ~20–25 MB and the contrived 100-cycle test consuming approximately 2 GB total.
• The Verge and PC Gamer reproduced the symptom and documented the same reproduction steps and workarounds, adding that Microsoft had not yet publicly acknowledged the issue at the time of reporting.
• Community threads, Reddit posts and forum threads captured direct user screenshots, videos and multiple environment reproductions, underlining that the bug is not universal and may depend on staged flags, drivers or other local conditions.

Taken together, this cross‑publication corroboration increases confidence that the regression exists and is tied to KB5067036 for a measurable subset of users.

---

Impact: practical and operational consequences​

For everyday users​

Most casual users likely won’t encounter a critical problem. The memory per orphaned instance is modest and ordinary desktop usage patterns don’t typically involve opening and closing Task Manager dozens of times per session. Reboots clear in‑memory processes, so short sessions and routine restarts minimize exposure.

For power users and administrators​

Power users, IT professionals and developers who open Task Manager frequently for profiling and troubleshooting are at higher risk. Repeated open/close cycles — common during troubleshooting — can accumulate orphaned instances, causing increased memory pressure, background CPU polling and degraded responsiveness. On low-memory devices or battery-sensitive laptops, dozens of leftover taskmgr.exe instances can meaningfully affect performance and battery life. For managed fleets, the problem raises operational risk if the preview were rolled out broadly instead of staying confined to pilot rings.

Worst‑case scenarios and caveats​

While some outlets mentioned reports of installation failures or more severe upgrade issues linked to the same update, those claims are varied in quality and sometimes anecdotal. Treat any claim of bricked devices or massive data loss with caution until verifiable telemetry or vendor-confirmed incidents are published; the dominant, reproducible symptom across reporters is the Task Manager orphaning behaviour. Flag unverified severe claims as such and prioritize diagnostic evidence (ProcMon, ETW traces) for any support case.

---

Immediate mitigations and fixes that work today​

Because KB5067036 is an optional preview and the behaviour is environment-dependent, the simplest mitigation for most users is to avoid installing the package on production devices. If you’ve already installed it and see the duplication, use one of the following practical options:

• Stop using the window Close (X) button to exit Task Manager. Instead, open Task Manager → Processes → Background processes → right-click the Task Manager entry and select End task. That reliably terminates individual orphaned instances.
• Run a single command to kill all Task Manager instances at once (needs elevated privileges):
  taskkill /im taskmgr.exe /f
  Or in PowerShell (Admin): Get-Process -Name taskmgr | Stop-Process -Force.
• Use Sysinternals Process Explorer as a temporary replacement for diagnostics and process management. Process Explorer provides finer detail (handles, threads, loaded modules) and can kill stubborn instances without triggering the duplication behavior.
• If performance is already impacted by many orphaned instances, run the taskkill command, then reboot to clear in‑memory state.
• If necessary for production stability, uninstall KB5067036 via Settings → Windows Update → Update history → Uninstall updates. Note: the package may be delivered as a combined Servicing Stack Update (SSU) + LCU in some cases; SSUs cannot be removed independently, and uninstall semantics can be more complex — consult Microsoft’s KB removal guidance if rollback is required.

These mitigations are intentional, low-risk containment measures; they do not fix the underlying bug but prevent resource accumulation until Microsoft releases a corrective update.

---

Microsoft’s official position and expected timeline​

As of the earliest reports, Microsoft’s KB article for KB5067036 listed the update’s fixes but did not include a known‑issue acknowledgement (KIA) describing the Task Manager duplication symptom. The KB page explicitly states the update’s release date, build numbers and the staged rollout model and includes guidance on file lists and uninstall semantics, but it did not (initially) confirm the replication bug. Historically, Microsoft has acknowledged and patched similar Task Manager regressions in subsequent cumulative updates after sufficient reproductions and telemetry are aggregated. For the most current status, administrators should monitor Microsoft’s Release Health dashboard and the KB support page for any KIA or out‑of‑band patch. Because preview updates are optional and staged by design, the company typically gathers telemetry and crash traces before issuing a fix in a follow-up cumulative update or out‑of‑band patch when severity warrants. Expect a vendor acknowledgement and a fix if the bug proves reproducible at scale or causes noticeable operational impact for managed fleets; meanwhile, conservative rollout practices are recommended.

---

Deep technical analysis — plausible root causes and diagnostic approach​

The most plausible root-cause classes​

The symptom points to a teardown/lifecycle regression. The most likely culprits include:

• A background monitoring thread that is not being gracefully shut down when the UI triggers WM_CLOSE/WM_DESTROY, holding the process alive.
• A COM object or performance-counter handle (PDH/Perfmon/ETW) that remains referenced by the process, preventing exit.
• A reference-counting or object ownership change introduced by the process‑grouping fix that inadvertently moved responsibilities for releasing objects, leaving a dangling reference.

Each of the above would manifest as a process without a visible window that nonetheless remains active and sometimes polls counters, which matches community measurements.

How to diagnose this in the field (for advanced users and admins)​

If you are collecting evidence for Microsoft support or incident triage, gather the following artifacts:

• ProcMon trace filtered for taskmgr.exe during reproduce steps (open → close → reopen).
• ETW traces capturing process create/exit events and thread lifetimes for taskmgr.exe.
• Process Explorer thread stacks for orphaned instances (to identify active threads and blocking modules).
• A short screen recording showing the reproduce steps and the Processes list.
• tasklist /FI "IMAGENAME eq taskmgr.exe" outputs and PowerShell Get-Process dumps.

Packaging these artifacts with a clear reproduce script accelerates vendor triage and helps engineers identify the precise reference or thread keeping the instance alive.

---

Enterprise guidance — how to protect fleets​

• Do not deploy KB5067036 to broad production rings. Keep optional previews in pilot rings that include developers and helpdesk machines before wide rollout. Use Windows Update for Business, WSUS or SCCM to control distribution.
• If the update is already broadly deployed and you see the issue on many endpoints, stage a rollback for affected clusters while collecting diagnostics to open support cases with Microsoft. Follow Microsoft’s guidance for removing combined packages when SSUs are involved.
• Create a lightweight remediation script for detection and remediation via Intune or management tooling:
• Detect >1 taskmgr.exe instance via PowerShell.
• Report telemetry to management.
• Optionally run taskkill /im taskmgr.exe /f or set a flag for manual remediation.
• Update QA and automation acceptance tests to include lifecycle scenarios (open/close cycles for system utilities like Task Manager and Explorer) to catch teardown regressions early in the preview pipeline.

---

Lessons for QA and update governance​

This regression is an object lesson in why lifecycle testing (including the simplest “close” paths) is essential. Small UI or grouping logic changes can unpredictably touch core teardown sequences and produce widely visible regressions. Key takeaways:

• Include basic lifecycle tests — open/close, restart, graceful shutdown — in automated regression suits, especially for components that sample system state.
• Keep preview updates restricted to pilot rings by default, and ensure pilot groups include power users who exercise management tooling frequently.
• Encourage users to file Feedback Hub reports and collect ETW/ProcMon traces when preview regressions are observed; high-quality diagnostic artifacts speed vendor fixes.

---

What to tell users now (simple, actionable advice)​

• If you have not installed KB5067036 and you need rock‑solid stability, skip the optional preview for now. Wait for Microsoft to confirm a fix.
• If you installed it and notice the duplication, avoid clicking the Task Manager’s “X” button. Use End task from within Task Manager or run taskkill /im taskmgr.exe /f from an elevated command prompt. Reboot if you need to clear accumulated orphaned instances.
• If you manage a fleet, withhold the preview from broad production rings and remediate affected machines via automated scripts or manual taskkill actions until Microsoft issues a patch.

---

Risks and unresolved questions​

• The regression is not universal; it reproduces on some machines and not others. That mixed scope implies environmental triggers — staged server-side flags, device-specific drivers, or third-party hooks may be required — and complicates root-cause isolation.
• Several outlets and community posts referenced related upgrade glitches around the same servicing window (some anecdotal reports referenced installer issues). Those claims require verification with traceable telemetry before being treated as part of the Task Manager bug’s impact. Flag such claims as unverified until Microsoft or aggregated telemetry confirms them.
• Until Microsoft publishes a known-issue acknowledgement or a patch that identifies the exact failure mode, the teardown-thread/COM handle hypothesis remains plausible but unconfirmed. Collect and share diagnostics if you need Microsoft support.

---

Conclusion​

A seemingly modest preview change intended to improve Task Manager’s process grouping has produced an outsized nuisance: orphaned taskmgr.exe processes that accumulate when users close Task Manager with the window “X.” The bug is demonstrable and reproducible on many machines that installed KB5067036, but it is not universal — staged rollouts and environment-specific triggers likely play a role. Practical mitigations exist (don’t use the “X”; use End task or taskkill; uninstall the preview on production machines), and these are the pragmatic steps to preserve stability until Microsoft issues a corrective update. The incident is a timely reminder that lifecycle testing — the simple act of closing an app — remains a critical element of quality assurance for complex operating systems. The sensible course for most users and administrators is clear: treat KB5067036 as a preview and avoid production rollouts, apply the straightforward containment steps if you are affected, and watch Microsoft’s Release Health and KB pages for an official acknowledgement and patch.

---

Source: Tom's Guide https://www.tomsguide.com/computing...k-manager-clone-itself-and-you-cant-close-it/

Microsoft’s optional October preview for Windows 11 (KB5067036) appears to have introduced a puzzling regression: clicking the Task Manager window’s close button (the “X”) can leave the process running and — worse — spawn a new taskmgr.exe instance each time you reopen it, producing multiple live Task Manager processes that quietly consume RAM and occasionally CPU until you kill them manually.

Background​

Microsoft published the October 28, 2025, optional preview cumulative update identified as KB5067036, which updates Windows 11 to OS builds 26200.7019 (25H2) and 26100.7019 (24H2). The package bundles visible UI changes — notably a redesigned Start menu and taskbar battery icon updates — and internal fixes, including one that touches Task Manager’s process‑grouping logic. Community testers and multiple independent outlets reproduced an unexpected side effect: closing Task Manager with the top‑right “X” sometimes fails to terminate the process, and reopening Task Manager creates another running instance while the earlier one remains resident. That behavior has been documented by major tech sites and numerous user threads. This article explains what’s happening, who’s affected, practical mitigations, likely technical causes, and recommended steps for home users, power users, and administrators.

---

What the bug looks like (quick summary)​

• Open Task Manager (Ctrl+Shift+Esc).
• Click the window Close (X) button to dismiss Task Manager.
• Reopen Task Manager and check the Processes or Details tab.
• If affected, you’ll see more than one “Task Manager” entry (taskmgr.exe); each open→close cycle can accumulate an extra resident process.

The extra entries are real processes (not cosmetic UI duplicates): they show up in Process Explorer, PowerShell Get‑Process output, and tasklist. Community measurements report roughly 20–30 MB of RAM per orphaned taskmgr.exe, and intermittent small CPU spikes when those instances poll counters — numbers that sum quickly if many accumulate.

Why this matters: impact and risk assessment​

Task Manager is a frequently used, lightweight diagnostic utility. The bug’s practical impact depends on device profile and user habits.

• Home users and casual desktop users: low to moderate risk. If you rarely open Task Manager and you reboot regularly, the chance of a problematic accumulation is small. A nightly reboot clears orphaned in‑memory processes.
• Power users, developers, and IT pros: elevated risk. These users open and close Task Manager repeatedly and will notice resource creep, especially on machines used for troubleshooting or heavy multitasking.
• Low‑RAM systems and battery‑sensitive laptops: meaningful risk. On systems with limited memory or strict battery budgets, dozens of orphaned taskmgr.exe instances can force swapping and increase energy consumption, causing stutters and reduced battery life.
• Enterprise fleets and managed environments: operational risk. Preview (optional) updates like KB5067036 are intended for staged testing, and this regression illustrates why pilot rings and controlled deployment are essential for production endpoints.

---

Confirming whether your machine is affected​

• Press Windows+R, type winver, and confirm your OS build. Look for 26100.7019 or 26200.7019 if you installed KB5067036.
• Press Ctrl+Shift+Esc to open Task Manager.
• Click the Close (X) button.
• Reopen Task Manager and switch to Processes → expand Background processes.
• If the number of Task Manager entries increases each time you repeat open → close, your device demonstrates the orphaned process behavior. You can cross‑check with Command Prompt: tasklist /FI "IMAGENAME eq taskmgr.exe" or PowerShell: Get‑Process -Name taskmgr.

If you don’t see duplicates after repeated open/close cycles, you’re not affected (or the feature flag/staging doesn’t apply to your device).

---

Immediate mitigations and workarounds​

Until Microsoft issues a fix, the following mitigations are effective and safe:

• Avoid using the window Close (X) to dismiss Task Manager. Instead, use Task Manager’s End task option on its own entry to terminate a running instance cleanly.
• Use a single command to kill all Task Manager instances:
• Open an elevated Command Prompt or PowerShell and run:
  taskkill /im taskmgr.exe /f
• Or in PowerShell: Get‑Process taskmgr | Stop‑Process -Force
• Use Process Explorer (Sysinternals) to inspect and kill lingering taskmgr.exe instances safely if Task Manager itself is unreliable.
• Reboot: orphaned taskmgr.exe instances are in‑memory only and do not persist across restarts. A reboot clears them.
• If you installed the preview and prefer to avoid its changes, uninstall the preview update via Settings → Windows Update → Update history → Uninstall updates. Note: combined servicing packages can have complex uninstall semantics; consult Microsoft’s KB guidance for removal in managed environments.

Short, practical tip: if you use Task Manager as part of a frequent troubleshooting workflow, adopt the End task / taskkill approach until the vendor issues a patch.

---

Technical hypothesis: what likely went wrong​

KB5067036 explicitly mentions a change targeting Task Manager’s grouping of apps and processes, which suggests the update touches code that maps UI rows to underlying process objects. Modern Task Manager runs a UI thread and background monitoring threads that sample performance counters and marshal telemetry.
A plausible technical regression is this: a change in the grouping/ownership logic inadvertently broke the shutdown path for background monitoring threads or left references alive (handles, COM objects, sampling threads). When the UI window is closed via the window manager, the UI may be destroyed but background threads or held resources remain resident, preventing the process from exiting. Reopening Task Manager spawns a new UI process while the earlier one persists as a headless process that still polls counters — producing the “ghost” Task Manager phenomenon. This is consistent with lifecycle regressions seen in multi‑threaded applications when teardown code paths are altered.
Important caution: this explanation is a well‑fitted hypothesis based on community artifacts and the update’s changelog; it is not a formal root cause confirmed by Microsoft. Diagnostic artifacts such as ETW traces, ProcMon captures, and Process Explorer thread stacks would be required for a definitive engineering diagnosis. Treat the technical explanation as plausible but provisional until an official vendor post‑mortem is published.

---

Reproduction observations and measurements​

Community reproducibility and small lab tests show:

• Each orphaned taskmgr.exe instance typically consumes roughly 20–30 MB of RAM in standard configurations; some tests reported similar numbers and occasional small CPU usage (0–2%) when sampling counters. Those per‑instance footprints are modest, but repeated opens can sum to hundreds of megabytes or several gigabytes in contrived stress tests.
• Orphaned instances appear in:
• Task Manager (Processes and Details tabs)
• Sysinternals Process Explorer
• PowerShell Get‑Process and tasklist output
• The bug is not universal: some machines with KB5067036 do not reproduce the issue, indicating environmental triggers (third‑party drivers, services, staged feature flags, or device‑specific gating).

These observations line up across multiple independent outlets and forum threads, increasing confidence that this is a real regression introduced or exposed by the preview.

---

Enterprise guidance: containment, telemetry, and rollback​

For administrators, KB5067036 is a textbook example of why preview updates belong in pilot rings before broad deployment.
Recommended steps for managed environments:

• Pause deployment of KB5067036 in production ring. Treat it as optional preview and withhold from broad rollout until vendor confirms and fixes the regression.
• If the update is already present on endpoints:
• Deploy a simple detection script that checks for more than one taskmgr.exe instance (tasklist /FI "IMAGENAME eq taskmgr.exe") and triggers remediation (taskkill /im taskmgr.exe /f) or reports telemetry to the management console.
• Use Intune, WSUS, or SCCM to automate rollback policies for the preview package where necessary, remembering that SSU/LCU semantics can complicate removal.
• Collect diagnostic artifacts (winver screenshot, ETW trace filtered for Task Manager, ProcMon trace, Process Explorer capture, and a short video of open→close→open reproduction) when opening a Microsoft support case. These artifacts accelerate triage and increase the odds of a timely patch.
• Communicate to helpdesk and power‑user teams: ask them to avoid closing Task Manager with the X and use End task or taskkill until a vendor fix is available.

---

Why Microsoft may not yet have acknowledged it (and what to watch for)​

Preview updates are regularly distributed as staged rollouts and can include server‑side feature gating. That approach means not every device sees the same behavior, complicating telemetry aggregation and reproduction at scale. Microsoft’s KB page for KB5067036 currently lists the update’s changes and rollout details and — at the time community reporting began — did not include a known‑issue acknowledgement for Task Manager duplication. Several outlets explicitly noted Microsoft had not yet posted a public acknowledgement of this specific regression. A vendor acknowledgment typically follows one of these patterns:

• A known‑issue entry appended to the KB article or Release Health dashboard.
• A targeted out‑of‑band patch for the affected builds.
• Advice to uninstall the preview for production users until a fix is ready.

Watch Microsoft’s Windows Release Health and the KB entry for KB5067036 for updates; organizations should also monitor Feedback Hub and their support case dashboards for priority escalations.

---

Step‑by‑step remediation recipes​

Below are practical, copy‑ready steps for different user types.

For home users (fastest safe fix)​

• Open an elevated Command Prompt (right‑click Start → Windows Terminal (Admin).
• Run: taskkill /im taskmgr.exe /f
• Reopen Task Manager normally; avoid closing with the X.
• If you want to remove KB5067036: Settings → Windows Update → Update history → Uninstall updates → find KB5067036 and remove (if applicable). Reboot after removal.

For power users and IT staff (gather diagnostics and recover)​

• Reproduce and record the open→close→open sequence.
• Capture: winver output, tasklist /FI "IMAGENAME eq taskmgr.exe", and Process Explorer snapshot (handles & threads).
• Use taskkill /im taskmgr.exe /f to recover, or right‑click each orphan entry in Task Manager → End task.
• Submit a Feedback Hub entry with reproduction steps and attachments; attach artifacts to a Microsoft support case if needed.

For enterprise administrators (contain and automate)​

• Pause KB5067036 deployment in production rings.
• Deploy a detection/remediation script via Intune or endpoint management:
• Detect: if ( (tasklist /FI "IMAGENAME eq taskmgr.exe" | find /c "taskmgr.exe") -gt 1) then taskkill /im taskmgr.exe /f
• Collect aggregated telemetry and open a support case if multiple devices are affected.
• If necessary, plan a rollback of the preview update for affected clusters; follow Microsoft’s combined package uninstall guidance.

---

Strengths and weaknesses of Microsoft’s preview model — and lessons from this regression​

Strengths:

• Field testing at scale: preview releases allow Microsoft to gather telemetry across varied hardware and software combinations.
• Feature gating: staged rollouts let the vendor throttle exposure and limit blast radius.

Weaknesses exposed by this incident:

• Lifecycle paths (open/close/exit) are fundamental and highly exercised; changes that touch those paths require rigorous lifecycle and teardown testing on representative hardware.
• Staged enablement can make root‑cause correlation harder: a bug that affects only some configurations may take longer to surface in vendor telemetry.
• Preview updates installed on pilot or production devices increase helpdesk burden when regressions slip through.

Operational lesson: enterprises must treat optional preview updates as testing artifacts and rely on pilot rings; home power users should be cautious about installing optional previews on primary devices.

---

What to expect next​

Historically, Microsoft has issued fixes for high‑impact regressions found in preview updates once sufficient telemetry and reproducible reports reach engineering. Given Task Manager’s central role and the clear reproducibility described by multiple independent outlets and community threads, a vendor acknowledgment and patch are likely once Microsoft validates reproductions and root cause. In the meantime, users should apply the mitigations above and monitor Microsoft’s KB and Release Health pages for follow‑up.

---

Final analysis and recommendations​

This Task Manager duplication bug is an awkward but manageable regression that highlights the tradeoffs of preview updates: quicker feature validation at the cost of exposing edge‑case regressions. The bug is not catastrophic — orphaned Task Manager instances are not malware and are cleared by reboot — but it is an energetic nuisance for power users and can degrade performance on constrained devices.
Actionable recommendations:

• Home users: if you installed KB5067036 and notice the behavior, use taskkill /im taskmgr.exe /f to clear instances, avoid closing Task Manager with the X, and consider uninstalling the preview on a production device.
• Power users: gather ProcMon and ETW artifacts when you reproduce the bug and submit a detailed Feedback Hub entry; this accelerates vendor triage.
• Administrators: stop broad deployment of the optional preview, deploy detection/remediation scripts for endpoints, and escalate via Microsoft support if the bug affects multiple clients in a fleet.

This regression is a timely reminder: preview releases are valuable for advancing Windows, but they must be staged carefully. Until Microsoft provides a formal fix, avoid using the Close (X) on Task Manager and prefer End task or a forced taskkill to keep systems clean and responsive.

---

Microsoft’s official KB page documents the October 28, 2025 preview (KB5067036) and the OS build numbers it installs; community testing and independent reporting corroborate the Task Manager close‑path regression and its practical mitigations. If you are affected, follow the containment steps above, gather reproducible diagnostics, and report the issue through Feedback Hub or a Microsoft support case so engineers have the artifacts they need to accelerate a resolution.

---

Source: Notebookcheck New Windows 11 bug makes Task Manager replicate itself when you close it

Microsoft’s optional October preview for Windows 11, KB5067036, introduced a surprising and persistent regression: closing Task Manager with the window “X” can leave the underlying taskmgr.exe process running, and repeating the open→close cycle spawns additional background Task Manager instances that quietly consume RAM and occasional CPU until explicitly terminated.

Background / Overview​

Microsoft released KB5067036 (OS builds 26200.7019 and 26100.7019) as an optional, non‑security preview cumulative update that bundles UI tweaks and a handful of reliability fixes, including an explicit change intended to improve Task Manager’s process‑grouping behaviour. The change was published on October 28, 2025 and is being rolled out in a staged fashion. Within days of that rollout, multiple independent outlets and community threads reproduced a reproducible anomaly: close Task Manager using the top‑right Close (X) button, reopen it, and you may find more than one “Task Manager” listed in Processes — with each prior instance still running in memory. The symptom is real and observable in Process Explorer, PowerShell Get‑Process output, tasklist, and Task Manager’s own Details view. This article explains what’s happening, what the community and independent tests show about resource impact, practical mitigations for end users and administrators, a technical hypothesis for the regression, and lessons for Windows QA and update deployment strategies.

---

What users are seeing — Symptoms and reproduction​

Simple reproduction steps​

• Press Ctrl+Shift+Esc (or start Task Manager by any other method).
• Close Task Manager using the top‑right Close (X) button.
• Reopen Task Manager and go to Processes (expand Background processes if necessary).

On affected machines, each open→close cycle increases the count of “Task Manager” processes; earlier instances remain present and continue occupying system resources. This is not a visual duplicate — these are additional taskmgr.exe processes tracked by the OS.

How it presents in tooling​

• Task Manager: shows multiple Task Manager entries; orphaned copies commonly appear under Background processes and can be overlooked by casual users.
• Process Explorer / tasklist / PowerShell: orphaned taskmgr.exe instances are visible to process and system tools, confirming they are real processes rather than UI artifacts.

Variability and scope​

The behavior reproduces reliably on many systems but not universally. Reports indicate a staged rollout and environmental triggers — hardware, drivers, OEM modifications, third‑party utilities, or server‑side feature flags could influence whether a machine exhibits the bug. That inconsistency is why some users see nothing while others can reproduce it readily.

---

Measured impact — Memory, CPU, and practical consequences​

Community reproductions and independent testing converge on a handful of measured effects:

• Memory: orphaned taskmgr.exe instances typically consume around 20–30 MB of RAM each in observed tests. That means:
• 10 orphaned instances ≈ 200–300 MB
• 100 orphaned instances ≈ 2–3 GB (a contrived but demonstrative stress test recorded roughly 2 GB after ~100 open/close cycles).
• CPU: each orphaned Task Manager process usually uses very little CPU at idle, but periodic polling or sampling can produce small spikes. Independent reports cite per‑instance CPU use in the ~0–1.5% range during sampling spikes; combined, many instances can add measurable CPU pressure and battery drain. Exact figures vary by test and machine.
• Usability and troubleshooting: the irony is acute — the Windows tool used to find and kill misbehaving processes becomes unreliable if it itself leaves ghost processes behind. Helpdesk workflows and fast troubleshooting sessions that repeatedly open/close Task Manager can accumulate resource waste invisibly until someone notices.

Important caveat: the precise per‑instance resource numbers and CPU spikes are community measurements and can vary with OS configuration, telemetry sampling frequency, and whether full UI elements are active. Treat specific numbers as empirical observations from early reproductions, not immutable facts.

---

Technical analysis and likely root causes​

What changed in KB5067036​

The KB release notes explicitly include a fix for Task Manager that adjusts how apps are grouped with their processes, a change that touches Task Manager internals and how it maps UI rows to underlying OS process information. That shows Microsoft intentionally modified the code paths that relate to how Task Manager represents and tracks process groups.

Plausible failure modes​

Task Manager is not a single‑threaded UI; it mixes UI threads, background telemetry sampling, performance counter watchers, COM interactions, and various reference‑counted objects. When lifecycle or grouping logic is changed, it’s possible to inadvertently break the teardown sequence:

• A background sampler, timer, or COM registration is left active, preventing full process termination when the UI window is destroyed.
• The UI thread and window may be torn down (so the window disappears), but the process remains because worker threads still hold references or have outstanding handles.
• Launching Task Manager again spawns a fresh process and UI while the old one remains resident to service whatever background workers are still running.

This class of bug — a teardown or reference counting regression — is consistent with the symptoms and with the KB note about changes to grouping logic. However, no public Microsoft post‑mortem or detailed root‑cause has been published at the time of reporting, so the explanation remains a technically plausible hypothesis rather than a vendor-confirmed cause.

Why it’s not a parent/child forking artifact​

Windows NT’s kernel process model is flat and object‑handle based, not a forked parent/child model like some Unix systems. Task Manager instances are independent processes, and the phenomenon observed here is not a conventional parent process spawning detached child processes; rather, it appears to be the original taskmgr.exe failing to exit while its UI is destroyed — creating a scenario where multiple independent taskmgr.exe processes coexist. The exact internal reference or handle being held is still unknown publicly.

---

Short‑term mitigations and practical fixes​

If you are affected, these are practical, immediate steps to contain resource accumulation and restore normal operation.

For end users​

• Do not close Task Manager with the window Close (X) button. Instead:
• Use Task Manager’s own End task option to terminate Task Manager from within Task Manager’s UI. That reliably kills the running process.
• Kill all Task Manager processes from an elevated command prompt:
• taskkill /im taskmgr.exe /f
• Or in PowerShell (Admin): Get‑Process -Name taskmgr | Stop‑Process -Force
  These commands forcefully terminate all taskmgr.exe instances at once.
• Reboot: a restart clears any in‑memory orphaned processes.
• Use Sysinternals Process Explorer for deeper inspection or selective process termination.

For power users and administrators​

• Uninstall the optional preview on infected machines if the behavior materially impacts workflows:
• Settings → Windows Update → Update history → Uninstall updates (note: the preview may be a combined SSU + LCU and uninstall semantics can be more complex; consult Microsoft’s KB entry for guidance).
• If you manage fleets, hold KB5067036 out of pilot rings used for troubleshooting and helpdesk devices until Microsoft publishes a fix. Preview channel updates should be limited to dedicated test rings for precisely these reasons.

Quick command reference​

• Verify Task Manager instances (non‑admin): tasklist /FI "IMAGENAME eq taskmgr.exe"
• Kill all instances (admin): taskkill /im taskmgr.exe /f
• PowerShell: Get‑Process -Name taskmgr | Stop-Process -Force.

---

Impact assessment — who should care most​

• Home users who rarely open Task Manager and reboot often: low immediate risk. Memory per orphaned process is modest and reboots clear the issue.
• Power users, developers, IT staff, troubleshooting desks: elevated risk. These users open/close Task Manager frequently and will notice resource creep and workflow friction.
• Low‑RAM devices and battery‑sensitive laptops: meaningful risk. Multiple orphans can force paging and reduce battery life, causing noticeable stutters.
• Enterprises managing large fleets: high operational risk if the preview reaches production devices. This regression is a textbook example of why optional previews are staged and why pilot ring validation is essential.

---

What Microsoft has published (and what they haven’t)​

Microsoft’s official KB entry for KB5067036 lists the update’s content and explicitly mentions a fix related to Task Manager grouping logic, confirming Task Manager internals were changed in this preview. However, at the time of coverage the KB did not list the duplicate Task Manager process behaviour as a known issue. Microsoft’s official guidance page remains the most authoritative place to check for any subsequent known‑issue acknowledgement or patch. Independent outlets and community threads reported the duplication behaviour and published reproductions before Microsoft published a formal acknowledgement; that is a normal cadence for preview channel regressions. Users and admins are advised to monitor Microsoft’s Release Health / KB pages for updates.

---

Risk analysis and QA lessons​

This regression is an instructive case study in how a narrowly scoped functional fix can create a lifecycle regression:

• Small changes to grouping or mapping logic can have outsize effects on teardown sequences if reference counting, timers, or COM interfaces aren’t covered by regression tests.
• Preview channels do their job: exposing environment‑specific regressions before a full rollout. However, staged rollouts and server‑side flags can create confusing partial exposures that make root‑cause triangulation harder.
• Automated test suites for system utilities should include lifecycle tests (open, close, reopen, repeated cycles, and teardown under stress) in addition to functional UI tests. The bug underlines how lifecycle regressions slip through feature‑focused test plans.

Operational recommendation for IT teams: use pilot rings that include helpdesk and power‑user machines to exercise management tools (like Task Manager and Process Explorer) under normal support workflows. If those devices are allowed into preview/ahead‑of‑release updates, they will surface the kinds of regressions that would otherwise impact broad production users.

---

Practical step‑by‑step: How to check quickly and recover​

Verify whether you’re running the affected build​

• Press Windows+R, type winver, and check the OS build — look for 26100.7019 or 26200.7019 if KB5067036 is installed.

Quick verification for the bug​

• Open Task Manager (Ctrl+Shift+Esc).
• Close it with the Close (X) button.
• Reopen Task Manager and examine the Processes tab; expand Background processes.
• If the Task Manager count increases after each open→close, you are affected.

Fast recovery (single machine)​

• Open an elevated Command Prompt (Run as administrator).
• Run: taskkill /im taskmgr.exe /f — this will kill all taskmgr.exe instances.
• Reboot if resource pressure persists.

Uninstall the preview (if required)​

• Settings → Windows Update → Update history → Uninstall updates. Be aware that combined servicing packages may have nonstandard uninstall behaviors; check Microsoft’s KB entry for details before performing mass rollbacks.

---

What to watch next​

• Microsoft’s KB/Release Health pages for a known‑issue acknowledgement and a patch. The vendor typically documents significant regressions and their mitigations once engineering confirms a root cause.
• Community threads and independent outlets for reproductions across OEMs and hardware permutations; those reports will clarify environmental triggers or third‑party interactions that expand the issue’s footprint.

If a formal patch appears, admins should validate in a controlled pilot before broad redeployment. If no patch is forthcoming quickly, continue to rely on the mitigations above and avoid installing optional previews on production endpoints.

---

Conclusion​

KB5067036 delivers visible UI and reliability changes for Windows 11, but the Task Manager close‑path regression is a sharp reminder that even apparently small changes to system utilities can cascade into unexpected lifecycle bugs. The symptom is straightforward and reproducible on affected builds: closing Task Manager with the window Close (X) can leave the process running and spawn additional background instances on each reopen, consuming modest amounts of RAM and occasional CPU spikes that aggregate into real impact for certain users and devices. For now, practical containment is simple: avoid the window X, use End task or taskkill to clear instances, reboot to clear memory, and consider uninstalling the optional preview on production devices until Microsoft publishes a fix. Enterprises should treat this incident as evidence for conservative preview deployment, stronger lifecycle regression testing, and reliable pilot ring discipline.
Note: resource figures and CPU percentages referenced above are drawn from independent community tests and outlet reproductions; these are useful empirical indicators but can vary by environment and telemetry cadence, so treat specific numbers as representative rather than universal.

---

Source: TechPowerUp Windows 11 Has a Buggy, Duplicating Task Manager That Hogs Resources | TechPowerUp}

The optional October preview update KB5067036 can leave Task Manager running after you click the window “X,” and repeated open→close cycles may spawn additional background taskmgr.exe processes that accumulate memory and occasional CPU until you explicitly kill them or reboot — a reproducible but not universal regression that affects a subset of Windows 11 machines.

Background​

Microsoft released the non‑security preview cumulative update identified as KB5067036 on October 28, 2025. The package updates Windows 11 to OS builds 26200.7019 and 26100.7019, and it bundles several feature and reliability changes — notably a redesigned Start menu, taskbar/battery icon improvements, File Explorer tweaks, and an explicit change touching Task Manager’s process grouping behavior. The preview is distributed in a staged rollout (gradual → normal), so availability and behavior can vary by device. Preview updates exist to let Microsoft and the community validate non‑security fixes before they reach broad production channels. That staged delivery model helps reduce blast radius, but it also means preview regressions can surface only on some configurations — which appears to be the case for the Task Manager behaviour described here.

---

What users are seeing (Symptoms and quick reproduction)​

• Open Task Manager (for example, press Ctrl+Shift+Esc).
• Close it using the top‑right Close (X) button.
• Reopen Task Manager. On affected machines you may now see more than one “Task Manager” listed in Processes — previous taskmgr.exe processes remain running in the background.

This is not a cosmetic UI glitch: the extra Task Manager entries are real OS processes visible in Task Manager’s Details view, Process Explorer, tasklist, and PowerShell’s Get‑Process output. Independent reproductions report the leftover processes persist until killed or until a reboot clears them.

Typical resource footprint​

Community testing and independent outlets consistently measured modest per‑instance resource use:

• Memory: commonly ~20–30 MB per orphaned taskmgr.exe in stress tests.
• CPU: low but measurable periodic polling spikes (often negligible per instance, but aggregated use can be noticeable when many instances exist).

In contrived stress tests (open + close repeated dozens to hundreds of times) these footprints can sum to hundreds of megabytes or even a few gigabytes, which matters most on low‑RAM devices, virtual machines, or when Task Manager is used frequently as part of troubleshooting workflows.

---

Why this likely happened (technical hypothesis)​

KB5067036 specifically includes a fix that modifies how Task Manager groups processes for display and accounting. Task Manager maintains UI threads and background monitoring threads that poll performance counters and marshal data to the UI. A change to grouping semantics, object ownership, or reference counting can easily affect process lifecycle and teardown.
The leading, plausible explanation from independent analysis is that the update introduced a regression in Task Manager’s close/teardown path — a path that should release background sampling threads, COM objects, and reference counts so the process can exit cleanly. If those teardown actions fail to run (or references remain), the UI window may close while the underlying taskmgr.exe process remains alive. Reopening Task Manager starts a fresh instance while prior ones remain resident. This is a well‑understood class of lifecycle bug in multi‑threaded UIs, but the precise root cause requires vendor confirmation (ETW/ProcMon traces and debug stacks).
Note: this is a plausible engineering explanation based on observed symptoms and the changelog area touched by the update; Microsoft has not (at time of publication) published a detailed post‑mortem describing the exact code path at fault. Treat the teardown hypothesis as informed but unverified until Microsoft releases diagnostic notes or a formal fix.

---

How to verify if your PC is affected​

• Confirm the OS build: press Win+R, type winver, and check whether your system lists build 26100.7019 or 26200.7019 (the builds KB5067036 targets).
• Reproduce the behaviour: open Task Manager (Ctrl+Shift+Esc), click the top‑right X, then reopen Task Manager and inspect Processes → Background processes for multiple “Task Manager” entries.
• Verify running processes from a shell: run Get‑Process -Name taskmgr or tasklist /FI "IMAGENAME eq taskmgr.exe". If you see more than one entry after a close→open cycle, your machine is exhibiting the orphaned‑process behaviour.

---

Immediate mitigations (safe, short‑term)​

If you discover orphaned Task Manager instances, use one of these containment steps:

• Use Task Manager itself: open a Task Manager instance, expand Background processes → right‑click the extra Task Manager process(es) → End task. This reliably terminates individual orphaned instances.
• Command line (fast, forces all taskmgr.exe processes to close): open an elevated Command Prompt or PowerShell and run:
  taskkill /im taskmgr.exe /f
  Explanation:
• taskkill instructs Windows to end a task
• /im specifies an image name (taskmgr.exe)
• /f forces termination of any matching process

This clears all taskmgr.exe instances in one command.

• PowerShell alternative:
• Run Get‑Process -Name taskmgr
• Then Stop‑Process -Id <pid> -Force for each orphaned PID, or use Stop‑Process -Name taskmgr -Force to kill all.
• Reboot the PC: orphaned taskmgr.exe instances are in‑memory only and will be cleared by a restart.
• Use Process Explorer (Sysinternals) for forensic inspection: it shows threads, handles and stacks for each taskmgr.exe instance and remains a robust alternative for process control and diagnostics.

---

Longer‑term options and rollback considerations​

• Uninstall the preview (if installed and unacceptable on production devices): Settings → Windows Update → Update history → Uninstall updates and remove KB5067036 if present. Note that combined SSU + LCU packages may complicate rollbacks; enterprise removals might require DISM or other servicing procedures. Administrators should follow Microsoft’s official guidance for package removal.
• Pause preview/optional updates on production machines: disable “get the latest updates as soon as they’re available” or use Windows Update for Business policies to block optional previews. Preview updates are designed for pilot rings and early testing — avoid them on devices that require high stability.
• Report and collect diagnostics if you need a vendor fix: reproduce the issue and gather ETW traces, ProcMon logs, Process Explorer stacks, and a Winver screenshot. Submit a Feedback Hub report or open a Microsoft support case; reproducible artifacts materially speed engineering triage.

---

Enterprise guidance (operational risk and remediation)​

This regression is an excellent example of why organizations should treat preview updates as test artifacts:

• For every device fleet, maintain a pilot ring that includes helpdesk and developer machines to validate optional previews before rollout to production. Preview packages sometimes toggle features server‑side, producing inconsistent behavior across configurations.
• If KB5067036 has been widely deployed in a managed environment and the Task Manager problem is observed, stage a rollback for affected groups and deploy automated remediation scripts (for example, a scheduled script that runs tasklist/Get‑Process and kills taskmgr.exe duplicates) until Microsoft issues a patch.
• Collect and centralize diagnostics (ProcMon, ETW) from representative hardware and escalate to Microsoft with reproducible cases — this accelerates the vendor’s ability to triage an environment‑dependent regression.

---

How serious is the problem?​

• For most home users: the issue is annoying rather than catastrophic. Each orphaned Task Manager instance is small in memory and typically harmless if you reboot frequently. The practical risk is low unless you repeatedly open/close Task Manager or run on constrained hardware.
• For power users and IT staff: higher nuisance and measurable risk. If Task Manager is part of frequent troubleshooting workflows, orphaned instances can accumulate and affect responsiveness or battery life.
• For managed fleets and low‑RAM devices: greater operational risk. On machines with limited memory, dozens of orphaned instances can cause swapping, stuttering, and noticeable degradation; enterprise administrators should avoid rolling the preview broadly until fixed.

---

What Microsoft has said and what to watch​

Microsoft’s official KB page for the October 28, 2025 preview lists KB5067036 details and the builds it delivers, and it encourages monitoring Windows Release Health and the update history pages for follow‑ups. At the time community reporting spiked, the KB initially did not list the Task Manager duplication symptom as a known issue; the community supplied reproducible reports and independent outlets corroborated the behaviour. Watch Microsoft’s Release Health dashboard and the KB support note for any known‑issue acknowledgement or corrective update.

---

Cross‑checked reporting (independent confirmation)​

This behaviour was reproduced and reported by multiple independent outlets and community threads within days of the preview release. Examples of corroborating coverage and testing include mainstream tech outlets that reproduced the symptom and published workarounds, plus community reproductions that measured the per‑instance footprint and aggregated impact in stress tests. These independent sources corroborate three central, load‑bearing facts:

• The issue is tied to the October 28, 2025 preview update KB5067036 (builds 26100.7019 / 26200.7019).
• Closing Task Manager with the top‑right X can leave taskmgr.exe running; reopening spawns additional taskmgr.exe instances.
• Workarounds (End task, taskkill, reboot) clear the orphaned processes; uninstalling the preview or avoiding optional updates prevents exposure.

Cross‑referencing the Microsoft KB with independent reporting provides reasonable confidence in the facts above while acknowledging that Microsoft’s final engineering notes (a formal root‑cause and patch) are required for definitive confirmation.

---

Caveats and unverified claims​

Some scattered online reports around the same servicing window described installation failures or highly negative outcomes (for example, setup reaching 100% then failing, or isolated “bricking” anecdotes). Those claims are inconsistent and vary in detail; they remain unverified and require vendor telemetry or reproducible evidence before being treated as part of this Task Manager issue. Flag such reports as cautionary and prioritize confirmed, reproducible diagnostics over anecdote.

---

Recommendations — short, tactical checklist​

• If you need maximum stability on production devices, do not install optional preview updates like KB5067036. Use Windows Update settings and Windows Update for Business policies to block preview channels.
• If KB5067036 is installed and you observe duplicate Task Manager entries, run:
• taskkill /im taskmgr.exe /f (elevated) — clears all taskmgr.exe instances.
• For ongoing monitoring, use:
• tasklist /FI "IMAGENAME eq taskmgr.exe" or Get‑Process -Name taskmgr to detect duplicates.
• For enterprise fleets: stage the preview to a pilot ring only, collect ETW/ProcMon traces from any reproducing device, and prepare a rollback script that kills orphaned taskmgr.exe processes until Microsoft publishes a fix.

---

Lessons for QA and update governance​

This incident underscores several important, actionable lessons:

• Lifecycle paths must be exhaustively tested. Simple user actions — open, close, restart — exercise critical teardown code that should be included in automated end‑to‑end tests. A fix to process grouping accidentally touching the close path highlights why lifecycle regression tests matter.
• Preview channels work, but scope must be limited. Preview updates surface environment‑specific regressions. Enterprises must confine previews to pilot rings and gather diagnostics before broader deployment.
• Fast, transparent vendor communication reduces helpdesk burden. When the KB page and Release Health dashboard are updated with a known‑issue entry and mitigation guidance, administrators can act quickly; until then community threads fill the guidance gap.

---

Conclusion​

KB5067036’s Task Manager duplication issue is a tangible but manageable regression: it can turn a core diagnostic tool into a quiet resource accumulator on affected Windows 11 systems. The problem is tied to an October 28, 2025 preview update and is reproducible on many devices but not universal. Practical mitigations — End task, taskkill /im taskmgr.exe /f, and reboot — restore normal behavior immediately, and administrators should withhold optional previews from production until Microsoft confirms and issues a fix. This episode is a useful reminder: preview updates are invaluable for validating changes at scale, but they must be staged and instrumented carefully. When lifecycle regressions touch a system utility as central as Task Manager, the prudent path for most users and IT teams is to prioritize stability, collect reproducible diagnostics, and rely on staged pilot rings to catch edge cases before broad deployment.

---

---

Source: How-To Geek Task Manager Is Cloning Itself on Windows 11

Microsoft’s long‑promised Start menu redesign arrived for mainstream Windows 11 users in the October 2025 non‑security preview (KB5067036), but the new single‑page Start surface and fresh layout options have arrived with a selection of odd regressions that are already frustrating testers and early adopters. The most visible issues reported so far range from newly installed apps and their Start‑menu folders not appearing until Explorer is restarted, to a one‑time “scroll to top” misbehavior when interacting with the app list — and, separately, an unrelated but serious regression that leaves duplicate Task Manager processes running after you close the window. These problems expose both the risks of staged feature rollouts and shortcomings in update QA for core shell components. The update itself was released as a preview on October 28, 2025 and ships as OS builds 26200.7019 and 26100.7019.

Background and overview​

Microsoft packaged the Start redesign into the October 28, 2025 preview update (KB5067036) with a stated goal of improving discoverability and space use in the Start experience. The headline changes include a single, vertically scrollable Start canvas that places the full All Apps inventory on the main page, new All‑Apps views (Category, Grid / List), and better on‑screen adaptability for larger displays. The KB notes these features are rolling out gradually by flighting and server‑side gating; that is, installing the preview does not guarantee the UI will flip on immediately for every device. The same preview also bundles a handful of other UX tweaks — colorful battery icons, File Explorer recommended feed updates, and some internal Task Manager process‑grouping changes — the latter of which appears to be closely tied to the duplicate Task Manager process regression that surfaced almost immediately in community testing. Independent outlets and community threads reproduced the Task Manager behavior in the days after the preview landed and published step‑by‑step verifications.

---

What users are seeing: Start redesign bugs reported in the field​

1) Installed apps' Start‑menu folders not appearing until Explorer restart​

Several testers activating the new Start menu reported that apps which create a folder in Start Menu > Programs (for example, VMware Workstation which typically creates a VMware folder containing multiple shortcuts) do not appear in the Start app list immediately after installation. The folder and shortcuts exist on disk and are discoverable via Explorer (Right‑click an app → Open file location), but the Start UI fails to surface the new folder until either File Explorer or the system is restarted. This behavior appears to specifically affect apps that add a folder to the Start Menu > Programs directory. The condition has been reproduced by multiple independent testers using fresh installs and virtual machines. Why this matters: installers, packaging tools, and deployment scripts rely on deterministic Start‑menu behavior. If the shell does not pick up new start‑menu entries reliably, installers look broken and automated imaging or provisioning workflows can produce confusing results for end users.

2) First‑open misbehavior: Start scrolls to the top on click​

A second, more tactile regression affects the first time you open Start after a File Explorer restart or a full reboot. Left‑clicking or right‑clicking an entry in the app list will, in some cases, cause the Start menu to immediately scroll to the top of the list — landing the pointer on a different app than intended. The effect appears to be a one‑time occurrence: after that initial misclick and the resultant unexpected scroll, subsequent interactions behave normally until the next restart. Testers replicated this across multiple machines and configurations when they enabled the redesigned Start surface. The original community reporter described both issues (missing folders and one‑time scroll) after enabling the redesign on several devices.

3) Task Manager duplication: an unrelated but high‑impact regression​

Arguably the most consequential problem reported during the KB5067036 preview rollout is that closing Task Manager with the window “X” can leave the underlying taskmgr.exe process running. When Task Manager is reopened, a new visible instance appears while the earlier process remains resident in memory. Repeating open→close cycles can accumulate multiple taskmgr.exe processes that persist until explicitly killed or the system is restarted. Community tests report each orphaned instance typically consumes on the order of 20–30 MB of RAM and occasional small CPU sampling spikes; in pathological contrived tests the aggregate can sum to gigabytes of memory. This behavior has been reproduced by a number of outlets and community members and is tied to the same preview update.

---

Reproducing and verifying the bugs (short, actionable steps)​

These reproduction steps are intended for testers and IT staff who need to confirm whether a device is affected. Treat preview updates with caution on production machines.

• Confirm the OS build: Press Windows+R → winver and verify you have build 26200.7019 or 26100.7019 (KB5067036 preview).
• To reproduce the Start menu missing‑folder symptom:
• Enable the redesigned Start (if not enabled automatically) or install an environment that already displays the new Start canvas.
• Install an application that creates a Start Menu > Programs folder (for example, VMware Workstation, some Office installers, or other multi‑shortcut apps).
• Open Start → All apps and search visually for the new folder. If not visible, right‑click an existing app and choose Open file location to navigate to the file system and confirm the folder exists.
• Restart File Explorer (via Task Manager → restart explorer.exe) or reboot. If the folder appears only after restarting Explorer, the system reproduces the issue.
• To reproduce the one‑time scroll behavior:
• Restart File Explorer or reboot to ensure the Start surface is freshly loaded.
• Open Start and attempt to click an entry away from the top of the list (for example, Photos).
• If Start immediately scrolls to the top on first click and opens a different app, the condition is present. Repeat after reboot to confirm the one‑time nature.
• To reproduce the Task Manager duplication:
• Open Task Manager (Ctrl+Shift+Esc).
• Click the top‑right Close (X) button to close the window.
• Reopen Task Manager and check the Processes tab (expand Background processes).
• If you see more than one “Task Manager” entry and it grows with repeated open→close cycles, the device exhibits the duplicate process regression. Confirm with PowerShell: Get‑Process -Name taskmgr.

---

What the official release materials say (and what they don’t)​

The Microsoft support page for KB5067036 lists the Start menu redesign as a new addition and documents the new scrollable All section, Category and Grid views, and the responsive layout behavior. It explicitly marks the package as a preview and notes staged delivery for many features. The KB does reference fixes for Task Manager’s process‑grouping behavior in the change list, but it did not — at the time these community reports surfaced — list the Task Manager duplication or the Start‑menu app‑folder visibility problems as known issues in the KB’s known‑issues section. Independent reporting from major outlets corroborates the Task Manager duplication as real and reproducible and advises users to avoid closing Task Manager with the “X” button or to use taskkill to remove orphaned processes until a fix arrives. The Verge, PC Gamer and TechRadar published confirmations of the Task Manager issue within days of community disclosures.

---

Technical analysis: likely cause and why these bugs slipped through​

These regressions illustrate a predictable class of problems that emerge when changes touch lifecycle and UI integration code paths.

• Start menu app‑folder visibility: The Start shell maintains an index of Start‑menu shortcuts and folders that the UI maps into the All Apps view. If that indexing and change‑notification pathway (FileSystemWatcher or equivalent shell notification handlers) fails to fire or if the Start process does not refresh its in‑memory catalog after the installer writes new shortcuts, new folders will exist on disk but not in the UI. The fact that File Explorer or an Explorer restart forces the UI to reflect the change strongly suggests the update introduced a timing or notification regression between the Start process and the shell’s folder enumeration. This is consistent with the behavior being limited to items that create folders under Start Menu > Programs.
• Start scroll‑to‑top on first click: The one‑time scroll behavior points to an initialization race in the Start control’s selection/scroll anchoring logic. On first open, the UI may not have fully populated metrics for measured items, resulting in an early focus or selection event that anchors scroll to the top when a click triggers before the layout stabilizes. Because the problem tends to occur only once per Explorer session, an initialization ordering issue is the most plausible explanation.
• Task Manager duplicate processes: Microsoft’s KB explicitly referenced fixes to Task Manager’s process grouping, which suggests engineers changed grouping, sampling, or lifecycle code paths. The duplication bug looks like a teardown/lifecycle regression where the visible window is destroyed but background sampling threads, COM references, or other owned objects are not freed, causing the taskmgr.exe process to remain resident. When a fresh Task Manager instance is started, the older resident process remains, producing duplicate live processes. The observed memory footprint per orphaned instance and the fact that reboots clear the problem are consistent with lingering background threads or unreleased references rather than persistent leaked kernel resources. Outlets and test reproductions support this hypothesis, though Microsoft has not published an engineering post‑mortem to confirm the exact root cause.

---

Impact assessment: who is affected and how badly​

• Consumers and power users: Those who installed the preview to get the new Start layout will experience annoying usability regressions (missing app folders, the one‑time scroll) but can mitigate them with an Explorer restart or reboot. The Task Manager duplication is more serious for power users who open Task Manager frequently because the resource cost accumulates and can affect responsiveness and battery life on laptops.
• IT departments and administrators: The Start menu behavior breaks expectations for imaging scripts, deployment tests, and user training. Because Microsoft stages UI features and gates many experiences server‑side, identical builds can behave differently across devices — complicating pilot programs. The Task Manager duplication introduces operational risk for managed devices where Task Manager is used for monitoring; administrators should avoid deploying the preview widely and collect diagnostic artifacts if devices are affected.
• Enterprises with compliance and automation: Automated packaging and shortcut management rely on consistent Start behavior; failures to surface newly created Start‑menu folders could impede scripted deployments, training, or compliance checks. Enterprises should delay preview adoption in production rings until remediation is confirmed.

Scope and prevalence: community reports and independent testing reproduced these issues on multiple machines and virtual machines, but the precise percentage of affected devices is not publicly verifiable. Some outlets reported significant reproduction rates in small VM fleets (for example, an individual outlet’s VM tests), but those sample sizes do not prove broad incidence. Treat community reproduction as evidence of a real regression with variable environmental triggers; the staged rollout model and server‑side gating mean not all devices will show the problem. Flag: the true global impact remains unverifiable without Microsoft telemetry.

---

Immediate mitigations and workarounds​

For end users:

• If newly installed apps do not appear in Start:
• Restart File Explorer (open Task Manager → find Windows Explorer → Restart) or reboot the machine. This forces the Start UI to refresh its catalog and usually makes the newly created folders appear.
• As a quick diagnostic, right‑click a known app and choose Open file location to confirm the shortcuts exist on disk.
• For the one‑time Start scroll:
• If Start unexpectedly scrolls to the top, simply reopen Start after the first misclick or restart explorer if it persists. The bug tends to be a single occurrence per Explorer session.
• For Task Manager duplicates:
• Avoid closing Task Manager with the top‑right “X” button until Microsoft issues a fix. Use the “End task” action or run taskkill /im taskmgr.exe /f from an elevated command prompt to terminate all Task Manager instances. Rebooting clears accumulated orphaned instances. Multiple outlets recommended these steps as temporary containment.

For IT administrators:

• Do not deploy the KB5067036 preview to production rings. Treat it as a pilot/preview release and keep it confined to test or evaluation rings.
• If pilot devices must install the preview, add detection scripts that run tasklist /FI "IMAGENAME eq taskmgr.exe" to identify multiple taskmgr.exe instances and remediate via taskkill when necessary.
• Collect trace artifacts for Microsoft:
• ProcMon captures, ETW traces, and a Feedback Hub repro with Winver screenshots and tasklist outputs accelerate vendor triage. Microsoft often requests these artifacts to reproduce and diagnose regressions.
• Monitor Microsoft Release Health and the KB article for a known‑issue acknowledgement and patch information. Historically, Microsoft issues follow‑up fixes when a regression is confirmed and impactful.

---

Quality‑assurance and process critique​

These regressions expose a recurring tension in modern Windows servicing:

• Staged server‑side gating and preview packaging are valuable for reduced blast radius, but they mean optional previews reach a broad set of real‑world environments where edge conditions are discovered by end users rather than in closed test labs. That accelerates discovery but shifts more QA onto the community.
• UI changes that touch the shell and process‑lifecycle code require rigorous end‑to‑end lifecycle testing. The Task Manager duplication suggests the shutdown path was insufficiently exercised in pre‑shipping tests, or the fix altered reference counting or thread lifetimes in a way that escaped regression tests.
• The partial fix pipeline in Insider builds illustrates that Microsoft is aware of and iterating on these behaviors in earlier rings; however, the presence of the same or similar regressions in a preview that reaches mainstream machines raises questions about gating thresholds and cross‑ring bug migration. Some fixes noted in Insider builds reportedly addressed similar scrolling problems weeks earlier, but those fixes did not appear to reach all preview users before this wider preview was issued. This mismatch between Insider fixes and preview rollouts erodes user confidence when regressions surface in “stable” preview builds.

Caveat: while these observations are grounded in technical patterns and community evidence, definitive statements about Microsoft’s internal QA processes or why specific changes landed without catching these regressions are speculative unless Microsoft publishes a formal root‑cause post‑mortem.

---

Longer‑term implications and recommended changes​

• Harden lifecycle testing: Automated regression suites should specifically exercise open→close→reopen cycles, window teardown handlers, and file‑system change notifications for Start, Explorer, and Task Manager on a wide matrix of hardware and driver configurations.
• Improve rollout transparency: Microsoft should make it clearer which fixes are gated server‑side versus shipped in the binary, and maintain a public ledger of Insider fixes that have yet to reach preview or production rings so IT pros can map risk more accurately.
• Provide a safe rollback or opt‑out for major UX surface changes: When a core UI like Start is redesigned, enterprises and power users benefit from an easy and supported rollback path or a per‑device policy that pins the old UX until validation completes.
• Increase telemetry thresholds for core utilities: Process teardown regressions can quietly accumulate resource consumption; elevated automated alerts when background processes persist after window closure would surface such regressions earlier in controlled rings.

---

What to watch next​

• Microsoft Release Health and the KB5067036 support article for a known‑issue acknowledgement and a corrective update. The KB and Release Health pages are authoritative for status and patch availability.
• Independent outlets and community threads for reproduction reports and verified workarounds. Early reporting from The Verge, PC Gamer, TechRadar and community forums documented the Task Manager behavior; watching those channels provides rapid situational awareness as fixes roll out.
• Insider channels for fixes: Microsoft frequently iterates in the Insider program before backporting changes to preview and production. If you need the new Start features but want stability, follow the Insider flight notes to see when corresponding fixes land and get rolled into preview or cumulative updates.

---

Final assessment​

The Start menu redesign in KB5067036 is a long‑awaited UX improvement for many Windows users: a single, scrollable All page and new Category/Grid views provide improved discoverability and better use of screen real estate. The update’s stated goals and the KB’s feature list show Microsoft is investing in shell refinements that users have requested. However, the practical reality of field testing a large, component‑level change is that small lifecycle or notification regressions can have outsized impact when they affect installers, user workflows, or a core diagnostic tool like Task Manager. The preview’s combination of Start‑menu display glitches and the Task Manager duplication regression highlights the need for more exhaustive lifecycle QA for core shell components and clearer rollout controls so enterprises and power users can adopt changes on a predictable timetable. Until Microsoft issues a formal fix or a known‑issue acknowledgment, testers and administrators should exercise caution, apply the containment steps above, and collect diagnostic artifacts to accelerate remediation. The arrival of better Start experiences is welcome, but shipping them without ironclad lifecycle stability for apps and management tools undermines the benefit. Users who rely on stable behavior should defer preview updates; enthusiasts who adopt early should prepare to troubleshoot and contribute detailed repro data to Feedback Hub so engineering teams have the traces they need to push a timely, reliable fix.

---

Source: Neowin Windows 11's redesigned Start menu has some very strange bugs