Windows 11 users saw a surprising regression in late‑October 2025: closing Task Manager with the window’s Close (X) button could leave the underlying taskmgr.exe process running and, on repeated use, spawn
additional Task Manager processes — a reproducible duplication bug tied to the optional preview cumulative update KB5067036 that Microsoft later addressed in a November cumulative patch.
Background / Overview
Microsoft shipped the optional preview update identified as
KB5067036 on October 28, 2025. The package targeted Windows 11 builds
26100.7019 and
26200.7019, and bundled a set of UI and reliability changes, including an explicit adjustment to Task Manager’s process‑grouping behavior. Within days, multiple independent testers and community threads reproduced a lifecycle regression: closing Task Manager didn’t always terminate the process, and reopening the app could leave an orphaned taskmgr.exe running while another instance started.
That behavior is not a cosmetic UI quirk. The leftover processes are real OS processes visible in Task Manager’s Details tab, Process Explorer, and command‑line tools such as tasklist or PowerShell’s Get‑Process. Each orphaned instance commonly consumed roughly
20–30 MB of RAM in community tests, with low but measurable CPU polling activity; aggregated, many orphaned instances could meaningfully affect low‑RAM systems.
Microsoft tracked the issue and published mitigation guidance, later rolling a corrective cumulative update in November that restored the expected Task Manager teardown behavior for affected builds.
What the bug looks like (reproduction and detection)
Quick reproduction steps
- Press Ctrl + Shift + Esc to open Task Manager.
- Close Task Manager using the window Close (X) button.
- Reopen Task Manager and switch to Processes → Background processes or the Details tab.
- Repeat steps 1–3 several times; if you see multiple “Task Manager” or multiple taskmgr.exe entries, the device is affected.
How to verify from the command line
- In Command Prompt: tasklist /FI "IMAGENAME eq taskmgr.exe"
- In PowerShell: Get-Process -Name taskmgr
These commands list live taskmgr.exe processes and make it trivial to detect orphaned instances without relying on the Task Manager UI.
Immediate fixes and workarounds (practical, safe)
This bug is annoying but
manageable. Multiple low‑risk mitigations were reproducible and widely recommended while Microsoft worked on a fix.
1. End Task from Task Manager (GUI)
- Open Task Manager (Ctrl + Shift + Esc).
- In the Processes tab, expand Background processes and find each “Task Manager” entry.
- Select an entry and click “End task.” Repeat until no orphaned entries remain.
This avoids triggering the faulty Close (X) path and safely terminates residual instances.
2. Kill Task Manager from the command line (fast)
- Open the Run dialog (Win + R), type cmd, then press Ctrl + Shift + Enter to run as administrator.
- Run: taskkill.exe /im taskmgr.exe /f
That forcibly terminates all taskmgr.exe instances immediately and is the fastest way to reclaim memory. PowerShell equivalent: Get-Process -Name taskmgr | Stop-Process -Force.
3. Reboot
A full restart clears all in‑memory orphaned processes; this is a blunt but guaranteed fix when resource pressure is visible.
4. Use Sysinternals Process Explorer for advanced inspection
Process Explorer will reveal thread stacks, handles, loaded modules and can kill specific processes without triggering additional UI lifecycle paths. It’s the best tool for triage when you need detailed diagnostics.
5. Uninstall the optional preview (if necessary)
If you prefer a stable environment and are on production devices, you can uninstall KB5067036 via Settings → Windows Update → Update history → Uninstall updates. Note that some combined SSU/LCU packages have tricky semantics; consult your update management process before broad rollbacks.
A note on the registry "fix" and community patches
Some community contributors published registry edits and scripts that purported to prevent Task Manager from duplicating or running in the background. These community remedies can be tempting for users who want a quick, seemingly permanent fix.
- Treat registry edits as community‑sourced, potentially risky fixes. Modifying HKEY_LOCAL_MACHINE or other core keys can have unintended consequences — particularly on managed devices — and should only be applied after careful inspection (open the .reg file in a text editor first) and with a tested rollback plan.
- If a community solution (for example, a GitHub repository) is proposed, verify the change line‑by‑line and test in a VM or non‑critical device before applying in production. If you cannot validate the exact registry changes or their provenance, do not apply them. Flag such interventions as unverified until you have confirmed their effect and safety.
Technical analysis — what likely went wrong
Multiple independent commentators and community engineers converged on the same plausible hypothesis: the update altered Task Manager’s process‑grouping or teardown logic in a way that interfered with the close/unload path.
- Task Manager runs a UI thread that owns the window and additional background threads that sample performance counters and marshal data. If a change to grouping or object ownership altered reference counting, thread lifetime, COM object release ordering, or message teardown semantics, the UI could be destroyed while a background sampling thread remained alive — preventing process exit. Relaunching the app then spawns a new process while the residual thread continues to run, producing the duplicated processes seen in practice. This hypothesis fits the observed symptoms and the change log note about grouping behavior.
- Important caveat: this is an informed technical hypothesis that fits the facts captured by community tests and reproductions, but Microsoft’s formal engineering post‑mortem (if published) is the only conclusive root‑cause. Treat the hypothesis as plausible but not verified until vendor confirmation.
Measured impact and who should worry
- Per‑instance memory: community tests repeatedly measured ~20–30 MB per orphaned taskmgr.exe; aggregated instances can consume hundreds of MB or more under stress cycles.
- CPU: each orphaned instance typically used a small amount of CPU (often 0–2%) during periodic polling. Aggregated CPU use across many instances can cause perceptible stutter and battery drain on laptops.
- Who is most affected:
- Power users, developers, support engineers and admins who open and close Task Manager frequently (they exercise the lifecycle path more aggressively).
- Low‑RAM devices (8 GB or less) where tens or hundreds of megabytes matter.
- Managed enterprise fleets that installed the preview widely without pilot rings.
For casual users who open Task Manager occasionally and reboot nightly, the practical risk is low; for helpdesk teams and developers, the issue is actionable and should be addressed with the mitigations described above.
Timeline and Microsoft’s response
- October 28, 2025: Microsoft released the optional preview cumulative update KB5067036. Community testing quickly reproduced the Task Manager duplication regression on affected builds.
- Community reporting and independent outlets published reproduction steps and mitigation advice (End task, taskkill, reboot), and enterprise guidance recommended holding preview updates on production machines.
- November cumulative update: Microsoft included a targeted remediation in the November 2025 Patch Tuesday cumulative (reported as KB5068861), which restored expected Task Manager lifecycle behavior for affected builds. Users who applied that update saw the closing semantics return to normal.
This sequence shows the lifecycle of a preview regression: staged preview ➜ community detection and mitigation ➜ vendor remediation in a later cumulative. The community mitigations bought time for users and administrators until Microsoft issued a supported fix.
Step‑by‑step remediation guide (concise)
Follow these prioritized actions based on your role and risk tolerance.
For home users and power users
- Check your build: Win + R → winver — look for 26100.7019 or 26200.7019 if you installed KB5067036.
- If you see duplicate Task Manager entries, run an elevated command prompt and execute:
taskkill.exe /im taskmgr.exe /f
or in PowerShell: Get-Process -Name taskmgr | Stop-Process -Force.
- Avoid using the Close (X) button on Task Manager until a fix is applied; use End task instead.
- If you prefer absolute stability, uninstall the preview via Settings → Windows Update → Update history → Uninstall updates.
For IT administrators and helpdesk teams
- Pause deployment of KB5067036 to broad production rings; restrict it to a pilot ring containing support and developer endpoints.
- Add a detection script to triage workflows: PowerShell Get-Process -Name taskmgr and conditionally run taskkill when counts exceed 1. Use caution; do not indiscriminately kill taskmgr.exe on all endpoints without context.
- Collect repro traces (ProcMon, ETW, Process Explorer stacks) from affected devices and open a Microsoft support case if you need vendor triage. Attach winver screenshots.
- Apply the November cumulative (or any subsequent Microsoft patch that explicitly lists the Task Manager fix) once validated in your test ring.
Risks, caveats, and verification guidance
- Registry edits and community scripts: treat these as unverified fixes until you can validate them in a non‑production environment. Always inspect .reg files and scripts in a text editor and maintain backups and system restore points prior to applying changes.
- Automatic kill scripts: do not deploy scheduled scripts that kill taskmgr.exe blindly across a fleet. Task Manager is a legitimate troubleshooting tool; automated termination can interfere with diagnostics and support workflows. Use targeted remediation based on detection logic instead.
- Uninstall semantics: some combined servicing packages (SSU + LCU) can complicate uninstall; follow documented removal guidance for combined updates in enterprise scenarios and test rollback procedures first.
- Root‑cause certainty: community technical hypotheses about thread lifetime, COM references, or grouping changes are plausible and consistent with the evidence, but definitive root‑cause confirmation requires Microsoft engineering notes. Flag such claims as plausible rather than authoritative until the vendor publishes a post‑mortem.
Why this matters: operational and QA lessons
This incident highlights several enduring lessons for update management and QA:
- Preview/staged updates surface environment‑specific regressions before broad distribution — that is their purpose, but it requires disciplined staging and pilot rings in enterprise environments.
- Core tooling lifecycle paths (open → close → reopen) are heavily exercised by users; they must be included in automated regression suites because small changes in grouping or teardown logic can cause outsized user impact.
- Clear vendor communication reduces helpdesk load. When a vendor acknowledges a regression and publishes mitigation steps and a timeline for a fix, admins can act defensibly rather than improvising risky workarounds.
- Collect reproducible artifacts. ProcMon traces, ETW captures, Process Explorer stacks and winver screenshots accelerate vendor triage and shorten mean time to fix.
Final assessment and recommendations
- Short term: If you’re affected, run taskkill.exe /im taskmgr.exe /f or use Task Manager → End task, avoid closing Task Manager with the Close (X), and reboot when convenient to clear orphans. These mitigations are safe and effective.
- Medium term: Do not install optional preview updates like KB5067036 on production machines unless you accept the preview risk. Instead, validate previews in a controlled pilot ring.
- Long term: Treat the incident as a test case for update governance. Include lifecycle tests for core utilities in acceptance suites, require pilot rings for previews, and maintain a clear rollback and diagnostic plan to minimize user impact when regressions appear.
Microsoft’s remediation in the November cumulative update addressed the immediate problem for affected builds, but the episode remains instructive: even tightly scoped changes to process grouping or UI behavior can cascade into lifecycle regressions for fundamental system tools. The practical mitigations are simple, the vendor response was timely, and the overall risk is controllable for most users who follow standard update best practices.
Conclusion: the Windows 11 Task Manager duplication bug tied to KB5067036 was a reproducible lifecycle regression that could quietly accumulate orphaned taskmgr.exe processes. The fastest remedies are to force‑kill taskmgr.exe or use End task, avoid closing the app with the Close (X) until patched, and apply vendor updates once Microsoft publishes the confirmed fix. Administrators should keep preview updates confined to pilot rings, collect diagnostics for affected endpoints, and follow Microsoft’s guidance for removal or remediation when necessary.
Source: Guiding Tech
Windows 11 Task Manager Shows Duplicates