Windows 11 KB5067036 Task Manager Duplicates Bug Explained

Windows 11’s October preview (KB5067036) is shipping attractive UI changes — a redesigned Start menu, colorful battery icons and fixes for Update & Shut Down — but an emerging, strange regression is putting one of the OS’s core utilities under a microscope: multiple reports show Task Manager’s close button failing to actually terminate the app, leaving behind duplicate taskmgr.exe processes that accumulate and can harm performance on some machines.

Background / Overview​

Microsoft published the KB5067036 preview on October 28, 2025, as an optional non‑security update for Windows 11 (OS builds 26200.7019 and 26100.7019). The official release notes list new Start menu layouts, taskbar battery icon updates, File Explorer recommended feed changes, and a number of quality improvements and bug fixes. Among those fixes is one explicitly addressing how Task Manager groups apps with their processes to show clearer performance usage. The package is being delivered in a staged rollout (gradual and normal phases).
Community reporting began circulating immediately after the preview’s release: users and sites testing the update started observing abnormal Task Manager behavior — specifically, that clicking the window close button (the ‘X’) sometimes does not terminate Task Manager, and each open/close sequence leaves another taskmgr.exe process running in the background. The issue was first documented in detail by an independent report that reproduced the behavior, and it has been corroborated by multiple user posts and community threads.

---

What’s happening: Task Manager “ghost” instances explained​

The symptom in short​

• Open Task Manager (Ctrl+Shift+Esc).
• Click the top-right Close (X) button.
• Reopen Task Manager and inspect Processes.
• If affected, you’ll see multiple entries for “Task Manager” and the count increases each time you repeat the open → close cycle.

Independent testing shows these leftover processes are real, not just UI artifacts: they remain listed as running processes (taskmgr.exe) and consume memory while persisting until explicitly terminated. One tester opened and closed Task Manager ~100 times and observed roughly 20–25 MB RAM per orphaned instance, which summed to about 2 GB of RAM used by orphaned Task Manager processes in that contrived test. That degree of accumulation would be noticeable on low‑end systems and could affect battery life and overall responsiveness.

Where the problem likely came from​

Microsoft’s release notes note a fix for Task Manager’s process grouping behavior — that is, changes to how the Task Manager maps UI rows to underlying processes and shows performance usage. The bug that leaves taskmgr.exe instances behind looks like a regression in the shutdown/close path for the Task Manager window: a close handler or reference‑counting path that should fully terminate the process may not be executing correctly in the affected build, causing the main process to stay resident while a new instance starts and appears to the user as a new app window.
This is consistent with a class of bugs where UI or window‑manager changes alter lifecycle sequencing (for example, a new grouping subsystem might retain references to objects that prevent normal exit). That hypothesis fits the timeline: a fix in process grouping shipped in KB5067036, and users report Task Manager close behavior breaking immediately after moving to the preview build. The vendor has not, at time of writing, posted a known‑issue acknowledgement specifically describing Task Manager duplicate processes.

---

How to verify whether you’re 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 on Task Manager.
• Open Task Manager again and switch to the Processes tab.
• If you see more than one “Task Manager” entry and the number increases each time you repeat the open/close action, your machine exhibits the issue.

If you don’t see duplicates after repeated open/close cycles, you are not affected. Community reports indicate the bug is not universal — it reproduces on some machines and not others, which points to an environmental trigger (driver/service combination, specific hardware, or staged feature gating).

---

Immediate mitigation and safe workarounds​

If you see the behavior, apply the following practical steps to prevent resource accumulation and to recover quickly.

• Stop using the window Close (X) button to shut Task Manager. Instead:
• Use Task Manager’s own End task option to terminate its process tree.
• Or run the command: taskkill /im taskmgr.exe /f from an elevated Command Prompt or PowerShell to kill all Task Manager instances at once.
• To inspect lingering processes without Task Manager, use:
• PowerShell: Get-Process taskmgr
• Or tasklist | findstr taskmgr
• If resource usage becomes a problem:
• End the taskmgr.exe processes (taskkill).
• Reboot if necessary.
• If you prefer to avoid the preview package altogether, uninstall KB5067036 via Settings → Windows Update → Update history → Uninstall updates (note that the package is a combined SSU + LCU and uninstall semantics can be more complex for combined packages; Microsoft’s KB entry explains removal guidance).

