Microsoft has quietly closed a puzzling lifecycle regression in Windows 11 that left invisible Task Manager processes running after you clicked the Close (X) button — the November cumulative update (KB5068861) restores the expected behavior and prevents multiple background instances of taskmgr.exe from accumulating.
Background / Overview
The issue first surfaced after an optional preview cumulative update, KB5067036, was rolled out on October 28, 2025. That preview included several UI and under‑the‑hood changes — notably adjustments to Task Manager’s process‑grouping logic — and within days community testers reproduced a reproducible regression: closing Task Manager via the window Close (X) sometimes failed to terminate the underlying process, so reopening the utility could spawn new visible instances while previous taskmgr.exe processes continued running invisibly.
Microsoft tracked the reports and incorporated a repair into the November Patch Tuesday cumulative update, KB5068861. Installing the November cumulative returns Task Manager’s teardown semantics to the expected state: clicking Close ends the process rather than leaving a “ghost” instance behind. The company’s release notes and community reproductions align on the fix being part of that November rollup.
What users actually saw (symptoms and reproduction)
The symptom is simple to reproduce on affected systems and therefore easy to observe for power users and IT staff.
- Open Task Manager (for example, Ctrl+Shift+Esc).
- Close it using the top‑right Close (X) button.
- Reopen Task Manager and inspect the Processes tab or run a process listing.
On machines exhibiting the bug, repeated open→close cycles produced multiple “Task Manager” entries in Processes (and multiple taskmgr.exe processes in Details), with each prior instance remaining resident until explicitly terminated or the system was rebooted. These were bona fide OS processes, visible to Process Explorer, tasklist, and PowerShell’s Get‑Process — not merely UI duplicates.
Quick verification commands
- In Command Prompt: tasklist /FI "IMAGENAME eq taskmgr.exe"
- In PowerShell: Get-Process -Name taskmgr
If those commands return more than a single taskmgr.exe entry after the open→close sequence, the device was affected.
Measured impact: resource footprint and practical risk
Community stress tests and independent reproductions reported a modest per‑instance memory footprint — commonly in the
20–30 MB range per orphaned taskmgr.exe — with occasional small CPU polling spikes. That per‑instance cost is small, but repeated accumulation (especially on long‑running desktops, developer machines, or VMs that seldom reboot) can add up to hundreds of megabytes or more and produce perceptible slowdowns on memory‑constrained devices. Extreme, contrived test runs that opened and closed Task Manager hundreds of times showed multi‑gigabyte totals in aggregate.
Important practical notes:
- Orphaned taskmgr.exe processes are cleared by a reboot; the effect was an operational nuisance and resource waste, not data corruption or persistent system damage.
- For casual users who open Task Manager occasionally and reboot regularly, the user‑impact is low; for power users and IT support teams that frequently use the utility, the regression was materially annoying and operationally relevant.
Timeline: preview → community detection → patch
- October 28, 2025 — Microsoft published the optional preview cumulative KB5067036. Community testers began reproducing a Task Manager lifecycle regression shortly after the rollout.
- Early November 2025 — Community reporting and independent outlets documented reproductions, mitigation steps, and operational guidance while Microsoft triaged the issue.
- November Patch Tuesday (November 11, 2025) — Microsoft shipped the November cumulative (KB5068861), which includes a targeted remediation that restores correct Task Manager teardown behavior. Installing that cumulative resolved the ghost taskmgr.exe accumulation for affected builds.
If your device received updates released on or after October 28, 2025, and you installed the preview, the November cumulative is the corrective package to apply to eliminate the symptom.
Official acknowledgement and affected versions
Microsoft documented the symptom on its Windows Release Health / known issues pages referencing the October 28 preview (KB5067036) and explicitly indicated that closing Task Manager using the Close (X) button might not fully terminate the process on affected devices. The remediation was rolled into KB5068861 and later cumulative updates. Client builds impacted included Windows 11, version 24H2 and 25H2; no server SKU was identified as affected in the vendor notes.
Immediate mitigations and practical workarounds
While waiting for the November cumulative, users and admins had reliable options to avoid accumulation and reclaim resources. These mitigations are safe and non‑destructive.
- Use Task Manager’s End task instead of the Close (X) button:
- Open Task Manager → Processes tab → find “Task Manager” → right‑click → End task. This triggers the internal teardown path and avoids the buggy close path.
- Force‑kill via command line (fast, effective):
- Open an elevated Command Prompt or PowerShell and run:
- taskkill.exe /im taskmgr.exe /f
- or in PowerShell: Get-Process -Name taskmgr | Stop-Process -Force
These commands forcibly terminate all taskmgr.exe instances and instantly reclaim memory.
- Reboot to clear all orphaned instances — guaranteed but disruptive.
- If the optional preview itself is unacceptable in production, uninstall the KB via Settings → Windows Update → Update history → Uninstall updates (note: combined SSU+LCU packages may complicate removals; follow vendor guidance in those cases).
Caveat for administrators: avoid deploying automated scripts that indiscriminately kill taskmgr.exe across a fleet; Task Manager is a legitimate diagnostic tool, and blind kills can interfere with troubleshooting workflows. Instead, use targeted detection logic and conditional remediation.
How to verify the fix (step‑by‑step)
- Check your build: Press Win+R → winver → confirm OS build family. If you installed KB5067036 you may have seen builds in the 26100/26200 family.
- Update: Settings → Windows Update → Check for updates → apply KB5068861 (or any later cumulative that lists the Task Manager fix) and reboot.
- Reproduce: Open Task Manager → Close (X) → Reopen → inspect Processes. Use tasklist /FI "IMAGENAME eq taskmgr.exe" to confirm only a single taskmgr.exe is present. If the number of taskmgr.exe instances no longer increases, the remediation applied successfully.
Technical analysis: what likely went wrong (and what remains unverified)
At a high level, Task Manager comprises UI threads that drive the window and background sampling threads that query performance counters, collect process groupings, and render aggregated metrics. KB5067036 included a change intended to improve Task Manager’s process‑grouping behaviour; that change plausibly touched lifecycle or teardown semantics and introduced a subtle reference or thread‑lifetime regression where the UI window destroyed while a background worker or held resource prevented the process from exiting. Reopening the utility spawned a new visible instance while the prior process continued running — producing the “ghost” taskmgr.exe instances that users observed.
This hypothesis fits community measurement (per‑instance memory use, visible threads in Process Explorer, and process listings), but
it is not a vendor‑published root‑cause. Microsoft’s public notes confirm the symptom and that a fix was provided; the definitive engineering post‑mortem identifying the exact codepath or handle leak has not been published, so treat the causal narrative as an informed technical hypothesis rather than a confirmed engineering finding.
Why lifecycle regressions are easy to miss in testing
- Lifecycle paths (open → close → reopen) are deeply exercised by users but can be under‑represented in automated preview test suites that focus on feature behavior rather than teardown edge cases.
- Preview/staged rollouts and server‑side feature flags mean the bug can be environment‑dependent and not reproducible on all hardware profiles, making telemetry correlation harder.
- Utilities that integrate with many system subsystems (performance counters, COM, driver telemetry) have many cross‑interaction surfaces that can expose latent timing or reference counting bugs.
Enterprise guidance: triage, detection, and deployment policy
For IT teams managing fleets, the incident provides several concrete operational actions and policy reminders.
- Pause broad deployment of optional preview updates like KB5067036 on production rings. Keep preview updates confined to pilot rings that include support engineers and devices representative of your fleet.
- Detection script (example): use PowerShell to detect more than one taskmgr.exe and trigger conditional remediation.
- Example detection snippet:
Code:
$count = (Get-Process -Name taskmgr -ErrorAction SilentlyContinue).Count
if ($count -gt 1) {
# Log the event, notify admin, and optionally run a conditional kill
taskkill.exe /im taskmgr.exe /f
}
- Note: use with caution — avoid blanket kills in environments where Task Manager may be in active diagnostic use.
- Collect diagnostics if you see the issue: winver screenshot, Process Explorer capture of orphaned instances, ProcMon filter for taskmgr.exe process create/exit events, ETW traces, and a short video showing reproduce steps. Attach these artifacts to a Feedback Hub entry or an enterprise Microsoft support case to accelerate triage.
- Test the November cumulative (KB5068861) in a pilot ring, confirm the remediation, and then roll it out broadly. Maintaining disparate update rings — pilot, broad, production — remains the strongest operational defense against preview regressions.
QA and update governance lessons
This incident is a textbook example of how a small change in a widely used subsystem can amplify into a painful edge case:
- Lifecycle tests must be part of automated suites for core utilities. Automated regression tests should exercise open → close → reopen cycles and concurrency scenarios to catch teardown regressions early.
- Staged rollouts and feature gating are essential, but they require clear telemetry and rapid feedback channels so that environment‑dependent regressions are correlated and addressed quickly.
- Administrators must treat optional preview packages as test artifacts and reserve them for pilot deployments, not broad production use. The cost of a lightly tested preview in a production fleet can be measured in helpdesk load, lost productivity, and remediation overhead.
Strengths and remaining risks
Strengths:
- Microsoft responded through the standard servicing channel: community reports were validated and a corrective cumulative (KB5068861) was released to address the symptom. That demonstrates the preview → pilot → remediation lifecycle working as intended.
- Workarounds were trivial and low‑risk (End task, taskkill, reboot), enabling administrators to contain the issue quickly while waiting for the KB.
Risks and caveats:
- The exact engineering root cause remains unpublicized; until Microsoft publishes a formal post‑mortem, any causal claims should be treated as plausible hypotheses.
- Combined servicing packages (SSU+LCU) sometimes complicate rollbacks, and uninstall paths for preview packages may not always be straightforward — enterprises should test rollback procedures before broad rollout.
Practical checklist — what to do now
- Confirm your PC’s build: Win+R → winver. If you installed updates from October 28, 2025 (KB5067036), check whether you see duplicate Task Manager entries.
- Install the November cumulative (KB5068861) or any later cumulative that includes the Task Manager fix, then reboot. Verify that the Close (X) behavior now ends the process properly.
- If remediation is not immediately possible: use End task or run taskkill.exe /im taskmgr.exe /f to clear orphaned instances as needed.
- For admins: block optional preview updates on production until validated; deploy KB5068861 to a pilot ring and confirm the behavior before fleet‑wide rollout.
Conclusion
A small but visible regression turned Task Manager — Windows’ central troubleshooting utility — into a source of resource accumulation for some users. The lifecycle of the incident followed the predictable preview‑detection‑remediation arc: an October 28, 2025 preview (KB5067036) introduced a change that sometimes prevented Task Manager from fully exiting when closed, community tests and independent outlets reproduced the symptom and supplied practical mitigations, and Microsoft shipped a corrective November cumulative (KB5068861) that restores correct teardown behavior. The fix is available via Windows Update; administrators and power users should apply the November cumulative (or later rollups) and follow the containment steps above if they still encounter ghost taskmgr.exe instances.
This episode is a sharp reminder that even the smallest changes to core utilities require rigorous lifecycle testing, and that staged update policies and rapid telemetry are essential tools for keeping production devices reliable while Windows continues to evolve.
Source: thewincentral.com
Microsoft: A long-existing Task Manager issue in Windows 11 24H2 resolved with latest update. - WinCentral