These steps are blunt but effective; they prevent incremental memory bloat from repeated Task Manager opens while you wait for a vendor fix.

---

Why this matters: performance, reliability and trust​

Performance impact​

Each orphaned taskmgr.exe process is small (tens of MB), but they add up. A few dozen orphaned instances can consume hundreds of megabytes or gigabytes of RAM and increase background CPU work if any monitoring threads remain active. That’s particularly visible on low‑memory devices and laptops where every hundred MB matters for system responsiveness and battery life.

Reliability and risk surface​

• The bug highlights how a localized UI fix (process grouping) can ripple into unrelated functionality (window close semantics).
• For power users and sysadmins who open Task Manager frequently for profiling or troubleshooting, the issue is both reproducible and insidious: it can silently accumulate resources.
• For admins managing update rollout at scale, such regressions complicate patching plans and increase rollback risk.

Reputational and operational cost​

October’s servicing cadence has already seen high‑impact regressions this month (for example, earlier October update problems that temporarily broke LocalHost connections for IIS‑based services and a WinRE USB input failure that required an out‑of‑band patch). Those incidents — documented on Microsoft’s Release Health pages and covered in technical press — illustrate that a single servicing cycle can deliver multiple, unrelated regressions across the stack, increasing cost for IT teams and diminishing user confidence.

---

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

• Microsoft’s official KB page for KB5067036 lists the update’s features and fixes (Start menu redesign, battery icons, Task Manager grouping fix among others) and gives guidance for rollout and uninstall. The Task Manager duplication bug is not explicitly listed as a known issue in the KB release notes at the time of writing.
• The vendor previously acknowledged and patched earlier October regressions (WinRE input and IIS/localhost issues) with out‑of‑band fixes and entries on the Release Health dashboard; that indicates Microsoft is tracking high‑severity regressions quickly and issuing emergency patches when required. However, there has not yet been an explicit Microsoft acknowledgement for the Task Manager duplicate instance issue that’s circulating in community posts and independent reporting.

Note: Independent outlets and community threads are already reporting and reproducing the Task Manager issue, but vendor confirmation (which often precedes a KIR or out‑of‑band fix) had not been public at the time of community reporting. Until Microsoft acknowledges, the precise root cause and the exact set of affected builds/hardware remains an open question.

---

Recommended actions for home users and administrators​

For home users and power users​

• If you are not on an Insider/Release Preview path, wait: KB5067036 is optional and delivered gradually; you can delay installing optional preview updates until the vendor marks fixes as broadly available.
• If you installed the update and see Task Manager duplicates:
• Avoid using the Close (X) button to exit Task Manager.
• Use End task or taskkill /im taskmgr.exe /f to clear instances.
• Consider uninstalling the update if you need a headache-free desktop experience and rollback is a viable option for you.
• Create a System Restore point or full backup before applying preview updates in future.

For IT administrators and enterprises​

• Pause or stage the KB deployment:
• Use your usual pilot group to validate quality.
• Don’t push optional preview updates to broad production rings.
• Test the specific scenarios your users rely on:
• Tools like taskmgr.exe are often used by developers, helpdesk staff, and performance teams — include them in your acceptance tests.
• If you see the problem widely:
• Consider rolling back the patch in affected clusters and follow Microsoft guidance for LCU/SSU combined packages (the KB notes include removal instructions).
• File telemetry and repros with Microsoft:
• Use Microsoft Q&A/Support and Feedback Hub to upload reproducible traces, ETW logs and short screen recordings. Collect hardware and driver inventory to speed triage.

These steps reduce the chance that a seemingly small UI issue will create larger operational problems across many endpoints.

---

Technical analysis and forensic pointers​

Why a close button can fail to terminate a process​

Closing a window is typically a sequence of messages and cleanup actions (WM_CLOSE → WM_DESTROY → process exit). Modern applications sometimes use a separate monitor or helper thread, COM servers, or global process hooks to maintain functionality across restarts. If a fix modifies the way Task Manager enumerates child processes or binds to system services (for grouping or perf counters), it could inadvertently leave active threads or object references, preventing process exit. The next launch of Task Manager spawns a fresh process that surfaces as a second “Task Manager” entry while the previous one remains resident.

Forensic steps for developers and support teams​

• Reproduce the issue on a controlled VM and capture:
• Procmon trace filtered for taskmgr.exe
• ETW traces for process create/exit events
• A minimal video showing open → close → open sequence and process list
• Compare thread stacks for the orphaned taskmgr.exe to see which modules are active.
• Inspect handles and loaded DLLs to find references that prevent termination (Process Explorer → Handles, DLL view).
• Collect environment data: third‑party security software, shell extensions, performance monitoring tools that may hook Task Manager.

If you intend to file a repro with Microsoft, include these artifacts to help engineering reproduce and triage faster.

---

Strengths of KB5067036 — why the update matters​

Despite the regression risk, KB5067036 contains several positive, user‑facing changes:

• Start menu redesign with scrollable All apps and category/grid views intended to improve discoverability.
• Taskbar battery icons with color indicators and percentage options that give clearer battery state at a glance.
• Fixes for Update & Shut Down so Windows can finish installation and power off when selected from the Start menu.
• A stated fix for Task Manager’s grouping behavior, which, in theory, improves clarity when identifying a process’s resource usage.

These are worthwhile improvements, especially for Copilot‑enabled and Copilot+ PCs where discoverability and clear system signals matter.

---

Risks, QA observations and what should change​

• The emergence of multiple unrelated regressions in a single servicing window (WinRE input, IIS/localhost issues, now Task Manager duplication reports) suggests that tightly coupled changes across UI, networking and recovery components can create cross‑cutting failures.
• Staged rollout reduces exposure, but staged enablement + optional preview + aggressive feature flags can still expose many users — especially those on Release Preview rings and enterprise pilots — to incomplete interactions between features.
• QA for lifecycle events (close/exit, uninstall, rollback) must be prioritized; the “close” path is fundamental and frequently exercised by both users and monitoring tools.
• Microsoft’s communication cadence matters: quick, transparent acknowledgement and a mitigation roadmap (KIR, patch or guidance to uninstall/avoid) reduce churn and admin labor.

---

How to report and speed a fix​

• Submit a detailed Feedback Hub entry (use Recreate feature) with:
• Steps to reproduce.
• Winver screenshot with build number.
• Process Explorer or tasklist output showing multiple taskmgr.exe entries.
• Short recording of the reproduction (open → close → open).
• If you’re an enterprise customer, open a support case with Microsoft and attach repro artifacts and telemetry.
• Monitor Microsoft’s Windows release health pages and the KB article for updates and out‑of‑band fixes. Microsoft has used out‑of‑band updates previously to fix critical issues (for example, the WinRE input problem in mid‑October), so an emergency fix is an established path for high‑impact regressions.

---

Conclusion​

KB5067036 brings visible UI improvements and several welcome fixes, but the community discovery of Task Manager duplicate/ghost instances underscores the fragility of complex updates where a fix in one subsystem can break a fundamental lifecycle path in another. For now, affected users should avoid closing Task Manager with the window X, use End task or taskkill to remove orphaned instances, and consider uninstalling the optional preview if the behavior materially impacts their workflows.
System administrators should treat this as a reminder to stage preview updates, validate critical management workflows in pilot rings, collect reproducible diagnostics, and report findings to Microsoft to accelerate a fix. Given Microsoft’s rapid response to prior October regressions, an acknowledgment and patch are likely once enough reproducible reports and telemetry are aggregated — but until then, cautious update practices and the mitigations in this article are the most reliable defense against unexpected performance regressions.

---

WindowsForum community threads and independent testing have traced and reproduced this Task Manager behavior in the KB5067036 preview, and Microsoft’s official KB and Release Health pages document the update details and other October servicing incidents; affected users and admins should follow the mitigation steps above while awaiting vendor guidance.

---

Source: Windows Latest Windows 11 KB5067036 issue: Task Manager won’t close and duplicates, may hurt performance

 

[ChatGPT]

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

 

[ChatGPT]

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

 

[ChatGPT]

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

 

[ChatGPT]

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