Windows 11 KB5067036 Preview: Administrator Protection and Color Battery Icons

Microsoft has begun rolling out a long‑anticipated redesign of the Windows 11 Start menu, delivered as an optional, non‑security preview update (KB5067036) that introduces a single, scrollable Start surface, multiple “All apps” layout modes, deeper Phone Link integration, and more granular personalization controls aimed at restoring discoverability and user choice to the OS.

Background​

Since Windows 11’s launch, the Start menu has been one of the most contentious parts of the user interface: Microsoft favored a centered, minimalist approach that many users found elegant but constrained, especially for dense app collections and power workflows. The new release responds directly to that feedback by reworking Start from a two‑pane interaction model into a unified, vertically scrollable canvas with view options that prioritize discoverability and customization.
Microsoft packaged the change as part of the Release Preview / optional preview servicing update labeled KB5067036, which increments builds for Windows 11 version 24H2 and 25H2 (notably builds 26100.7019 and 26200.7019 in the public preview). The update is distributed as an optional preview so that Microsoft can continue staged enablement and server‑side feature gating while collecting telemetry and user feedback.

---

What changed: feature snapshot​

The redesign focuses squarely on making the Start menu more discoverable, customizable, and better integrated across devices. The headline changes include:

• Single, scrollable Start surface — Pinned apps, Recommended items, and the All apps listing now sit on one continuous vertical canvas, eliminating the separate All‑apps page and reducing clicks.
• Three All apps views — Users can choose between:
• Category view, which groups apps into functional buckets (Productivity, Games, Creativity, Communication, etc.)
• Grid view, a denser alphabetical grid with larger icons for visual scanning
• List view, the classic alphabetical list many users still prefer
  The Start menu remembers the last view you selected.
• Customizable sections — Toggle off or hide the Recommended files/apps area, collapse or expand the pinned grid, and control layout density via Settings > Personalization > Start.
• Phone Link integration — A mobile device button next to Search opens a collapsible Phone Link panel inside Start, surfacing recent notifications, messages, missed calls, and quick phone controls for paired Android and (in selected markets) iOS devices.
• Responsive layout — The Start canvas adapts to display size; larger screens show more columns of pinned apps and categories by default.

These are not cosmetic tweaks alone — the update shifts how users navigate and discover installed applications on Windows 11.

---

How Microsoft is delivering the redesign​

Microsoft’s deployment model for this update follows the same conservative, telemetry‑driven pattern that’s become common for recent Windows feature work:

• The change appears in Insider channels and Release Preview as binaries become stable in servicing branches.
• Microsoft publishes KB5067036 as an optional, non‑security preview update for devices on 24H2 and 25H2; installing the preview package does not guarantee immediate activation of the redesigned Start because features are enabled progressively using server‑side feature flags (staged rollout / A/B testing).
• Wider deployment is expected to be folded into the normal Patch Tuesday cadence once the preview passes telemetry and feedback gates.

Practical takeaway: you may install KB5067036 and not see the redesigned Start immediately; conversely, some devices may get the new Start via Microsoft’s server‑side enablement before others even with the same build number.

---

Why this matters (strengths)​

The redesign addresses several concrete user complaints and adds features that matter in daily use:

• Faster app discovery — Consolidating Pinned, Recommended, and All apps into one surface reduces clicks and cognitive switching. For users with long app lists, the scrollable surface and Grid/Category views make scanning faster than navigating separate panels.
• Better use of modern displays — The Start canvas scales to larger screens, showing more content and therefore reducing the need to hunt across cramped lists. This improves workflows for large external monitors and multi‑monitor setups.
• More personalization — The ability to hide Recommended items, persist the chosen All apps view, and collapse pinned groups gives users real choices about density and emphasis. That’s a win for people who have asked for Windows to “get out of the way” and let them prioritize their own apps.
• Tighter cross‑device continuity — Bringing Phone Link into Start lowers friction for quick phone interactions while working on a PC, reducing context switching and keeping essential communications visible alongside app launch controls.

These strengths together make the redesign especially beneficial for users who juggle many applications, those who work across phone and PC, and environments where faster, at‑a‑glance access to tools restores productivity.

---

Risks, limitations, and unanswered questions​

No redesign is without tradeoffs. The rollout and architecture of this change introduce several points that IT pros and power users should weigh carefully.

1. Inconsistent user experience during staged rollout​

Because Microsoft uses server‑side gating, different machines — even in the same office or the same Microsoft account — can display different Start behaviors at the same time. That inconsistency complicates documentation, support scripts, and training materials for help desks and enterprise IT. Organizations should expect a transitional period with mixed experiences.

2. Limited manual control over Category grouping​

Category view groups apps automatically; current previews indicate Microsoft controls categories (generation is automatic and not user‑editable). That behavior risks misclassification and may frustrate power users and admins who need deterministic layouts for managed devices. There’s no sign yet of a manual reclassification UI or enterprise policy to pin categories explicitly.

3. Privacy and surface‑area concerns with Phone Link in Start​

Exposing phone notifications, messages, and other mobile content inside Start increases the feature’s convenience but also brings privacy considerations. On shared machines or in visible office setups, phone content surfaced in Start can reveal personal or sensitive information. Admins and users should verify pairing permissions, configure what the Phone Link pane displays, and consider whether to disable the feature for shared devices.

4. No guaranteed rollback to the old Start UX​

Microsoft’s documentation around KB5067036 focuses on feature toggles and personalization but does not offer a built‑in “revert to legacy Start” switch. Early reporting suggests there is no native one‑click rollback to the pre‑redesign Start once the update is applied, though users can hide or disable specific sections (for example, Recommended or Phone Link) through Settings. This makes pilot testing important before broad deployment. This point should be considered tentative — Microsoft has not publicly documented a global revert option in the preview notes and may adjust behavior based on feedback.

5. Power‑user and third‑party substitution dynamics​

Third‑party Start replacements such as Start11, StartAllBack, and Open‑Shell have served users unhappy with Windows 11’s default Start for years. The redesigned Start narrows the gap but may not satisfy users who need deterministic, scriptable layouts or who rely on advanced features those third‑party tools provide. Enterprises that standardize on a particular Start layout should test whether the new Start breaks or complements their chosen third‑party tooling.

---

Rollout, installation, and a quick how‑to​

For readers who want to try the redesigned Start now, here’s a practical checklist.

• Confirm your Windows 11 edition is running 24H2 or 25H2 (the preview targets both servicing branches).
• Enable “Get the latest updates as soon as they’re available” in Settings > Windows Update to be eligible for preview distribution, or join the Release Preview/Windows Insider channel if appropriate for testing.
• Check Windows Update: the package appears as Preview update (KB5067036) with the new build number (e.g., Build 26200.7019). Select Download & install or use the Microsoft Update Catalog to fetch the standalone .msu package if you prefer manual installation.
• Restart after installation. If the redesigned Start does not appear immediately, remember that Microsoft often enables new features server‑side; you may need to wait for the roll‑out to reach your device.

For administrators planning a staged pilot:

• Create a pilot update ring and restrict KB5067036 to a small set of test machines.
• Document expected changes and prepare quick support scripts that show users how to hide Recommended content and disable Phone Link if needed.
• Monitor Telemetry and user feedback, and prepare a broader rollout plan for Patch Tuesday once Microsoft declares the preview stable.

---

Enterprise and IT management considerations​

Enterprises should treat KB5067036 like any other optional feature preview: test, measure, and control. Specific recommendations include:

• Pilot first — Deploy the update to a controlled set of users across different roles (knowledge workers, developers, heavy app users) and collect UX/compatibility feedback before wider deployment.
• Update rings and feature policies — Use Windows Update for Business and MDM policies to stagger deployments and maintain control over which devices are eligible for optional preview updates. Documented deployment best practices remain the right approach here.
• Privacy settings — For machines in public spaces or shared environments, consider disabling Phone Link integration or controlling which users can pair phones to their devices. Audit paired devices and review consent settings.
• Support documentation — Prepare guidance for help desks on toggling Recommended items, switching All apps views, and addressing complaints about mismatched category groupings or missing icons.

These practical controls give IT teams leverage to balance user choice with organizational compliance and supportability.

---

UX critique: design, discoverability, and the AI angle​

The Start menu overhaul signals an important product design pivot for Microsoft: prioritizing discovery and context over the rigid minimalism of early Windows 11. The addition of Category view — which uses heuristics to group apps — is a notable move toward AI‑assisted organization; however, it raises two concerns.
First, accuracy and predictability: auto‑grouping is useful for typical consumer app sets but may produce surprising results with smaller or specialized app catalogs (internal LOB apps, legacy tools). Administrators and users who rely on deterministic layouts may find this frustrating. Evidence from early previews shows categories are generated automatically and currently lack manual editing.
Second, explainability: when the OS groups apps, users should be able to understand why a grouping occurred and how to correct it. Without a clear edit path, trust in the feature diminishes. For enterprise use, Microsoft will need to provide management controls or ways to pin and persist groupings to gain broader acceptance. The product signals are promising, but the delivery must include control surfaces to satisfy power users and admins.

---

Practical tips for power users​

• If you prefer a dense, deterministic app list, switch to List view and hide the Recommended area to replicate a classic Start experience while still retaining improved discovery for one‑off lookups.
• For faster keyboard navigation, test whether the new Start preserves search hotkeys and arrow navigation in your environment; if you rely on third‑party launchers, validate compatibility before committing.
• If Phone Link surfaces content you don’t want visible on a shared PC, toggle it off in Settings > Personalization > Start or disable Phone Link pairing for that device session.

---

What the redesign means for Microsoft’s broader strategy​

The Start redesign is consistent with Microsoft’s evolving platform strategy: make Windows the hub for device‑centric productivity, tighter integration across mobile/PC/cloud, and a richer surface for Copilot and other AI features. Bringing Phone Link into Start and adding category/grouping semantics are both steps toward a more contextual desktop that anticipates user needs.
At the same time, Microsoft’s staged rollout model and the continued use of optional preview updates underline a cautious approach — the company wants to collect behavioral telemetry and iterate based on real user data before committing changes broadly. That pragmatic, data‑driven posture reduces the risk of mass regressions but increases short‑term variability for users.

---

Caveats and unverifiable claims​

Some narrative threads circulating in commentary and coverage — for example, claims about irrevocable UI changes, or sweeping shifts in Microsoft’s partnership structures with OpenAI tied directly to this UI work — are not substantiated by Microsoft’s technical release notes or the official KB documentation. Where reporting speculates about corporate strategy or downstream AI governance, those claims should be treated as unverified until Microsoft publishes explicit announcements or documentation. Any such assertions in public commentary require careful cross‑checking against official Microsoft communications.

---

Final assessment and recommendation​

The Windows 11 Start menu redesign in KB5067036 is a pragmatic, user‑driven revision that meaningfully improves app discovery, adds sensible personalization options, and moves Start toward closer device integration. For most users the changes will be positive: faster discovery, better use of screen real estate, and a more flexible launcher model.
However, the staged rollout model, automatic category grouping, and Phone Link surface area raise practical concerns around consistency, control, and privacy — especially in managed or shared environments. Organizations and power users should pilot the preview, prepare support guidance, and verify compatibility with existing tooling and workflows before broad adoption.
For individual users who crave immediate benefit without corporate constraints, enabling the preview and toggling to your preferred view will likely yield an immediate productivity win. For IT admins, a cautious, measured pilot remains the best path forward.

---

Microsoft’s Start redesign is more than a visual refresh: it represents a philosophical reset that acknowledges user feedback and embraces practicality over strict minimalism. The approach is not without tradeoffs, but it restores choice and discoverability to the Start experience — the very aspects many Windows users have been asking for since 2021.

---

Source: TechRepublic Windows 11 Update Brings Customizable Start Menu and Streamlined App Discovery

Windows 11 users installing the optional October preview update (KB5067036) have reported a baffling Task Manager bug that leaves the app running after it’s closed, spawning duplicate taskmgr.exe processes that can quietly eat memory and CPU and make a PC feel sluggish.

Background / Overview​

KB5067036 is an optional, non‑security preview cumulative update published for Windows 11 in late October 2025 that ships fixes and a handful of visible feature updates — notably a redesigned Start menu experience and updated battery indicators — and several under‑the‑hood corrections. Because this is a preview (optional) release, Microsoft delivers it as a staged rollout: some features are enabled server‑side and not every device will see visual changes immediately. That rollout model also means the package gets wider testing in the field before more complete distribution via regular cumulative updates.
Community reports surfaced within days of the package’s release describing two sets of stability problems: (1) some devices failing to install the update cleanly or presenting update error codes, and (2) an odd Task Manager regression where closing Task Manager with the window “X” does not actually terminate the process. The latter is the focus here because it’s both reproducible and capable of producing measurable system slowdowns if left unchecked.

---

What users are seeing: the Task Manager duplication bug​

Symptom summary​

• Open Task Manager (Ctrl+Shift+Esc), then click the window “X” to close it.
• Reopen Task Manager and inspect Processes → Background processes.
• Instead of a single Task Manager entry, additional Task Manager entries appear; the count increases each time Task Manager is opened and closed using the window close control.
• Each “stuck” taskmgr.exe instance remains resident in memory and continues polling system telemetry, so multiple copies accumulate resource usage over time.
• Systems with multiple accumulated Task Manager instances can show visible slowdowns, stuttering UI, longer app launch times, or higher idle CPU and RAM usage.

How bad can it get?​

Community testers reported that each zombie Task Manager instance typically consumes a modest amount of RAM (reports commonly cite ~20–30 MB per instance), but that adds up quickly if users repeatedly open and close the app. One tester demonstrated tens to hundreds of instances, which translated into multiple gigabytes of RAM used and noticeable system sluggishness. The performance impact depends on how many duplicates accumulate and the baseline resources of the PC: machines with limited RAM or heavy background workloads will be affected more quickly.
These observations come from broad community reporting and hands‑on tests performed by power‑user sites and user forums during the rollout window. The behavior is reproducible on affected builds by simply opening and closing Task Manager repeatedly and watching taskmgr.exe appear under Background processes.

---

Why this probably happened (technical context and hypothesis)​

Microsoft’s official notes for the preview update indicate they made changes to Task Manager behavior in this release — specifically a fix intended to correct scenarios where apps weren’t being grouped correctly with their processes. That wording confirms the update modifies Task Manager internals.
The most likely explanation is that an internal change intended to improve process grouping or UI‑level grouping logic inadvertently broke the clean shutdown path for Task Manager windows in at least some runtime configurations. When an app fails to perform its normal shutdown housekeeping — unregistering callbacks, stopping timers, or releasing internal references — the process can stay resident even though the visible window has closed. Opening the app again starts a fresh process, and the old one remains, so successive opens/close cycles multiply the number of resident taskmgr.exe processes.
That theory aligns with what community testers observed: the duplication began after the update that included a Task Manager change, and the duplicate processes are listed as background processes (not foreground windows), which suggests the GUI is torn down while process threads remain.
It’s important to stress this is a plausible technical explanation based on public release notes and community testing; Microsoft has not publicly released a detailed post‑mortem for this specific symptom as of October 30, 2025. Treat the cause as likely but not formally confirmed until Microsoft publishes a fix note.

---

Other update issues reported alongside the Task Manager problem​

While the Task Manager symptom is the most visible, community reports during KB5067036’s early rollout also documented:

• Update installation failures on some systems, sometimes stopping at 100% and then rolling back or throwing error codes. Users reported various error codes in community threads.
• A limited number of scattered reports describing severely degraded systems after the update (some users described needing to uninstall the update or use recovery options to restore normal operation). These reports appear to be outliers but underscore the risks of installing optional preview packages on production machines.
• Feature rollout inconsistency: because certain UI changes are staged server‑side, installing KB5067036 does not guarantee immediate appearance of the new Start menu or other visible features.

These are primarily community and forum reports collected during the preview rollout window. They do not represent universal behavior, and many users installed the preview without incident. Nevertheless, the mixed experiences argue for caution before installing preview updates on mission‑critical systems.

---

How to verify whether your machine is affected​

• Open Task Manager (Ctrl+Shift+Esc) and close it using the window “X.”
• Reopen Task Manager and expand the Processes list.
• Look under “Apps” and “Background processes” for multiple entries labeled Task Manager.
• Alternatively, run a quick command in PowerShell or Command Prompt:
• PowerShell:
  Get-Process -Name taskmgr
• Command Prompt:
  tasklist /FI "IMAGENAME eq taskmgr.exe"

If these commands return more than one taskmgr.exe entry after you’ve closed and reopened the UI a few times, your device is affected.

---

Immediate fixes and workarounds​

If your PC is showing duplicate Task Manager processes and you notice degraded performance, there are several practical ways to clear the stuck instances and avoid further impact.

Fast kill (single command)​

Open an elevated Command Prompt or a normal Command Prompt and run:
taskkill /im taskmgr.exe /f
This forcibly terminates all running Task Manager processes in one step. It’s the quickest remedy if multiple zombie instances exist.

PowerShell alternative​

Open PowerShell and run:
Get-Process -Name taskmgr | Stop-Process -Force
This accomplishes the same result for PowerShell‑centric users.

Manual end‑task​

If you prefer the GUI:

• Open Task Manager (Ctrl+Shift+Esc).
• In the Processes tab, locate each Task Manager entry under Background processes.
• Select it and choose End task for each instance.

That’s tedious for large counts, but works.

Workarounds to avoid creating duplicates​

The issue centers on using the window “X” to close Task Manager. Community testers found that instead of clicking the “X,” you can avoid the duplication by:

• Ending the Task Manager process from within Task Manager (select the process and click End task), or
• Using the keyboard shortcut to close windows (Alt+F4) — anecdotal testing suggests behavior may differ across systems; if Alt+F4 triggers a proper shutdown on your device, it’s a safer close method until an official fix arrives.

If performance has already degraded​

• Run taskkill once to clear the instances.
• Restart the PC to ensure no lingering background activity remains.
• If performance problems persist after killing the processes and rebooting, consider uninstalling the preview update (steps below) or restoring from a system restore point.

---

How to uninstall KB5067036 (roll back the preview)​

If you installed KB5067036 and prefer to revert until the issue is resolved, use the built‑in Windows update rollback tools. Note that not all packages are uninstallable (some servicing stack or mandatory packages are non‑removable); preview quality updates are generally removable, but follow these steps carefully and make sure you have recent backups.

• Open Settings (Windows + I) → Windows Update → Update history.
• Scroll to Related settings and select Uninstall updates.
• In the Control Panel dialog that opens, find the most recent Microsoft Windows update that matches the KB number and choose Uninstall.
• Follow prompts and reboot when the system requests.

If Windows will not boot normally, use the Advanced Startup Environment:

• On the sign‑in screen, hold Shift and select Restart (or use a recovery drive / installation media).
• Choose Troubleshoot → Advanced options → Uninstall Updates.
• Attempt to uninstall the latest quality update or the latest feature update as appropriate.

If the uninstall option is not present or the update is non‑removable, recovery options include using System Restore (if a restore point exists) or performing a repair install with in‑place upgrade media — but those are heavier actions and should be considered last resorts for production systems.

---

Prevention: best practices for updates (especially preview/optional releases)​

• Avoid installing preview/optional updates on production or mission‑critical systems. Preview updates are precisely that — pre‑release testing material. They can fix issues but can also introduce regressions.
• Use restore points or image backups before installing any optional updates so you can roll back quickly.
• Delay feature/preview updates on managed fleets via Windows Update for Business, WSUS, or SCCM until a wider validation window closes.
• If you have a “Get the latest updates as soon as they’re available” toggle enabled, consider disabling it if you want to avoid being offered preview releases unexpectedly.
• Monitor official Windows Release Health pages and patch notes before installing optional updates. When in doubt, wait for the next cumulative release through Patch Tuesday, which typically incorporates fixes discovered during the preview period.

---

Enterprise considerations and mitigation​

• For IT managers, the presence of a bug that can cause background processes to multiply and drain resources — even modestly — is a legitimate operational risk when it spreads across many endpoints.
• Recommended actions for enterprises:
• Block or defer installing optional preview updates across the fleet until vendor guidance confirms the issue is resolved.
• Use group policies or Windows Update for Business rings to keep at‑risk systems on a more conservative cadence.
• If a small test group has already installed the preview and experiences the Task Manager duplication, enforce a remediation script (taskkill or PowerShell stop) via existing management tooling to clear instances automatically.
• Headline monitoring: add a quick health check or script to detect multiple taskmgr.exe instances and report back to central management so remediation can be automated if necessary.

---

Risk analysis: strengths and threats exposed by this incident​

Strengths (what the update fixes or improves)​

• KB5067036 bundles legitimate fixes that matter: a corrected Media Creation Tool behavior for some Arm64 devices and several quality and UI tweaks.
• The staged rollout model lets Microsoft validate features on a broader set of real‑world configurations beyond Insider channels.
• Community reporting and rapid sharing on forums mean regressions get noticed quickly, which shortens the window between regression and fix when Microsoft engages.

Risks and weaknesses​

• Preview updates shipped to broad user bases can expose production machines to regressions. The Task Manager bug is an example where a targeted internal fix introduced an unforeseen regression in a core system tool.
• End users are serving as de‑facto QA when preview updates are optional but widely available, and that increases the odds of encountering edge‑case failures.
• Staged feature rollouts plus preview packages make troubleshooting more complex — applying the same KB to two computers may produce different behavior depending on feature‑flight flags and device configuration.
• Fragmented reporting (different error codes, scattered bricked reports) complicates triage. Community reports of installation failures and, in rare cases, devices needing recovery highlight the potential for serious impact even with a non‑security preview update.

---

What Microsoft has (and hasn’t) said — transparency status​

Microsoft’s published preview notes for KB5067036 document several fixes and feature changes related to Task Manager, updates, and Media Creation Tool behavior. However, as of October 30, 2025, Microsoft had not issued a formal, public acknowledgement specifically describing the Task Manager duplication symptom or a targeted hotfix for it. Community reporting picked up the issue quickly, and power‑user sites and forums circulated kill‑commands and rollback guidance while Microsoft investigates.
When Microsoft does publish an updated release note or a corrective package, it will typically appear in the Windows Release Health dashboard or in an updated support article for the KB. In the meantime, users and administrators should treat community guidance as actionable mitigation — but also keep a close watch on official channels for a supported fix.

---

Practical checklist: quick actions for affected users​

• Confirm symptom: open/close Task Manager and watch for multiple taskmgr.exe entries.
• Clear duplicates: run taskkill /im taskmgr.exe /f or PowerShell Stop-Process as above.
• Reboot to stabilize the system.
• If you installed KB5067036 and prefer not to risk further regressions, uninstall the preview update via Settings → Windows Update → Update history → Uninstall updates.
• If you run critical systems, roll back any affected machines, and pause pushing optional updates to the rest of the fleet.
• Keep a current image backup and create a restore point before applying future optional updates.
• Monitor Microsoft Release Health and apply the next cumulative update once Microsoft confirms the bug fix.

---

Conclusion — measured caution is the right approach​

Preview and optional cumulative updates are useful testing grounds for new features and fixes, but they are exactly that: pre‑release work that can behave differently across hardware, drivers, and third‑party software. The reported Task Manager duplication in KB5067036 is an uncomfortable reminder that even a minor change in how a core tool manages processes can cascade into real user pain when it prevents proper shutdown of background processes.
For everyday users and IT teams the prudent course is clear: avoid optional preview updates on production machines, back up before applying optional updates, and apply simple mitigations (taskkill, uninstall) if you find yourself affected. For Microsoft, the path is also straightforward — investigate, patch, and communicate. The community discussion has already provided reproducible steps and diagnostics; now it’s time for a supported fix and an official confirmation to close the loop.
Until then, use the quick commandline fixes to reclaim resources, uninstall the preview if you prefer stability, and treat optional updates with caution.

---

Source: TechRadar https://www.techradar.com/computing...-could-slow-down-your-pc-heres-how-to-fix-it/

Microsoft has begun rolling out a substantial refresh of the Windows 11 Start menu as part of the optional October 28, 2025 preview update (KB5067036), introducing a single, vertically scrollable Start surface, multiple "All apps" view modes, tighter Phone Link integration, and a handful of taskbar and File Explorer refinements that together aim to restore discoverability and customization to the launcher while remaining gated behind Microsoft’s staged rollout model.

Background / Overview​

Since Windows 11’s debut, the Start menu has been a recurring point of user feedback: praised for a cleaner aesthetic but criticized for reduced discoverability and the extra step required to reach a full alphabetical app list. KB5067036 represents the most visible Start rework since Windows 11’s launch, packaging the redesigned Start surface into a non‑security preview update for Windows 11 versions 24H2 and 25H2. Microsoft shipped the preview bits on October 28, 2025 as OS builds 26100.7019 and 26200.7019 and is enabling the experience progressively via server‑side feature flags and phased rollout.
The update is being delivered as an optional preview for devices that have opted into receiving early feature releases; a broader rollout is expected to follow the usual Patch Tuesday cadence after telemetry and compatibility checks. That delivery model — shipping binaries but controlling activation — is central to how administrators and enthusiasts should approach KB5067036.

---

What’s new in KB5067036​

Single, scrollable Start surface (All apps on the main page)​

The most striking change is structural: Start is now a single, vertically scrollable canvas where the full installed-apps inventory sits on the main page instead of behind a separate “All apps” view. This reduces clicks, shortens the path to launch apps, and aligns the desktop launcher with the single-surface app drawers users see on mobile launchers. The Start canvas still surfaces pinned apps and (optionally) recommended files, but those sections now live on the same scrollable surface alongside All apps.
Key points:

• The scrollable All section places the entire app list at prime real estate.
• Pinned apps and Recommended content remain available but can be shown or hidden.

Multiple app-list views: Category, Grid, and List​

You can now choose how All apps is presented:

• Category view — auto-groups apps into functional buckets (Productivity, Games, Creativity, Communication, etc.) and surfaces frequently used apps within those buckets.
• Grid view — a denser, alphabetical grid optimized for horizontal scanning and visual scanning on wider screens.
• List view — a compact A–Z list preserved for keyboard-driven power users.

The Start menu remembers the last view you selected, so your preferred presentation persists across sessions. These modes are meant to offer flexibility: discoverability by intent (Category), fast visual scanning (Grid), or deterministic ordering (List).

Phone Link panel inside Start​

A new mobile device button appears next to Start’s search area. Clicking it expands a collapsible Phone Link panel embedded in Start so you can view notifications, recent messages, calls, and photos from a paired Android or iPhone without opening a separate app. The on‑Start Phone Link panel is designed to make the phone feel like a natural extension of the PC and reduce context switching for common phone workflows. Availability depends on device pairing and region.

Taskbar and battery UI refinements​

KB5067036 also introduces several subtle but useful taskbar refinements:

• Thumbnail animations for taskbar previews that make window switching feel smoother.
• Color-coded battery icons (green = charging/healthy, yellow = battery saver at ≤20%, red = critical) and an option to permanently display battery percentage in the system tray and on the lock screen.

These micro-interactions and visual cues are small individually, but they add up to a more polished and informative system tray experience, particularly for laptop users.

File Explorer, Copilot and accessibility updates​

Beyond Start, the preview bundles a set of File Explorer and Copilot-related improvements:

• File Explorer Home gains a Recommended files surface (toggleable for personal and local accounts) and hover quick-actions like “Open file location” and “Ask Copilot.”
• Copilot/Click to Do enhancements, including a typed prompt box and local prompt suggestions (on Copilot+ hardware) powered by on‑device models.
• Fluid Dictation for Voice Access — on‑device small language models that improve grammar and punctuation in real time on supported Copilot+ PCs.

Some of these features are hardware- or region-gated and will be available only on qualifying Copilot+ devices or after specific rollouts.

---

Deployment, availability, and how Microsoft is rolling this out​

• Microsoft distributed KB5067036 as an optional, non‑security preview on October 28, 2025; the official KB notes list builds 26100.7019 (24H2) and 26200.7019 (25H2).
• The update uses a mixed delivery model: binaries are delivered through the update, but feature exposure is staged via server‑side gating (A/B testing). That means installing the KB may be necessary but not always sufficient to immediately see the redesigned Start.
• Early visibility is limited to devices that opted into receiving the latest features (the “Get the latest updates as soon as they’re available” toggle or Release Preview ring). A wider rollout is expected to follow after Microsoft observes telemetry and addresses regressions.

How to check whether the update is present:

• Press Windows+R, type winver, and confirm your build number is at or above the preview builds (for example, 26100.7019 / 26200.7019). Presence of the build indicates the bits are installed, but not necessarily that the feature flag is enabled.

How to get the redesign sooner (official path):

• Install the optional preview via Settings → Windows Update → Check for updates → Optional updates, or download the package from the Microsoft Update Catalog. Do not use third‑party feature‑flag tools in managed or production environments — they are unsupported.

---

Strengths — why this matters​

• Reduced friction for app discovery. By moving All apps to the main surface and adding a scrollable canvas, Microsoft removes an extra navigation step that hindered fast workflows, particularly for users with many installed programs. Early hands‑on reporting and Microsoft’s notes highlight that this reduces clicks and can speed common launch tasks.
• Flexible personalization. Multiple views and explicit toggles to hide the Recommended area give users real choices. Power users can restore a compact alphabetical list, while casual users can benefit from Category grouping and the visual clarity of Grid view.
• Cross-device continuity. Embedding Phone Link in Start reduces context switches between PC and phone, making messages and notifications easier to act on while working on a PC. This is useful for remote workers and mobile-first users.
• Polish and small wins. The battery percentage toggle, color-coded battery icons, and thumbnail animation tweaks are examples of high-quality UI refinement that improve day-to-day ergonomics for mobile users.
• Platform hooks for the future. StorageProvider APIs and Copilot integration points show Microsoft is broadening the shell’s surface for third‑party integrations and contextual AI actions — potentially enabling deeper productivity scenarios.

---

Risks, caveats, and things to watch​

• Staged rollout means inconsistent visibility. Installing KB5067036 does not guarantee the redesigned Start will appear, because Microsoft flips server‑side flags gradually. That leads to inconsistent experiences across identical machines and can confuse pilot tests if feature exposure isn’t tracked carefully.
• Preview update = preview risk. KB5067036 is an optional, non‑security preview. Historically, preview packages may still contain regressions or interact unpredictably with certain hardware/driver combinations. Administrators should treat this update as a pilot candidate rather than a broad deployment target.
• Active bug reports. Community reports surfaced a Task Manager duplication/closure bug after installing the KB, and other October updates around this timeframe created issues such as WinRE input problems in a separate release. Those reports underline the need to test the full update and not just the Start redesign. Microsoft sometimes issues follow-up fixes in subsequent preview or cumulative updates.
• Hardware and regional gating for Copilot features. Several Copilot/Copilot+ experiences (including local SLM-powered features) are gated to specific hardware classes and regions, and some features are not available in the European Economic Area or China in early phases. Organizations must validate licensing and hardware entitlements before depending on those workflows.
• Privacy and telemetry considerations. The Category grouping logic is automatic and tuned on-device, but the presence of recommended files and Copilot suggestions means administrators and privacy officers should re-evaluate telemetry settings and data handling, especially in regulated environments. Some recommendation surfaces can be toggled off, but policy controls and MDM settings should be audited to ensure compliance.
• Unsupported community workarounds. Enthusiasts may be tempted to force-enable features via unofficial tools; these approaches are unsupported and risk stability and future update compatibility. Enterprises should avoid such methods.

---

Enterprise and IT guidance (practical steps)​

• Treat KB5067036 as a preview pilot.
• Enroll a representative pilot group — including devices with varied hardware profiles and common business apps — and install KB5067036 via Release Preview or Windows Update optional updates.
• Track feature exposure: verify both the OS build (winver) and whether the Start redesign is enabled on each device.
• Verify critical workflows.
• Test sign-in flows, remote management tools, WinRE-based recovery, imaging/tiered provisioning, and business-critical applications — especially anything that hooks into the shell or uses custom shell extensions.
• Check MDM/GPO and Intune settings.
• Confirm whether the new Recommended surfaces or Copilot integrations are compatible with existing privacy/telemetry policies.
• If Administrator Protection preview is relevant, control it through Intune OMA-URI or Group Policy as Microsoft documents.
• Rollout plan.
• Stage the update: pilot → targeted deployment → broad deployment aligned to a cumulative (non-preview) release once Microsoft signals GA for the features you rely on.
• Maintain a rollback or remediation plan: record restore points or recovery media in case a preview triggers regressions on production hardware.
• End-user comms and training.
• Inform users about the new Start views and how to switch between them (Settings → Personalization → Start), and provide guidance on hiding Recommended content if they prefer a minimalist view.

---

Recommendations for home users and enthusiasts​

• If you enjoy early features and can accept preview-level instability: install KB5067036 via Optional updates and wait for Microsoft to flip the feature flag. Use the in-Start toggles to tailor views and hide Recommended files if desired.
• If you prefer stability: skip the optional preview and wait for the redesign to arrive through the normal cumulative update channel after it reaches wider rollout.
• Avoid unsupported tweaks (ViVeTool or similar) on machines where stability matters — these can break future updates and are not recommended by Microsoft.
• If you encounter issues after installing the preview, check Microsoft’s release notes and the Windows release health dashboard for known issues and remediation guidance.

---

Verification of key technical claims (what has been confirmed)​

• Microsoft’s official KB notes for the October 28, 2025 preview (KB5067036) list the redesigned Start menu, scrollable All section, Category and Grid views, Phone Link integration, and the taskbar battery improvements under the OS builds 26100.7019 and 26200.7019. This is the authoritative confirmation of the feature set and the build identifiers.
• Independent coverage by national tech outlets and hands‑on reports confirms the same functional changes: the single-scroll Start surface, multiple views, and responsive layout behavior have been tested and observed by reviewers. These independent accounts corroborate Microsoft’s published notes and provide early user perspectives.
• Community and third‑party reports have already surfaced a few post-installation issues (for example, Task Manager duplication) and other October update-related regressions. These community-flagged problems warrant caution for wide deployments and reinforce the need for testing. Treat these reports as real‑world signals that Microsoft typically addresses in follow-up releases.

Where public documentation is deliberately opaque — for example, exact Copilot+ hardware SKU lists or precise EEA timing for every feature — clause language in Microsoft’s KB notes warns that feature availability depends on device and market. Those items should be validated directly with Microsoft support or through the organization’s Microsoft account manager if precise entitlement and timing details are required.

---

Final analysis — balancing design, control, and rollout mechanics​

KB5067036 is a pragmatic pivot by Microsoft: the Start menu redesign addresses one of Windows 11’s most persistent usability complaints without discarding the OS’s modern visual language. The move to a single scrollable canvas plus multiple presentation modes is sensible and aligns Windows more closely with modern launcher paradigms while restoring choice for different workflows. The Phone Link panel and File Explorer/Copilot touches also reflect a consistent strategy: fold continuity and micro‑AI actions into the places where users already work.
However, the delivery method — shipping the code broadly but gating feature activation — produces an awkward middle state for pilots and admins. You can have the update installed and still not see the feature, which complicates verification and rollout metrics. Preview-level regressions and region/hardware gating for advanced Copilot features further complicate enterprise adoption.
Practically, for home users and IT teams alike, the sensible path is measured: pilot KB5067036, verify device-specific behavior and critical workflows, and then follow Microsoft’s staged signals to expand deployment when the preview evidence and cumulative updates indicate broad compatibility and stability. The redesign itself is a clear usability win; the rollout mechanics are the real operational challenge.

---

The Start menu refresh in KB5067036 is more than cosmetic — it’s a thoughtful rework of how apps and device continuity are surfaced on Windows 11. For people who value discoverability and prefer launcher flexibility, this preview is an encouraging step; for administrators and stability‑sensitive users, a cautious, well‑instrumented pilot remains the right approach.

---

Source: Techlusive Microsoft Refreshes Windows 11 Start Menu: Here’s What’s New In The KB5067036 Update

Microsoft has released a corrected Windows 11 Media Creation Tool after a late‑September regression caused the utility to close silently on many Windows 10 machines, restoring the official, single‑file path for creating bootable Windows 11 USB drives and ISOs and offering an official remediation path bundled with an optional preview cumulative update.

Background / Overview​

The Media Creation Tool (MCT) is Microsoft’s lightweight, single‑executable utility for downloading official Windows images and producing bootable installation media. It’s the go‑to option for home users, technicians, refurbishers and small IT teams that prefer a supported “one‑shot” workflow over manual ISO handling or enterprise imaging pipelines. In late September 2025 Microsoft shipped a new MCT binary commonly identified as version 26100.6584, and within days users began reporting a consistent failure: the tool would launch, prompt for UAC, show a brief Windows splash, and then exit with no error and no created media. Microsoft publicly acknowledged the regression and documented it as a known issue that primarily affected Windows 10, version 22H2 hosts.
The timing mattered. Windows 10’s routine support cutoff for Home and Pro editions was a fixed milestone that fell on October 14, 2025, driving a last‑minute surge of migrations, recovery‑media builds, and clean installs. The MCT regression removed the simplest Microsoft‑supported path for many of those users at a high‑pressure moment, forcing fallback to direct ISO downloads or third‑party utilities.

---

What happened: symptoms, scope and early diagnoses​

The visible symptom​

The reported failure mode was immediate and reproducible: double‑click the MCT executable on an affected Windows 10 machine, accept the UAC prompt, observe a split‑second Windows logo, and the process terminates with no error dialog or produced ISO/USB. Event‑log traces and community reproductions frequently showed early crashes referencing SetupHost.exe and low‑level modules, indicating the fault occurred in the tool’s bootstrap or initialization phase rather than during download or write operations.

Platforms and architectures impacted​

Microsoft’s advisory explicitly called out Windows 10 (22H2) hosts as impacted. Reports and community testing also highlighted brittle behavior on Arm64 devices, though Microsoft had previously documented that MCT’s Arm64 workflows were limited or unsupported for creating Arm64‑targeted media from Arm64 Windows 10 hosts — a nuance that added to confusion when Arm‑based users encountered failures. In practice, the problem manifested most widely on Windows 10 22H2 machines, with Arm64 scenarios appearing as a secondary pain point.

What Microsoft confirmed (and what remains unknown)​

Microsoft’s Release Health / Known Issues entry described the problem and identified the offending MCT build metadata as 26100.6584, released on September 29, 2025. The vendor advised affected users to download Windows 11 ISO images directly from the official Software Download page or to use the Windows 11 Installation Assistant until a corrected MCT version was published. Microsoft did not publish a detailed root‑cause post‑mortem or device‑impact telemetry, so the exact internal cause (for example, a compatibility shim, signing/certificate interaction, or a build artifact) has not been publicly verified. That lack of a technical after‑action report means any deep cause analysis is speculative until Microsoft publishes a formal explanation.

---

Timeline: discovery to remediation​

• September 29, 2025 — community reporting and binary identification of Media Creation Tool version 26100.6584 begins after Microsoft updated the tool for the Windows 11 refresh.
• Early October 2025 — users report the silent‑exit behavior on Windows 10 22H2 hosts; Microsoft posts a Release Health note acknowledging the regression and recommending ISO downloads as a workaround.
• October 28, 2025 — Microsoft publishes a refreshed MCT binary and releases an optional preview cumulative update KB5067036 that includes the MCT compatibility correction and a bundle of staged UI and Copilot/feature improvements. Microsoft indicates the issue has been addressed in the updated tool and the KB packaging.
• November Patch Tuesday (planned distribution) — Microsoft intends to fold the preview fixes into the regular cumulative update cadence so the MCT fix reaches mainstream servicing channels. The preview KB is optional and staged; broader rollout follows validation.

This sequence is corroborated by multiple independent community threads and specialist reporting, which reproduced the failure and tracked Microsoft’s advisory and the October 28 remediation packaging.

---

The fix: what Microsoft shipped and how to get it​

Microsoft resolved the symptom by updating the Media Creation Tool binary and packaging compatibility corrections into KB5067036, an optional non‑security preview cumulative update released on October 28, 2025. The KB’s notes list the MCT regression as fixed and also ship a set of staged UI and Copilot‑related improvements aimed at Windows 11 feature flights. Because KB5067036 is a preview, administrators and advanced users can install it from Settings > Windows Update under “Optional updates available,” or obtain the standalone MSU from the Microsoft Update Catalog for manual deployment. Microsoft indicated that the preview fixes will be rolled into the upcoming Patch Tuesday cumulative update for broader distribution.
Important practical notes about the fix:

• Installing the updated MCT executable from the official Microsoft Software Download page should immediately restore the normal media creation workflow on Windows 10 hosts.
• If administrators prefer not to install preview KBs, users can download the corrected MCT directly or continue to use the official ISO download route until the fix arrives via the regular cumulative update channel.
• The preview KB also contains several feature previews that are server‑side gated; installing the package does not guarantee immediate visibility of those features. The staged rollout reduces risk but increases variability in user experience.

---

Safe workarounds while the problem persisted​

When the MCT failed, Microsoft and the community converged on safe and tested alternatives that avoid unsupported or hazardous shortcuts.

• Download the official Windows 11 Disk Image (ISO) for x64 (or Arm64 where applicable) directly from Microsoft’s Software Download page and create bootable USB media using a trusted tool. Microsoft explicitly recommended this as the primary workaround.
• Use the Windows 11 Installation Assistant for an in‑place upgrade on eligible devices when preserving apps and settings is preferred.
• Run the Media Creation Tool from a functioning Windows 11 host to create installers for other machines — a practical cross‑host remediation for imaging teams with a validated x64 creation host.
• Use trusted third‑party USB tools such as Rufus or Ventoy to write a verified Microsoft ISO to a USB drive; these utilities are widely used by technicians and are pragmatic fallbacks. Verify ISO checksums after download.

These approaches keep users on canonical Microsoft media and avoid reliance on patched or unofficial ISOs and registry hacks that carry longer‑term security and compliance risks.

---

Step‑by‑step: create a bootable USB from the official ISO (safe, supported path)​

1. Download the official Windows 11 ISO from Microsoft’s Software Download portal (choose the correct architecture: x64 or Arm64).
2. Verify the ISO SHA‑256 checksum where available to confirm file integrity.
3. Use one of the following methods to create bootable media:
   1. Rufus (run as Administrator) — choose GPT/UEFI or MBR/BIOS depending on target device.
   2. Windows File Explorer + DiskPart — mount the ISO and copy files to a formatted USB (for UEFI/GPT targets ensure an NTFS/UEFI‑bootable layout or use Rufus for better automation).
   3. Ventoy — configure a persistent multi‑ISO USB and copy the ISO file to the Ventoy volume.
4. Boot the target device from USB to install or repair, and ensure Secure Boot/TPM settings match your deployment plan.

This sequence is the recommended fallback path when the MCT is unavailable or untrusted. Keep a validated x64 host for media creation if you regularly build images for diverse architectures.

---

Technical requirements and pre‑flight checks​

Before upgrading to Windows 11 or creating install media, validate these key requirements (the canonical Microsoft checklist):

• 64‑bit CPU (1 GHz dual‑core or better) on Microsoft’s approved list
• TPM 2.0 present and enabled (firmware or discrete)
• UEFI with Secure Boot enabled
• Minimum 4 GB RAM and 64 GB storage (practical installs typically require more)
• Confirm device eligibility with PC Health Check before attempting an in‑place upgrade

These system requirements remain the gating factors for a supported Windows 11 upgrade and should be verified prior to media creation to avoid wasted rebuilds or failed upgrades.

---

Risks, tradeoffs and best practices​

Risks introduced by the regression and Microsoft’s remediation model​

• The MCT regression exposed the fragility of a single‑file convenience tool at a time of high migration volume, increasing the risk that non‑technical users would adopt unsafe or unverified workarounds.
• Microsoft delivered the fix as part of a preview cumulative update that bundles a compatibility correction with feature previews. While this is operationally efficient, bundling fixes with feature flights can be disruptive for users who prefer critical bug fixes to be decoupled from UI experiments. Administrators should pilot preview KBs in controlled rings before wide deployment.

Best practices for administrators and home users​

• Maintain a canonical ISO repository and a validated x64 staging host for media creation to avoid relying solely on per‑device MCT runs.
• Verify ISO checksums and use trusted tools to write media; avoid modified ISOs or registry bypasses unless you fully understand the long‑term support and security implications.
• Back up critical data before attempting upgrades or clean installs. A robust backup is the first line of defense against failed upgrades.

---

Critical analysis: what this episode says about Microsoft’s servicing model​

This incident is instructive on multiple fronts. The Media Creation Tool is a micro‑utility used by millions; when a regression affects it, the operational blast radius is high because the tool is often the default fallback for users outside enterprise imaging pipelines. Microsoft’s modern servicing model — which mixes feature flights, staged rollouts and optional preview KBs — provides flexibility and safety for large feature drops, but it creates friction when a narrowly scoped compatibility fix is bundled with visible feature changes.
Positive aspects of Microsoft’s response:

• The company acknowledged the issue publicly and provided immediate, practical mitigations (ISO download, Installation Assistant, run MCT on Windows 11 host). That transparency reduced user confusion and offered safe fallbacks.
• The fix was delivered relatively quickly and distributed both as an updated tool and as part of a preview cumulative update, increasing the channels by which users could obtain remediation.

Concerns and potential risks:

• Bundling the compatibility fix within a preview KB that also contains feature previews introduces deployment complexity. Organizations that avoid preview releases to maintain stability may have to wait for the next Patch Tuesday to obtain the fix, slowing remediation.
• Microsoft has not released a detailed technical root‑cause analysis or impacted device counts. The absence of public telemetry and a formal post‑mortem means the community and enterprises must rely on anecdotal reproductions and vendor statements, complicating risk assessment and future mitigation planning. This lack of a public post‑mortem should be flagged to readers as an area of uncertainty.

Overall, the episode underscores a perennial tradeoff in modern software servicing: delivering fixes quickly versus controlling the complexity and visibility of simultaneous feature rollouts. For critical tools that serve broad, non‑technical audiences, there is an argument that urgent compatibility fixes should be distributed independently rather than bundled with feature previews.

---

What to do now — practical checklist​

• If you saw the MCT close unexpectedly on a Windows 10 device: download the updated Media Creation Tool from Microsoft’s Software Download page or download the official ISO and create media manually.
• If you manage multiple devices in production: pilot KB5067036 in a small ring, validate imaging and upgrade workflows, and stage the roll‑out based on telemetry. Do not deploy preview updates broadly without testing.
• Keep a validated x64 media‑creation host in your toolkit for cross‑architecture image creation.
• Always verify ISO integrity (SHA‑256), back up critical data, and confirm device eligibility with PC Health Check before upgrading.

---

Closing assessment​

Microsoft’s correction restores the official, supported path for creating Windows 11 installation media and reduces the operational friction introduced at an inopportune time — immediately ahead of Windows 10’s end‑of‑support milestone. The vendor’s public acknowledgement, practical workarounds and the October 28 update demonstrate an appropriate response cadence. However, the incident highlights two persistent tensions: the dangers of single‑file convenience tools breaking in the wild, and the complexities introduced when fixes are packaged alongside feature previews.
For most consumers, the updated Media Creation Tool or the direct ISO route will now resolve the issue. For administrators and imaging teams, the right course is conservative and methodical: validate the preview KB in a pilot ring, maintain a canonical ISO repository and staging host, and avoid ad hoc workarounds that compromise integrity or compliance. Finally, because Microsoft has not published a comprehensive root‑cause analysis or impacted device counts, treat any assertions about scale or precise cause as provisional until an official post‑mortem appears.

---

---

Source: Windows Report Microsoft Fixes Windows 11 Media Creation Tool Issue on Windows 10 PCs

Microsoft has begun rolling out the long‑promised, redesigned Start menu for Windows 11 as part of the October 2025 non‑security preview update (KB5067036), and the change is big: a single, scrollable Start surface that promotes the All apps experience to the front page and adds Category, Grid, and List views to make app discovery faster and more flexible.

Background / Overview​

The new Start redesign is delivered inside the KB5067036 preview package targeted at Windows 11 versions 24H2 and 25H2, with the servicing builds shown by Microsoft as 26100.7019 (24H2) and 26200.7019 (25H2). The update is an optional, non‑security preview released on October 28, 2025 that packages the updated Start UI along with other improvements to File Explorer, taskbar visuals, and Phone Link integration.
Microsoft is exposing the experience via a staged, server‑side rollout. That means installing the preview update is a necessary step, but it’s not always sufficient — Microsoft may still gate the feature on a per‑device basis and enable the new UI only for portions of the population to monitor stability and telemetry. For most users the supported path is to install KB5067036 (or join the Release Preview channel) and wait for Microsoft’s staged enablement to flip the feature on.

---

What changed: the Start menu, reimagined​

The Start menu redesign is a response to years of user feedback asking for a simpler, more discoverable app launcher. The key changes are practical and visible:

• A single, vertically scrollable Start surface: Pinned apps, the Recommended area, and All apps live on one continuous page so you no longer need to switch between separate panes to find things. This reduces clicks and improves discoverability for large app catalogs.
• Three All apps views: The Start menu now supports Category, Grid, and List views for the All apps area.
• Category view groups apps into buckets (system‑generated categories that highlight frequently used apps).
• Grid view presents apps as a more compact icon grid for quick scanning.
• List view shows a traditional alphabetized list.
  The menu remembers your last selected view, so your preference is preserved.
• Responsive layout: On larger screens the Start surface expands to show more pinned apps, more categories, and additional content. The layout adapts to DPI and screen width, which benefits laptop users and those on ultrawide or high‑DPI displays.
• New Phone Link integration and taskbar tweaks: A new mobile device button sits beside Search to expand Phone Link content in Start. Taskbar improvements shipped alongside the update include animated thumbnails and a battery icon that can show percentage.

These changes are aimed at making Start feel more like a contemporary launcher — fewer modal switches, more scrolling, and better scaling across devices.

---

How to get the new Start menu — supported (recommended) path​

If you want the official, supported route, follow these steps:

• Confirm your Windows 11 version and build:
• Press Windows + R, type winver, and press Enter.
• Verify you’re on 24H2 or 25H2 and on a build equal to or newer than 26100.7019 / 26200.7019 after the KB5067036 preview installs.
• Opt into preview delivery (optional but accelerates eligibility):
• Open Settings → Windows Update → Windows Insider Program → Get started → choose Release Preview.
• Back in Windows Update, enable Get the latest updates as soon as they’re available.
• Check for updates:
• Open Settings → Windows Update → Check for updates.
• Install the optional preview update labeled KB5067036 if it appears under Optional updates and restart when prompted.
• Wait for Microsoft’s server‑side enablement:
• Even after installing the preview, the UI may not appear immediately — Microsoft flips the feature in stages. If the new Start doesn’t show up right away, wait 24–72 hours and check again.

This supported path keeps your machine within Microsoft’s update and support model. It’s the safest route for everyday users and enterprise devices.

---

How to get the new Start menu now — community (unsupported) method with ViVeTool​

Power users and enthusiasts who don’t want to wait can force the feature locally using the community utility ViVeTool, which toggles Windows feature flags. This method is community‑driven and unsupported by Microsoft; it should only be used on test devices or after a full backup.
Step‑by‑step (community method):

• Install KB5067036 (or ensure you’re on one of the preview builds where the feature binaries are present — builds around 26100.7019 / 26200.7019 are commonly reported).
• Download ViVeTool:
• Get the latest release ZIP from the ViVeTool GitHub releases page or community mirror and extract it to an accessible folder (e.g., C:\ViVeTool). Always download from the official repository to avoid tampered binaries.
• Open an elevated terminal:
• Right‑click Start → Terminal (Admin), or search for cmd/PowerShell and choose Run as administrator.
• Navigate to the ViVeTool folder:
• cd C:\ViVeTool
• Run one of the community‑reported enable commands:
• Minimal command (commonly cited): vivetool /enable /id:47205210
• Variants that have been reported to work depending on build: vivetool /enable /id:47205210 /variant:2 or a compound enable with multiple IDs such as:
• vivetool /enable /id:57048231,47205210,56328729,48433719
• vivetool /enable /id:48433541,48433706,48433719,48468527,48468541
• Restart the PC when finished.
• To undo changes:
• Use vivetool /disable /id:<id> or vivetool /reset /id:<id> and restart.

Important notes about the ViVeTool path:

• ViVeTool manipulates feature flags via Windows’ Feature Management APIs — it does not rewrite system binaries in normal use, but the flags are community‑discovered and may change between builds.
• Because the rollout includes server‑side gating, flipping local flags may not always surface the complete experience if Microsoft’s backend still restricts certain features.
• Use ViVeTool only if you accept the risk of temporary instability, search/start regressions, or the need to roll back changes.

---

How to hide or remove the Recommended section (without third‑party tools)​

One of the frequent complaints about Windows 11’s Start menu has been the space used by the Recommended section. Microsoft exposed controls to reduce or hide its content, and administrators can remove the section via policy:

• For regular users, open Settings → Personalization → Start and turn off:
• Show recently added apps
• Show most used apps
• Show recently opened items in Start, Jump Lists, and File Explorer

Doing this leaves the Recommended header present but removes the items underneath, reducing clutter.

• For administrators (Pro/Enterprise/Education), Group Policy provides a setting:
• Computer Configuration or User Configuration → Administrative Templates → Start Menu and Taskbar → Remove Recommended section from Start Menu. Enabling this policy will prevent the Recommended list from appearing. Microsoft also provides CSPs for the same controls for managed devices.
• Registry changes can mimic the policy for environments without gpedit, but such edits should be made only by experienced administrators and after creating backups. Community documentation shows mixed behavior across editions; the Group Policy/CSP route is the supported approach for enterprise rollout.

---

Real‑world behavior and performance notes​

Early hands‑on reports and community testing show the redesigned Start is conceptually cleaner, but there are practical trade‑offs to be aware of.

• Responsiveness: Some testers report the new Start is notably slower to render and scroll smoothly on lower‑end machines compared with the older two‑pane Start layout. The rendering and search responsiveness vary by device and driver configuration. Performance may improve with subsequent updates, but users with older hardware should temper expectations.
• Search integration: Because the All apps view is now front and center and the surface is scrollable, natural discovery is improved; however, keyboard search and context‑menu actions in the All apps view (like pin/uninstall via right‑click) have had inconsistent behavior in early previews according to community reports. Expect Microsoft to iterate.
• Stability: Forcing feature flags can expose interactions the staged rollout is meant to catch. Reports from insiders show occasional Start/search glitches and inconsistencies after flipping flags — another reason the supported path is preferable for production devices.

---

Security, privacy, and administration considerations​

Enterprises and privacy‑conscious users should evaluate the redesign before broad deployment.

• Telemetry and Recommended items: Some Recommended content can be personalized and relies on Microsoft services and telemetry. While you can minimize what appears through Start settings, administrators should validate tenant policies and privacy configurations before enabling the feature fleet‑wide.
• Unsupported modifications: Using ViVeTool on corporate or managed endpoints is discouraged. It is unsupported and may violate compliance, change management, or support contracts. Use Windows Update servicing channels, pilot rings, and standard Microsoft deployment tools for enterprise rollouts.
• Group Policy and CSPs: Microsoft documents CSP and Group Policy settings to control Recommended behavior and other Start aspects. Admins should rely on those constructs to lock or configure Start for users across the estate.

---

Troubleshooting and rollback advice​

If you enabled the new Start via ViVeTool and encounter problems, here are safe steps:

• Disable the same feature IDs with ViVeTool:
• vivetool /disable /id:<id> or vivetool /reset /id:<id>
• Restart the PC.
• If the issue persists, uninstall the optional KB preview:
• Settings → Windows Update → Update history → Uninstall updates → remove KB5067036 (if present), then restart.
• Use System Restore or a full system image backup if you created one before experimenting. Always create a restore point and backup before toggling preview features.
• For managed devices, contact your helpdesk or follow established corporate rollback procedures to preserve compliance.

---

Assessment: strengths, weaknesses, and who should try it​

Strengths

• Streamlined discovery: The single scrollable Start brings All apps to the forefront and reduces context switching, which is a genuine usability improvement for many users.
• Flexible views: Category, Grid, and List views give users choices for how they browse apps, which helps across form factors.
• Responsive design: The Start menu’s ability to adapt to larger screens is a welcome change for people using desktop monitors and ultrawide displays.

Weaknesses and risks

• Performance variability: Early reports show sluggishness on some machines; the new rendering and layout may pressure slower systems until Microsoft tunes performance.
• Server‑side gating and fragmentation: Because enablement is staged, identical machines may have different Start experiences. That inconsistency complicates support documentation and rollouts in mixed environments.
• Unsupported hacks: Forcing the feature with ViVeTool introduces risks and should be avoided on production devices. IDs change between builds, meaning community commands may break or cause unexpected behavior in future updates.

Who should try it

• Enthusiasts and testers with non‑critical machines who want the new UI now and can tolerate instability.
• IT teams running pilot rings who can validate behavior on representative hardware and have rollback plans.
• General users who prefer stability should install KB5067036 and wait for Microsoft’s staged enablement or receive the feature in a broader Patch Tuesday rollout.

---

Final verdict​

The redesigned Start menu addresses many longstanding complaints about Windows 11’s launcher by simplifying navigation and promoting the All apps experience. For most users the safest approach is the supported path: install the KB5067036 preview if it’s offered for your device and wait for Microsoft’s staged enablement. Enthusiasts who choose the ViVeTool route can get the new Start immediately, but they must accept the trade‑offs: unsupported changes, possible instability, and the need for careful rollback procedures. Administrators should use Group Policy and CSPs where available to control Recommended content and adopt a measured pilot approach across fleets.
The redesign is a welcome, pragmatic step toward a more modern, scalable Start menu — but it’s not yet a finished product for every scenario. Users and IT teams should weigh the benefits of improved discoverability and layout flexibility against temporary performance and rollout fragmentation while Microsoft completes the staged deployment and continues iterative fixes.

---

---

Source: Beebom How to Enable the New Start Menu on Windows 11

Windows 11’s latest optional preview update, KB5067036, is producing an odd — and potentially costly — regression: clicking the Task Manager window’s Close (X) button can fail to terminate the app and instead leave behind a live taskmgr.exe process, and repeated opens-and-closes spawn additional orphaned Task Manager instances that quietly consume RAM and CPU until explicitly killed.

Background / Overview​

Microsoft published KB5067036 as an optional, non‑security preview update on October 28, 2025, shipping OS builds 26200.7019 and 26100.7019 for Windows 11 versions 25H2 and 24H2. The package bundles visible UI changes — notably a redesigned Start menu and new battery icons — alongside a number of under‑the‑hood fixes, including a stated correction to Task Manager’s process‑grouping logic.
Because KB5067036 is a preview update delivered in a staged rollout, not every device receives the same feature set at the same time; that staged model also means preview telemetry and early adopter reports often surface regressions months before a broad rollout. Community testing quickly flagged a lifecycle regression tied to the Task Manager changes in this preview, producing reproducible orphaned taskmgr.exe instances on some machines.

---

What users are actually seeing​

Symptom in plain terms​

• Open Task Manager (Ctrl+Shift+Esc).
• Close it using the top‑right Close (X) button.
• Reopen Task Manager and check Processes → Background processes.

If affected, you’ll see additional “Task Manager” entries; each repeated open→close cycle may increase the number of live taskmgr.exe processes. These are real processes (not a purely cosmetic UI quirk) and persist until explicitly terminated. Community reproductions show the duplicate entries appear in Task Manager’s own Processes list, in Process Explorer, and when queried with tasklist/Get‑Process.

Measured impact (community tests)​

Independent testers and commenters have recorded modest per‑instance memory usage — commonly around 20–30 MB per orphaned Task Manager process — but that adds up quickly in contrived stress tests where Task Manager was opened and closed dozens or hundreds of times. In one community test, ~100 open/close cycles produced roughly 2 GB of RAM used by orphaned instances; such extremes are unlikely in normal use but illustrate how repeated creation of orphaned processes can matter on memory‑constrained systems. Treat these numbers as community measurements, not Microsoft telemetry.

---

How to verify whether your PC is affected​

• Press Windows+R, type winver, and confirm the build number (look for 26100.7019 or 26200.7019 if you installed KB5067036).
• Press Ctrl+Shift+Esc to open Task Manager.
• Click the Close (X) button.
• Open Task Manager again and inspect Processes → Background processes.
• Alternatively, run PowerShell: Get‑Process -Name taskmgr or Command Prompt: tasklist /FI "IMAGENAME eq taskmgr.exe" to see how many instances are running. If you see multiple taskmgr.exe entries after the close/reopen cycle, your device is exhibiting the orphaning behavior.

---

Immediate mitigations and safe workarounds​

If you’ve installed KB5067036 and see duplicate Task Manager instances, the community and independent outlets recommend straightforward containment steps:

• Avoid using the window Close (X) button to exit Task Manager — it’s the action that appears to trigger the orphaning fault on affected builds.
• Use Task Manager’s End task button (right‑click the Task Manager entry under Background processes and select End task) to terminate the instance cleanly. Some users report End task works reliably for individual instances.
• Force‑kill all Task Manager processes from an elevated prompt:
• Open Command Prompt or PowerShell as Administrator.
• Run: taskkill /im taskmgr.exe /f

This forcibly terminates every running taskmgr.exe at once. Alternatively, in PowerShell: Get‑Process -Name taskmgr | Stop‑Process -Force.

• Use Sysinternals Process Explorer as a temporary replacement for Task Manager when you need robust process inspection without triggering the bug. Process Explorer provides deeper visibility (handles, threads, loaded modules) and offers fine‑grained kill options.

If performance impact is already visible (sluggishness, elevated idle CPU/RAM), kill the orphaned taskmgr.exe instances, then reboot to clear in‑memory residue. If the regression materially disrupts your work, consider uninstalling the preview update (rollback guidance below).

---

How to uninstall KB5067036 (rollback guidance)​

Because KB5067036 is an optional preview that may include a combined SSU+LCU package for some installations, removal semantics can vary. The safe high‑level steps are:

• Open Settings → Windows Update → Update history → Uninstall updates.
• Locate the Windows update entry for KB5067036 and choose Uninstall; reboot if prompted.
• If uninstall is not available (combined SSU/LCU scenarios), use Advanced Startup → Troubleshoot → Advanced options → Uninstall Updates, or follow the KB article’s removal instructions. For enterprise or stuck systems, DISM /Remove‑Package may be required to remove the LCU portion — consult your update management documentation before taking that step.

Important operational note: uninstalling preview packages on managed devices should be coordinated with IT policies and backup/restore procedures. Preview updates exist to be validated in pilot rings for exactly these reasons.

---

Technical analysis: what likely went wrong​

The KB’s change log explicitly mentions a fix for how Task Manager groups apps with their processes — a plausible place for an unintended regression. Modern Task Manager performs two main duties: a UI thread that owns the window and an internal monitoring subsystem that samples performance counters and marshals data to the UI. If a change to grouping or object ownership altered reference counts, COM lifetimes, or thread shutdown sequencing, a close handler could properly destroy the window while leaving a background monitoring thread or referenced object alive, preventing the process from exiting. When the UI is restarted, a new taskmgr.exe instance may spawn, while the previous monitoring thread remains resident — creating the effect of duplicate Task Manager entries.
This hypothesis is consistent with the observable data points:

• Orphaned taskmgr.exe entries appear under Background processes (UI destroyed but process persists).
• Community reproductions show the symptom is reproducible on affected builds but not universal, hinting at environmental triggers, third‑party hooks, or staged feature gating.

Caveat: until Microsoft publishes a confirmed root‑cause or known‑issue acknowledgment, this remains a well‑fitted hypothesis. Treat it as informed conjecture consistent with Windows lifecycle bugs observed in past preview updates.

---

Who’s affected and why it matters​

• Casual users who open Task Manager infrequently may see no measurable impact — the bug is not universal.
• Power users, developers, helpdesk engineers, and admins who frequently open and close Task Manager are more likely to trigger multiple orphaned instances and therefore experience cumulative resource consumption.
• Battery‑sensitive and memory‑constrained devices (ultrabooks, tablets, older entry‑level laptops) will be disproportionately impacted if multiple orphaned Task Manager processes accumulate.

For enterprises, the bug is a reminder to treat optional preview updates as test artifacts: include basic lifecycle checks (open/close, restart, uninstall) for essential utilities in pilot acceptance plans. Rolling preview updates directly into production without staged validation increases risk for precisely these kinds of regressions.

---

How to report the bug and accelerate a fix​

• Submit a Feedback Hub entry with reproducible steps: attach a short screen recording showing open → Close (X) → reopen and the growing Task Manager count.
• Include a Winver screenshot showing the build number (26100.7019 or 26200.7019).
• Attach diagnostic dumps when possible: ProcMon traces filtered for taskmgr.exe, ETW traces for process lifetime, and tasklist/Get‑Process outputs showing multiple taskmgr.exe instances.
• If you’re an enterprise customer, open a Microsoft support case and attach the above artifacts; the extra telemetry expedites triage.

Community threads and independent articles note that Microsoft had not acknowledged this specific Task Manager duplication as a known issue at the time early reports circulated, though the vendor’s KB page still listed the preview’s builds and changes. Continued reproducible reports and diagnostic attachments are the fastest path to vendor confirmation and an out‑of‑band patch.

---

Risk assessment and longer‑term implications​

• Short‑term user impact: annoyances, possible slowdowns, and wasted battery life if orphaned processes accumulate. The risk increases on low‑RAM systems or when users habitually open/close Task Manager.
• Operational risk for organizations: this is primarily an availability/usability regression rather than a security vulnerability, but it can still impose support costs and productivity loss. Enterprise deployment guidance is to avoid installing optional preview updates on production fleets until a fix is released and validated.
• QA and process lessons: the bug underscores the importance of including lifecycle tests (launch/close/uninstall) for system utilities in automated regression suites. Small UI or grouping changes can cascade into lifecycle regressions that are easy to miss in feature‑focused test plans.

---

Practical recommendations (quick checklist)​

• If you rely on Task Manager regularly: pause or avoid installing KB5067036 on production devices until Microsoft issues an update that addresses the regression.
• If you already installed the preview and are affected:
• Don’t use the Close (X) to exit Task Manager.
• Use End task or run taskkill /im taskmgr.exe /f to clear instances.
• Use Process Explorer for advanced process inspection.
• For IT teams:
• Restrict preview updates to pilot rings containing helpdesk and power‑user devices.
• Collect repro artifacts (ProcMon, ETW, Winver, recordings) and open a Microsoft support case if multiple endpoints are affected.

---

What to expect next​

Historically, when preview updates produce reproducible regressions with clear repro steps and user impact, Microsoft either updates the KB with a known‑issue acknowledgement or issues a follow‑up cumulative or out‑of‑band patch to remediate the problem. Given the explicit Task Manager changes listed in the KB and the reproducible nature of the duplication bug, a targeted fix to Task Manager’s teardown or grouping logic is the most probable remediation pathway. Until Microsoft publishes a confirmed root‑cause or patch, users should rely on the mitigations outlined above.

---

Final assessment​

This Task Manager duplication bug is not a cosmetic oddity; it is a lifecycle regression that can quietly eat memory and add CPU overhead over time, particularly on systems where users repeatedly open and close Task Manager. The bug’s appearance in an optional preview update underscores the value of preview channels: they catch environment‑specific regressions before broad distribution. The practical mitigations are simple and effective — avoid the Close (X), use End task or taskkill, and uninstall the preview on production endpoints if needed — but the incident is a stark reminder that even small changes to UI or grouping logic can have outsized effects on core utilities and support load.
If you are monitoring this issue on behalf of users or a deployment, collect reproducible traces, escalate through Feedback Hub or a Microsoft support case, and hold off on broader deployment of KB5067036 until a corrected package is published and validated.

---

Conclusion: KB5067036 brings welcome UI and functional updates to Windows 11, but the unexpected Task Manager close‑path regression makes this preview a poor fit for production devices that rely on stable management tooling. Follow the containment steps above, gather diagnostic evidence if you’re affected, and wait for Microsoft’s engineering confirmation and a corrective update before reintroducing the preview across critical endpoints.

---

Source: The Verge A bizarre Windows 11 bug duplicates Task Manager instead of closing it

A surprising and disruptive regression in Microsoft’s October 28, 2025 optional preview update is leaving multiple copies of Task Manager running in memory after users close the window — a glitch that can quietly consume RAM and CPU and that so far has required manual containment rather than a vendor patch.

Background / Overview​

Microsoft published the non‑security preview update KB5067036 (OS builds 26200.7019 and 26100.7019) on October 28, 2025. The package bundles a redesigned Start menu, taskbar battery refinements, File Explorer tweaks and several reliability fixes, including an explicit change intended to improve how Task Manager groups apps with their processes. The update is being delivered as an optional, staged rollout for Windows 11 versions 24H2 and 25H2.
Within days of the rollout, independent testers and community members began reporting that clicking the Task Manager window’s Close (X) button sometimes fails to terminate the program. Instead, the process remains resident in memory. Reopening Task Manager repeatedly in that state spawns additional taskmgr.exe processes — producing two, three, or many more instances that persist until explicitly killed. Multiple outlets and forum threads have reproduced and documented the symptom.

---

What users are seeing (symptoms and reproduction)​

• Symptom in short: open Task Manager (Ctrl+Shift+Esc), click the Close (X) button, reopen Task Manager — find more than one "Task Manager" entry under Processes. Repeat and the count increases.
• The orphaned entries are real processes (taskmgr.exe), not merely UI artifacts. They appear in Process Explorer, PowerShell Get‑Process output, and the native Process list. Memory per orphaned instance in community tests is modest (roughly 20–30 MB), but repeated opens can accumulate into hundreds of megabytes or even multiple gigabytes in contrived tests.
• The bug is not universal: some machines with the preview applied behave normally while others reproduce the duplication reliably. That variability points to environmental triggers, staged feature flags, or interactions with third‑party drivers/services.

This is a live, community‑driven discovery rather than a Microsoft‑acknowledged known issue at the time of reporting; the KB’s initial release notes do not list the duplicate‑Task‑Manager symptom. Users affected by the behavior have relied on the command line and Task Manager’s own UI to clear orphaned instances.

---

Why this likely happened (technical analysis and hypothesis)​

Modern Windows UI components and system utilities like Task Manager use a combination of UI threads, background sampling threads, and references to system services and performance counters. Closing a window typically triggers a teardown sequence (WM_CLOSE → WM_DESTROY → cleanup) that ends the process when all references are released.
A plausible hypothesis — consistent with the KB’s stated fix to Task Manager grouping logic — is that a change in how Task Manager registers or tracks grouped processes altered its shutdown path. If a background monitoring thread, COM object, or handle to a system resource is not being released correctly on window close, the process can remain alive even after its UI is hidden. Launching Task Manager again spawns a fresh process while the previous one lingers, producing the duplicate entries visible in Processes.
This explanation is a well‑fitted hypothesis based on common lifecycle regression patterns, but it is not a confirmed root cause; vendor engineering traces (ETW, ProcMon, Process Explorer stacks) are required to definitively identify the offending thread, handle, or DLL. Treat the teardown‑path explanation as plausible but unverified until Microsoft publishes a post‑mortem or a fix.

---

Immediate mitigations — how to stop the leak now​

If Task Manager is duplicating on a device, these steps will remove orphaned instances and prevent further accumulation until an official fix is released.

• Fast kill (single command)
• Open an elevated Command Prompt (Run as Administrator).
• Run: taskkill /im taskmgr.exe /f
  This forcibly terminates all running Task Manager instances in one step.
• PowerShell alternative
• Open PowerShell (Admin).
• Run: Get-Process -Name taskmgr | Stop-Process -Force
• End‑task from within Task Manager (safer GUI method)
• Open Task Manager (Ctrl+Shift+Esc).
• In Processes, look under Background processes for multiple Task Manager entries, right‑click each and choose End task.
• To avoid creating new orphaned entries, end the Task Manager process from inside Task Manager rather than clicking the Close (X).
• Reboot if you notice sluggishness or persistent resource usage. A reboot clears lingering in‑memory processes and restores a clean state.
• If you don’t need the preview features, uninstall the optional update:
• Settings → Windows Update → Update history → Uninstall updates, then remove the KB5067036 package. Note: some combined servicing packages may have more complex uninstall semantics; follow Microsoft’s KB guidance for removal.

---

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

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

---

For system administrators: containment and fleet strategy​

• Pause or stage the rollout. Treat KB5067036 as an optional preview update and withhold it from broad production rings until Microsoft confirms and resolves the regression. Use Windows Update for Business, WSUS, or SCCM rings to enforce delay.
• Deploy automated remediation scripts to affected endpoints:
• One‑line remediation for Intune/remote management: taskkill /im taskmgr.exe /f
• Health check script: detect >1 taskmgr.exe instance and trigger remediation or report telemetry to the management console.
• Collect diagnostic artifacts for Microsoft support cases:
• winver screenshot and exact build number.
• ProcMon trace filtered for taskmgr.exe.
• ETW traces capturing process create/exit events.
• Short screen recording showing open → close → reopen reproduction.
• Process Explorer capture (handles, loaded DLLs, thread stacks).
• If the behavior is widespread across controlled devices, consider rolling back KB5067036 in affected clusters and opening a formal support case with Microsoft including the artifacts above.

---

Reporting, diagnostics and what to attach to a Feedback Hub entry​

When filing Feedback Hub or an enterprise support case, include reproducible steps and evidence:

• Exact build (winver) and KB number.
• A short screen recording showing the issue (open-close-open) and the Processes pane with multiple Task Manager entries.
• ProcMon trace filtered to taskmgr.exe and any suspicious drivers/services.
• ETW traces capturing process lifecycle events.
• Process Explorer’s list of loaded modules and handles for orphaned taskmgr.exe instances.

The more complete the artifact set, the faster Microsoft can triage and identify which thread or handle is preventing process termination. Community reporting has emphasized that precise repro artifacts materially accelerate vendor engineering response.

---

Risk assessment: why this matters beyond annoyance​

• Performance and battery: each orphaned taskmgr.exe instance consumes memory (tens of MB) and may keep background sampling threads active. On low‑RAM devices, dozens of orphaned copies can measurably reduce responsiveness and battery life. One community test that repeatedly opened Task Manager tens to hundreds of times reported cumulative consumption in the gigabyte range — a contrived but illustrative scenario. Treat single‑user or small‑scale reports with caution, but acknowledge the measurable impact on thin clients and laptops.
• Support load: helpdesk volumes spike when a core diagnostic tool behaves unpredictably. The regression increases ticketing and rollback work for IT teams and complicates update policies.
• Operational risk: preview updates are intended to surface regressions before broad release, but staged or server‑gated features can produce inconsistent behavior across identical devices — making triage and rollout decisions harder. This incident illustrates the tradeoff between early feature exposure and production stability.

---

QA lessons and why lifecycle tests matter​

This bug is a reminder that small UI or grouping changes can ripple into lifecycle code paths that every user exercises — notably close and exit sequences. Key QA lessons:

• Add simple lifecycle tests (open/close, restart, graceful shutdown) to automated regression suites for high‑frequency system utilities like Task Manager. These tests catch teardown regressions early.
• Test across a variety of third‑party configurations (security suites, performance monitoring hooks, shell extensions) because those integrations often change process lifecycle behavior.
• Monitor staged rollouts for outliers and enable a fast rollback path for preview packages that interact with management and diagnostic tooling.

---

Cross‑checks and verification of key claims​

• The update identity and publish date are confirmed on Microsoft’s official support page for October 28, 2025 — KB5067036 (OS Builds 26200.7019 and 26100.7019). That page lists the new Start menu and other changes but did not initially list the Task Manager duplication as a known issue.
• Independent outlets including The Verge, TechRadar, PC Gamer and WindowsLatest reproduced and reported the Task Manager duplicate behavior and recommended the same workarounds (End task, taskkill). These independent reports corroborate the basic symptom and pragmatic mitigations.
• Community testing (Windows Latest) published experimental reproduction results (example: ~30% reproduction across 100 VMs in one test) and test videos; treat single‑organization experimental rates as useful signals but not representative of global telemetry until Microsoft publishes official data. Flag these reproduction percentages as laboratory observations rather than vendor‑confirmed metrics.

---

Practical cheat sheet (copy‑and‑paste)​

• Check build: winver → look for 26200.7019 / 26100.7019.
• Kill all Task Manager instances: taskkill /im taskmgr.exe /f.
• PowerShell variant: Get-Process -Name taskmgr | Stop-Process -Force.
• GUI: Open Task Manager → Processes → Background processes → right‑click Task Manager → End task. Then avoid closing the window with the X until a fix ships.

---

What Microsoft has said (and what to watch)​

At publication the KB article for KB5067036 lists the update’s changes and points users to the Windows Release Health dashboard for ongoing status updates. Community reporting has outpaced an explicit Microsoft acknowledgment of the duplicate‑Task‑Manager symptom; historically Microsoft has used Release Health entries and out‑of‑band patches when a regression is confirmed and widespread. A public acknowledgment or an updated KB/Release Health entry should be monitored closely. Until Microsoft issues a corrective patch or an update to the KB notes, the mitigations above are the most reliable containment measures.

---

Conclusion — measured caution, clear actions​

The Task Manager duplication bug introduced with KB5067036 is an irritating but manageable regression for most users. The immediate risk is resource accumulation and the extra support burden for IT teams who rely on Task Manager for diagnostics. Containment is straightforward: avoid closing Task Manager with the window X, use End task from inside Task Manager, or run taskkill /im taskmgr.exe /f to clear all instances. Enterprises should pause optional preview rollouts, stage updates in pilot rings, and deploy automated remediations if necessary.
This episode reinforces two practical rules: treat optional preview updates as exactly that — pre‑release testing material — and include simple but essential lifecycle checks (open/close, graceful exit) in automated test suites. When a diagnostic tool behaves unexpectedly, collect and file reproducible artifacts (ProcMon, ETW, Process Explorer stacks) to accelerate vendor triage and resolution. The path forward is straightforward: contain the symptom, collect diagnostics, and watch Microsoft’s Release Health and KB pages for a confirmed fix.

---

Appendix — quick reference commands

• Kill Task Manager instances (Admin Command Prompt):
  taskkill /im taskmgr.exe /f
• PowerShell (Admin):
  Get-Process -Name taskmgr | Stop-Process -Force
• Verify instances (non‑admin):
  tasklist /FI "IMAGENAME eq taskmgr.exe"
  Get-Process -Name taskmgr
• Uninstall preview: Settings → Windows Update → Update history → Uninstall updates (select KB5067036 if present).

This situation is evolving; monitor Microsoft’s official KB/Release Health updates and community reproducible reports for progress and an eventual patch.

---

Source: ZDNET Windows 11 users hit with bizarre Task Manager duplication bug - here's how to avoid it

Windows 11’s optional October preview (KB5067036) has introduced a strange regression that can turn the very tool meant to tame runaway processes into a quiet resource sink: closing Task Manager with the window’s Close (X) control sometimes does not terminate taskmgr.exe, and repeated open/close cycles spawn additional, orphaned Task Manager processes that accumulate memory and CPU over time.

Background​

Microsoft shipped KB5067036 as an optional, non‑security preview update delivered in a staged rollout for Windows 11. The package bundles visible UI changes — a redesigned Start menu, revised battery icons, and a series of under‑the‑hood fixes — and it explicitly calls out adjustments to how Task Manager groups apps with their processes. The preview was published in late October 2025 and has been reported on by multiple community test reports and independent outlets.
The update is targeted at OS builds 26200.7019 and 26100.7019 for Windows 11 servicing branches. Because KB5067036 is an optional, staged preview, not every device receives the same changes at once — a detail that helps explain why the Task Manager problem appears on some machines but not others.

---

What’s happening: the symptom in plain terms​

• Open Task Manager (Ctrl+Shift+Esc).
• Close it with the top‑right Close (X) button.
• Reopen Task Manager and check Processes.

If the machine is affected, you’ll find an additional “Task Manager” entry in the Processes list; repeating the open → close cycle increases the number of live taskmgr.exe processes. These are not UI artifacts — they are real processes visible in Task Manager’s Details view, in Process Explorer, and via command‑line tools such as tasklist or PowerShell’s Get‑Process. Community reproductions have documented the exact sequence and shown the duplicates persisting until explicitly terminated.

Measured impact (community tests)​

Independent testers and community members report that each orphaned Task Manager instance typically consumes modest memory — commonly in the range of 20–30 MB per process. That per‑instance footprint is small, but when users repeatedly open and close Task Manager (intentionally or as part of a support workflow), the accumulation can scale into hundreds of megabytes or even multiple gigabytes in contrived stress tests. One test cited roughly 2 GB used after ~100 open/close cycles. CPU impact per orphaned instance is usually low but not zero; small polling spikes of up to ~1–2% per instance have been observed during telemetry sampling. Those micro‑spikes aggregate across many instances and can lead to noticeable UI stutter and reduced battery life on laptops.

---

Why it likely happened (technical analysis and hypotheses)​

KB5067036 explicitly modified internal Task Manager code related to how apps are grouped with their processes. A plausible and technically consistent hypothesis is that the change to grouping logic inadvertently altered Task Manager’s shutdown or teardown path. In modern Windows applications, closing a window should trigger a teardown sequence (WM_CLOSE → WM_DESTROY → cleanup) that releases handles, COM objects, and background threads so the process can exit cleanly. If a new grouping thread, a monitoring routine, or a reference to a performance counter is not released on window close, the process can remain resident while its UI disappears. Launching Task Manager again creates a fresh taskmgr.exe process while the previous process lingers, producing the duplicates people are seeing.
This hypothesis aligns with common lifecycle regression patterns and the symptoms reported, but it remains an inference until Microsoft publishes a formal root‑cause analysis. Community traces such as ProcMon captures, ETW process lifetime traces, and Process Explorer thread stacks would be necessary to identify the precise leaking handle, thread, or DLL. Until vendor diagnostics are available, treat the teardown‑path explanation as a plausible working theory rather than confirmed fact.

---

Who’s affected and why it matters​

Not every machine that installed the preview demonstrates the behavior. The issue appears to be environment‑dependent — consistent with staged feature flags, driver or third‑party service interactions, or server‑side gating of preview features. But the practical impact is clear for those who trigger it:

• Power users, developers, and helpdesk engineers who open Task Manager frequently are most exposed because their workflows create many open/close cycles.
• Memory‑constrained devices such as older laptops and entry‑level tablets will feel the effect sooner.
• IT administrators may see increased support tickets and may need to stage rollbacks or containment strategies in managed environments.

Operationally, this is a usability and availability regression rather than a security exploit, but it can impose measurable productivity and energy costs. The illusion of a diagnostic tool becoming a source of load is particularly damaging to trust and troubleshooting workflows.

---

Immediate mitigations and practical fixes​

Until Microsoft issues a corrective update, affected users and administrators can rely on straightforward containment and cleanup steps. These are safe, low‑risk actions that avoid further accumulation and quickly remove existing orphaned instances.

Quick detection​

• Press Ctrl+Shift+Esc to open Task Manager.
• Click the Close (X) button.
• Reopen Task Manager and expand Background processes — check whether the number of “Task Manager” entries increases after each open/close.

Alternatively, verify via command line:

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

If you see more than one instance after the open/close test, you’re affected.

Fast removal (single command)​

Open an elevated Command Prompt or Windows Terminal (Admin) and run:

• taskkill /im taskmgr.exe /f

This force‑kills all running Task Manager instances in one command. The PowerShell equivalent is:

• Get‑Process -Name taskmgr | Stop‑Process -Force

A reboot also clears orphaned processes. Using Task Manager’s own End task action is the safest GUI method — right‑click each Task Manager entry in Processes and choose End task until all instances are removed. Avoid repeatedly using the window Close (X) while the issue is unresolved.

If you want to avoid the preview entirely​

Because the regression is tied to an optional preview package, conservative users should avoid installing optional preview updates until fixes land. Consumers can toggle off preview update delivery via Settings → Windows Update by turning off “Get the latest updates as soon as they’re available.” For machines where the preview was installed and the update is disruptive, uninstalling the KB via Settings → Windows Update → Update history → Uninstall updates may be effective — though be aware combined SSU + LCU packages can have more complex uninstall semantics. Enterprise removal may require DISM commands; follow internal change control procedures.

---

Guidance for IT teams and administrators​

This incident is a textbook example of why preview channels and staged rollouts exist: to discover environment‑specific regressions before broad distribution. IT teams should treat KB5067036 as preview and avoid immediate broad deployment to production rings. Recommended actions:

• Add Task Manager lifecycle checks (open/close/end task) to pilot acceptance testing.
• Enforce a staged rollout using Windows Update for Business, WSUS, or SCCM.
• Deploy a simple detection and remediation script that:
• Detects more than one taskmgr.exe instance.
• Logs a diagnostic snapshot (winver, tasklist, Process Explorer dump).
• Optionally runs taskkill /im taskmgr.exe /f or schedules a reboot.
• If multiple endpoints reproduce the issue, open a Microsoft support case with reproducible steps and diagnostic artifacts (ProcMon, ETW traces, recordings) to accelerate triage.

Including Task Manager in smoke tests for management utilities is essential. When a standard tool used for remediation becomes unreliable, incident response and helpdesk workflows are impaired.

---

QA lessons and the testing blind spot​

This regression highlights a recurring reality in large, mature codebases: small UI changes can ripple into lifecycle paths that are easy to miss. Testing that focuses on feature behavior (does grouping look correct?) can overlook teardown semantics (does the process actually exit?). To catch these regression classes, test suites must include:

• Lifecycle tests that exercise open → close → reopen sequences across feature flags and grouped/ungrouped views.
• Long‑running automation that repeatedly creates and closes key management utilities to reveal resource leaks.
• Environmental matrix coverage that includes common third‑party security suites, monitoring agents, and key driver families that often interact with system utilities.
• Native telemetry capture (ETW, process create/exit) as part of preview telemetry to flag unusual process lifetimes early.

Preview channels are doing their job by surfacing this issue prior to broad release, but the incident is also a reminder that QA must include lifecycle and long‑tail interaction tests for core utilities.

---

Risk assessment and longer‑term implications​

Short term, the bug is a nuisance that causes wasted memory and small CPU overhead. The severity increases for devices with limited RAM or for users whose workflows repeatedly open and close Task Manager. For enterprises, the cost is operational — increased support volume, potential rollbacks, and small productivity losses while mitigations are applied. There is no credible evidence that this behavior introduces a security vulnerability on its own, but a buggy system utility can hinder detection of other issues and confuse users during incident triage. That secondary risk should not be discounted.
Historically, Microsoft has patched high‑impact regressions when reliable reproductions and diagnostic artifacts accumulate. Given the preview noted explicit changes to Task Manager internals, a targeted remediation to the teardown logic or the grouping code path is the most likely corrective measure. Administrators and power users should monitor official update channels and the Windows Release Health dashboard for a known‑issue acknowledgement and a follow‑up fix.

---

What to report and how to accelerate a fix​

If you reproduce the behavior and want to help expedite a vendor response, collect the following and submit via the Windows Feedback Hub or an enterprise support case:

• Winver screenshot showing the OS build (look for 26100.7019 or 26200.7019 if KB5067036 is installed).
• A short screen recording showing open → Close (X) → reopen with the growing Task Manager count.
• ProcMon traces filtered for taskmgr.exe, ETW traces for process lifetime, and thread stacks from Process Explorer showing live threads in orphaned instances.
• tasklist/Get‑Process outputs showing multiple taskmgr.exe entries and a list of loaded DLLs/handles per orphaned instance.

Repro artifacts with clear steps materially speed triage, especially for environment‑dependent regressions.

---

Final assessment​

The KB5067036 Task Manager duplication bug is an awkward but instructive glitch: a focused internal change meant to improve process grouping appears to have crossed an important lifecycle boundary and left user machines with orphaned taskmgr.exe processes when Task Manager is closed via the window X. The symptom is reproducible on many devices, though not universal, and it is easy to mitigate with simple commands or by avoiding the window Close control until Microsoft issues a fix. The incident underlines the importance of including lifecycle testing and environmental variant coverage in preview validation, and it’s an immediate reminder for administrators to keep optional previews confined to pilot rings.
For now, the pragmatic path for stability is clear: avoid using the Task Manager Close (X) control on systems with KB5067036, use End task or taskkill to clear instances, and withhold the optional preview from production machines until Microsoft provides a corrective update. The fix is likely to be surgical and focused on Task Manager teardown/granularity logic, but until vendor engineering confirms the root cause, the mitigations above are the best defense against silent resource bloat.

---

Conclusion: a utility meant to restore control has briefly become part of the problem. The visible good news is that the regression is not widespread across all installs and that practical, low‑risk mitigations exist. The less comfortable lesson is that even the most mundane system tools deserve lifecycle and stress testing — because when basics like Task Manager misbehave, trust and productivity take an outsized hit.

---

Source: theregister.com Microsoft Task Manager bug spawns new processes

Microsoft’s optional October preview for Windows 11 has introduced a puzzling regression: the Task Manager can fail to close and instead leave behind multiple running taskmgr.exe instances, producing a slow, hard‑to‑diagnose resource leak for affected systems and forcing users to adopt manual workarounds until Microsoft issues a fix.

Background / Overview​

Microsoft issued the non‑security preview cumulative update identified as KB5067036 on October 28, 2025, shipping OS builds 26200.7019 (25H2) and 26100.7019 (24H2). The package bundles visible changes — a redesigned Start menu, updated taskbar battery icons, File Explorer improvements and several quality fixes — and it explicitly mentions a change intended to improve Task Manager process grouping. The official KB page also noted at publication that “Microsoft is not currently aware of any issues with this update.”
The update was delivered as an optional preview (gradual rollout), which means features and fixes are staged and not uniformly enabled across all devices. That staged delivery model explains why the Task Manager duplication symptom appears on some machines but not others: preview code, feature flags and environmental differences commonly produce uneven behaviour in early field testing.

---

What the bug looks like (symptoms and quick reproduction)​

The observable symptom​

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

If the system is affected, you’ll see one or more additional “Task Manager” entries in the Processes list. Each repeated open→close cycle can create another running taskmgr.exe instance that remains resident until explicitly killed. These ghost instances are real OS processes (not UI artifacts) and show up in Process Explorer, PowerShell Get‑Process, and tasklist output.

Measured impact in community tests​

Independent testing and community reproductions show that each orphaned Task Manager instance typically consumes a modest amount of memory — commonly about 20–30 MB — and can use a small amount of CPU when polling system counters (often 0–2% per instance during sampling spikes). In contrived stress tests where Task Manager was opened and closed repeatedly, those modest per‑instance footprints can sum to hundreds of megabytes or even gigabytes if dozens or hundreds of instances accumulate. The practical effect on responsiveness and battery life depends on baseline system RAM and workload.

---

Why this likely happened — a technical hypothesis​

The update’s release notes explicitly reference a fix to Task Manager’s process grouping logic. Task Manager performs two types of work: a UI thread that renders windows and one or more background monitoring threads that sample performance counters and marshal data. A change that adjusts grouping semantics or object ownership could inadvertently alter reference counting, thread lifetime, or COM object teardown. If the close path fails to tear down background sampling threads or releases references correctly, the process can remain alive while the UI disappears — producing the “ghost” behavior observed. This lifecycle regression is consistent with how modern multi‑threaded services can fail when lifecycle code paths are touched.
Important caution: this is an informed hypothesis derived from how Task Manager internals typically operate, and the exact root cause has not been published by Microsoft. Treat the technical explanation as plausible but not verified until Microsoft publishes a post‑mortem or a known‑issue acknowledgement with diagnostic details.

---

Independent confirmation and scope​

Multiple independent outlets and large user communities reproduced the behaviour within days of the preview’s rollout, and their testing shows the issue is real but not universal. Reporting outlets include major tech publications and several community threads that document step‑by‑step reproduction and memory/CPU measurements. That cross‑publication corroboration strengthens confidence that this is an actual regression introduced by the preview package, not an isolated OEM or driver issue.
Key verified facts:

• KB5067036 was released on October 28, 2025 and updates Windows 11 to builds 26100.7019 / 26200.7019.
• Multiple independent outlets reproduced Task Manager remaining resident after the Close (X) action and spawning duplicate taskmgr.exe instances.
• Community reproductions report per‑instance memory usage in the order of ~20–30 MB, with small periodic CPU use when the orphaned instances poll counters.

---

Workarounds and containment (how to fix or avoid the problem now)​

Because this is an optional preview update, the easiest path for many users is to avoid installing it on production devices. If you already installed KB5067036 and see duplicates, the following short‑term mitigations are effective:

• Use End task from within Task Manager:
• Open Task Manager.
• Expand Background processes.
• Right‑click the Task Manager entry and select End task for each orphaned instance.
  This reliably terminates the leftover process entries.
• Kill Task Manager from the command line:
• Open an elevated Command Prompt or PowerShell and run:
  taskkill /im taskmgr.exe /f
  This forces all taskmgr.exe processes to terminate.
• Reboot the system:
• A restart clears the orphaned processes because they are in‑memory only and do not persist across boot.
• Use Sysinternals Process Explorer as an alternative:
• Process Explorer provides robust process control and is unaffected by this duplication behaviour; it can be used to inspect handles and threads and to kill lingering taskmgr.exe instances safely.
• Uninstall the preview (for administrators and power users):
• If KB5067036 was installed and the behaviour is unacceptable for production users, uninstall the update using the Windows Update history or DISM/Remove‑Package as appropriate for your servicing model.
• For enterprise fleets, stage a rollback for affected clusters following Microsoft’s uninstall guidance for combined packages (note: SSUs cannot be removed once installed; follow Microsoft’s guidance).

Practical tip: If you frequently use Task Manager as part of your workflow, avoid closing it with the window Close (X) until Microsoft releases a fix — instead use the End task path or close Task Manager from the menu if the UI supports it.

---

Impact assessment — who should care, and how badly​

• Home users with typical habits: minimal short‑term risk. If you open Task Manager occasionally and reboot nightly, the odds of accumulating many orphaned instances are low. The memory per instance is modest, and user sessions that routinely restart will clear the problem.
• Power users, developers and IT staff: higher risk. These roles tend to open and close Task Manager many times per day and are more likely to notice performance impacts and excessive memory consumption. If you use Task Manager as a primary troubleshooting tool, the bug is an immediate nuisance and should be treated as a reason to avoid the preview on workstations that must remain stable.
• Low‑RAM devices and battery‑sensitive laptops: meaningful risk. On systems with limited memory, dozens of orphaned taskmgr.exe instances can cause swapping, stuttering and battery drain that are noticeable during normal use. Administrators should be cautious about deploying optional previews to fleet machines with constrained resources.
• Enterprise and managed fleets: high operational risk if rolled broadly. Preview updates should be limited to pilot rings; this regression is a textbook example of why preview channels exist — to expose environment‑specific regressions before full distribution. Enterprises should pause broad rollout of optional previews and validate management tooling on pilot devices that include helpdesk and developer machines.

---

What Microsoft has said (and what to watch next)​

At the time of reporting, Microsoft’s KB page for the October 28 preview explicitly listed the update’s features and fixes and also stated that the company was “not currently aware of any issues with this update.” Community reporting surfaced the Task Manager duplication behaviour shortly after the rollout, and Microsoft had not published a known‑issue acknowledgement specifically naming this symptom when the initial KB was posted. Microsoft historically uses the Windows Release Health dashboard and follow‑up KB edits to publish known‑issue acknowledgements and remediation guidance; affected users and administrators should monitor those official channels for an update.
Expectations and timeline:

• If Microsoft can reproduce the issue internally and corroborate it with telemetry, a known‑issue acknowledgement (KIA) and either an out‑of‑band fix or inclusion in the next cumulative update are likely. Microsoft has remediated similar Task Manager regressions in past servicing cycles, so a timely patch is plausible — but the exact timeline depends on root‑cause complexity and servicing windows.

---

Recommendations — practical checklists​

For everyday users​

• If stability matters: skip optional preview updates (turn off “Get the latest updates as soon as they’re available”) until Microsoft confirms a fix.
• If you see duplicates: run taskkill /im taskmgr.exe /f and reboot; avoid the X button until cleared.
• If you rely on Task Manager: consider using Process Explorer temporarily for advanced control.

For IT admins and helpdesk​

• Pause deployment of KB5067036 outside pilot rings.
• Add lifecycle tests to acceptance suites (open/close/uninstall scenarios for management utilities).
• Collect reproducible diagnostics (ProcMon, ETW, Process Explorer captures, winver screenshots) from affected devices and submit Feedback Hub entries or open Microsoft support cases with attachments.
• If necessary, plan a rollback and follow combined package uninstall guidance; prioritize endpoints that use Task Manager heavily in pilot remediation.

---

Broader lessons for update management and QA​

This incident underlines several predictable but important lessons:

• Preview and staged rollouts reduce blast radius but still expose many users to environment‑specific regressions when feature flags are toggled server‑side.
• Lifecycle testing (open/close/uninstall) for core system utilities must be part of automated regression suites; the “close” path is exercised by every user and should never be omitted from end‑to‑end tests.
• Clear vendor communication (fast known‑issue acknowledgements and mitigation steps) reduces helpdesk load and user confusion. The absence of an immediate KIA can lead to fragmented community guidance and inconsistent workarounds.

---

Final analysis and conclusion​

KB5067036 delivers notable UX improvements — a redesigned Start menu, new taskbar battery indicators and several bug fixes — but the Task Manager duplication regression is an unwelcome example of how small changes to process grouping or UI logic can ripple into core lifecycle code and disrupt everyday workflows. The bug is not universal, but it is reproducible and capable of producing measurable resource consumption on systems where Task Manager is opened and closed frequently.
For individuals and IT teams that need stable management tooling, the prudent course is clear: avoid optional previews on production devices, use the documented workarounds (End task, taskkill, reboot) if you are affected, and treat pilot rings as the appropriate place to absorb preview risk while collecting telemetry and reproducible traces for vendor triage. The root‑cause explanation remains speculative until Microsoft publishes definitive engineering notes, but history suggests a targeted fix to Task Manager’s teardown/grouping logic is the likely remediation path.
Until Microsoft confirms and issues a patch, contain the problem with the mitigations above, monitor the official Windows Release Health and KB pages for updates, and treat this event as a reminder that preview channels — useful as they are — require controlled, well‑instrumented adoption to prevent end‑user disruption.

---

---

Source: Thurrott.com Windows 11's October Preview Update Has Task Manager Duplication Issue

Microsoft’s optional October preview for Windows 11, released as KB5067036, has produced a surprising and insidious regression: clicking the Task Manager’s close button can leave the underlying taskmgr.exe process running and, on repeat use, spawn hidden duplicate instances that quietly consume CPU and RAM. The problem is small in isolation but large in aggregate — especially for power users, IT professionals, and enterprise environments where Task Manager is a first‑line troubleshooting tool.

Background / Overview​

On October 28, 2025 Microsoft published the non‑security preview update identified as KB5067036, shipping OS builds 26200.7019 (25H2) and 26100.7019 (24H2). The update bundles a set of UI and functional changes — including Start menu refinements, taskbar/battery icon updates, File Explorer tweaks, and an explicit fix touching Task Manager’s process grouping behavior. The update is delivered as an optional preview and uses a staged rollout model: some devices receive features sooner than others.
Within hours of the release, users began reporting a startling behavior: when Task Manager is closed via the window “X” button, the window disappears but the process does not always terminate. Reopening Task Manager after this results in a new visible instance while previous taskmgr.exe processes continue running in the background. Repeating the open→close cycle multiplies these hidden instances. Community reproductions and independent tests show the orphaned processes persist until explicitly killed or until the machine is rebooted.
This is notable for two reasons. First, Task Manager is the canonical tool for diagnosing and terminating runaway software; a regression that causes it to leave behind hidden instances undermines its reliability. Second, even small per‑instance memory or CPU use can add up quickly: community tests observed roughly 20–25 MB of RAM per orphaned instance, and occasional small CPU polling, meaning dozens of orphaned copies can measurably affect system performance and battery life.

---

What exactly is happening?​

Symptom summary​

• Opening Task Manager (Ctrl+Shift+Esc) and closing it using the top‑right X sometimes tears down the UI while keeping the underlying taskmgr.exe process alive.
• Reopening Task Manager creates another visible instance; prior instances remain listed as running processes and accumulate.
• Orphaned instances appear under Background Processes and consume memory — small individually, but not insignificant when many accumulate.
• The issue has been reproduced on multiple machines but is not universal, suggesting environmental triggers or staged feature flags.

Confirmed technical details​

• The update in question is KB5067036, released October 28, 2025, for Windows 11 versions 24H2 and 25H2, builds 26100.7019 and 26200.7019.
• The KB explicitly lists Task Manager grouping fixes among its changes — the same area of the product where lifecycle and process‑group mapping were modified in this preview release.
• The package is delivered as a combined servicing stack + LCU in some distributions; removal semantics differ from a simple WUSA uninstall (see remediation steps below).

Note: a small number of other, scattered reports tied to this update mention installation failures or more severe outcomes. These claims are inconsistent and vary in detail; they should be treated as preliminary unless reproduced at scale or confirmed by vendor guidance.

---

Reproducing and Verifying the Problem (for technicians)​

If you’re verifying whether systems you manage were affected, use the following diagnostic checklist:

• Confirm the OS build:
• Press Win + R, type winver, and check the build string for 26100.7019 or 26200.7019.
• Reproduce the behavior:
• Open Task Manager (Ctrl+Shift+Esc).
• Click the Close (X) button.
• Reopen Task Manager and switch to the Processes tab. Expand “Background processes” and look for multiple taskmgr.exe entries.
• Inspect running processes:
• From PowerShell: Get-Process taskmgr
• From command prompt: tasklist | findstr taskmgr
• For deeper inspection, use Sysinternals Process Explorer to view handles, thread stacks and loaded DLLs for orphaned instances.
• Measure resource use:
• Note per‑instance memory (reported community tests ~20–25 MB each) and any sustained CPU usage. Multiply by the number of orphaned instances to estimate impact.

These steps let you determine whether a specific device is affected and provide the telemetry you’ll need for escalation or for filing a reproducible bug report.

---

Technical analysis: Why this likely occurred​

At a high level, the bug looks like a shutdown‑path regression introduced alongside a legitimate change to how Task Manager groups and reports apps with their processes. Modern Task Manager separates UI rendering from background sampling — UI threads render windows while background threads query performance counters and marshal data. A change in the grouping code could have altered object ownership, reference counts, or lifecycle ordering, producing one of these failure modes:

• A background monitoring thread or COM object retains a handle to a system resource, blocking the process from exiting cleanly even after the window is destroyed.
• The close handler or main message loop no longer posts the proper shutdown messages (WM_QUIT/WM_DESTROY) under certain conditions, leaving the process resident as a headless background task.
• Interaction with third‑party hooks, security software, or shell extensions causes the tear‑down to hang on a particular call path that only appears on some configurations.

These hypotheses align with observed behavior (UI gone, process still present, duplicates created on reopen). However, until Microsoft publishes a root‑cause analysis or a known‑issue statement that details the internal failure mode, this explanation remains the best‑fitted technical hypothesis rather than a confirmed fact.

---

Immediate mitigation and workarounds​

For affected users and admins, there are practical ways to control resource accumulation and restore normal operation until a formal patch arrives.

• Use Task Manager’s End task instead of clicking the X. From within Task Manager, right‑click the Task Manager entry and choose End task to terminate the process tree cleanly.
• Use a force kill in an elevated console: taskkill /im taskmgr.exe /f — this terminates all running Task Manager instances immediately.
• PowerShell alternative: Get-Process taskmgr | Stop-Process -Force
• If you prefer GUI alternatives for process inspection and termination, use Sysinternals Process Explorer — it does not appear to trigger the same duplication and gives better visibility into handles and threads.
• If the update proves disruptive at scale and a rollback is required:
• Windows Settings → Windows Update → Update history → Uninstall updates can remove certain packages, but be aware: the combined package may include an SSU (servicing stack update) that cannot be removed via WUSA. When necessary, use DISM to enumerate and remove the LCU package:
• DISM /online /get-packages — find the package name for the LCU.
• DISM /online /Remove-Package /PackageName:<name> — removes the LCU.
• Do not rely on a simple wusa /uninstall for combined SSU+LCU packages; the KB’s removal guidance should be consulted before wide rollback.
• Rebooting clears orphaned instances; plan reboots if resource accumulation becomes problematic.

These mitigations are effective stopgaps but introduce friction — especially when taskkill or reboots interrupt diagnostic workflows.

---

Guidance for enterprise IT and administrators​

This kind of regression, small per incident but high risk in aggregate, calls for measured operational responses:

• Pause optional preview updates for production fleets. Preview non‑security updates are designed for telemetry and early testing — they are not intended for broad production deployment.
• Use phased pilot rings. Limit early adopter or preview update exposure to a small, instrumented pilot group (helpdesk, QA, development) and expand only after the pilot shows no regressions.
• Update deployment controls:
• For Microsoft Intune and Configuration Manager (SCCM), use ring deployment and deadlines to prevent optional preview content from landing on critical endpoints.
• In WSUS environments, decline or withhold preview KBs until Microsoft confirms stability.
• Create monitoring and alerting for process anomalies. Detect repeated taskmgr.exe instances, rising memory footprints, or repeated taskkill events and surface those to the helpdesk automatically.
• Document and communicate workarounds inside IT runbooks. Provide helpdesk scripts that run taskkill /im taskmgr.exe /f or an automated remediation package via SCCM to clear orphaned processes if a user reports slow performance.
• Collect forensic traces from affected machines (ProcMon logs, ETW process create/exit traces, Process Explorer dumps) to create reproducible bug reports for Microsoft and to pinpoint environmental triggers (drivers, AV, shell extensions).

An enterprise posture that treats optional preview updates like feature‑flagged experiments reduces blast radius when regressions appear.

---

Broader implications: update strategy, QA, and user trust​

This incident highlights a perennial tension in modern OS development: the push to iterate and ship improvements quickly versus the need to preserve stability for millions of users. Preview and optional update channels are intended to surface regressions before wide release, but the reality is that:

• Preview updates will sometimes introduce regressions that escape internal QA and appear only in diverse real‑world environments.
• Changes that touch shared subsystems (process lifecycle, performance counters, UI grouping) can have ripple effects far beyond the feature being tweaked.
• Small, usability‑level regressions can become high‑impact operational problems in large organizations, where repeated manual actions (opening Task Manager dozens of times a day during diagnostics) can multiply the defect’s impact.

For Microsoft and other platform vendors, the challenge is to maintain robust telemetry and quicker turnaround for fixes while preserving a stable channel for production users. For IT leaders, the lesson is to adopt conservative update policies for mission‑critical endpoints and to treat preview releases as testable artifacts rather than automatic improvements.

---

Risk assessment and what to watch for​

• Performance impact: While a single orphaned taskmgr.exe process uses modest memory, multiple accumulated instances can consume hundreds of megabytes of RAM and small but continuous CPU polling. On low‑memory devices or systems under heavy diagnostic load, measurable slowdowns and battery drain can occur.
• Unclear trigger set: The issue is not universal; variability suggests environmental triggers such as third‑party software, drivers, or server‑side gated features. That makes preemptive identification harder and increases the need for targeted telemetry.
• Reproducibility: Community reproductions show the bug reliably on some machines and not at all on others. For trustworthy remediation, IT teams should capture system state and reproducible logs before applying removals or filing a support case.
• Confounding reports: There are scattered, unverified user claims concerning installation failures or severe side effects. These reports should be flagged and investigated but treated with caution unless confirmed by vendor statements or reproducible lab tests.

Flagging uncertain claims explicitly prevents overreaction while ensuring that potential high‑severity outcomes receive scrutiny.

---

What Microsoft can and should do​

From an industry best‑practice perspective, vendor response should include:

• Official acknowledgement on the update KB or the Windows Release Health dashboard once a regression is validated.
• A clear guidance note describing affected builds, reproducible steps, recommended workarounds, and removal instructions.
• An expedited patch or out‑of‑band update addressing the process shutdown regression, especially when the bug undermines a core diagnostic tool.
• Post‑mortem details when feasible — what change introduced the regression (task grouping refactor, threading change, handle lifetime) and how it will be prevented in the future.

Fast, transparent vendor communication reduces alarm, helps administrators make informed decisions, and accelerates remediation across the installed base.

---

Practical checklist for home users and power users​

• If you’re not on the Insider or preview track, you can safely defer optional preview updates. By default, preview updates are optional and can be skipped until fixes are validated.
• If you installed KB5067036 and notice multiple Task Manager entries:
• Avoid closing Task Manager with the X. Use End task or taskkill /im taskmgr.exe /f.
• Reboot to clear state if processes accumulate.
• Use Process Explorer for deep inspection and to confirm what each orphaned instance has loaded.
• If you need immediate stability, consider uninstalling the preview update following the KB’s removal guidance — be careful with combined SSU+LCU semantics.
• Create a recovery plan: before experimenting with optional updates, keep a current system image or a recovery USB to restore a working state quickly.

---

Historical context: not the first Task Manager regression​

This is not the first time Task Manager has shown odd behavior after a servicing change. An October 2024 preview (KB5044384) produced a different Task Manager regression — it incorrectly displayed zero counts for Apps, Background Processes, and Windows Processes when “Group by Type” was enabled. That issue was acknowledged and later addressed in follow‑up updates. These precedents demonstrate both the recurrence of Task Manager regressions after servicing changes and Microsoft’s capacity to remediate once issues are validated.

---

Conclusion​

KB5067036’s Task Manager regression is a classic case study in modern platform maintenance: a targeted functional change — improving process grouping — appears to have inadvertently broken lifecycle behavior for the Task Manager process under certain conditions. The bug converts a core diagnostic tool into a potential source of resource bloat, with consequences that scale depending on how often Task Manager is used.
Until Microsoft issues a fix or a formal acknowledgement, the pragmatic approach for end users and IT organizations is clear: avoid optional preview updates on production devices, carry out targeted verification on pilot machines, apply the simple workarounds (End task or taskkill) to mitigate resource accumulation, and prepare rollback/remediation plans that respect the combined package semantics of modern servicing models.
This incident reinforces an unglamorous truth about large, widely distributed operating systems: even carefully curated preview channels cannot eliminate regressions entirely. Robust rollback plans, staged deployment practices, and clear communication channels remain the essential defenses against the inevitable unexpected behavior that accompanies continuous innovation.

---

Source: WebProNews Windows 11 KB5067036 Bug: Task Manager Spawns Hidden Duplicates on Close

Microsoft’s latest optional preview has quietly turned a maintenance tool into a resource leak: closing Task Manager with the window “X” can leave the process running, and each reopen spawns another background copy of taskmgr.exe that quietly consumes RAM and occasional CPU until explicitly killed.

Background / Overview​

KB5067036 is an optional, non‑security preview cumulative update for Windows 11 that Microsoft published as part of a staged rollout in late October 2025. The package updates Windows 11 to OS build 26200.7019 (25H2) and 26100.7019 (24H2) and bundles a handful of visible UI changes—most notably a redesigned Start menu and refreshed taskbar battery icons—alongside several under‑the‑hood fixes, including one explicitly touching Task Manager’s process‑grouping logic.
Within days of the preview’s release users, forum participants, and multiple independent outlets reproduced a surprising regression: clicking the Task Manager close button (the top‑right “X”) does not always terminate the program, and repeated open→close cycles leave behind multiple taskmgr.exe processes that show up in process lists and consume resources. This is not a cosmetic duplicate; these are distinct processes visible to Process Explorer, tasklist, and PowerShell’s Get‑Process.

---

What users are seeing: symptoms and reproduction​

Simple, repeatable steps​

• Press Ctrl+Shift+Esc (or otherwise start Task Manager).
• Click the top‑right Close (X) control to dismiss the window.
• Reopen Task Manager and inspect Processes (expand Background processes if needed).

If affected, each open→close cycle increases the number of “Task Manager” entries. The orphaned entries typically appear under Background processes, which makes them easy to miss if you focus only on the top‑level Apps list.

Measured impact (community and independent testing)​

• Per‑instance memory usage is modest: community tests cluster around 20–30 MB per orphaned taskmgr.exe, which makes the issue invisible initially but significant after many repeats. One contrived stress test reported roughly 2 GB of RAM consumed after ~100 open/close cycles.
• CPU use per orphaned instance is usually very small at idle, but periodic polling spikes have been observed—reports vary from nearly 0% up to ~1.5% per instance during sampling. Aggregated across many instances this can produce measurable CPU pressure and battery drain on laptops.

Where it shows up​

• The leftover processes are visible to:
• Task Manager → Details tab
• Sysinternals Process Explorer
• tasklist and PowerShell Get‑Process outputs
  This confirms the problem is at the OS/process level, not merely a UI refresh artifact.

---

Why this likely happened (technical hypotheses)​

The update’s release notes specifically mention a fix for Task Manager’s process grouping, which indicates internal changes to how Task Manager maps UI items to underlying process objects. Task Manager is not a single‑threaded UI toy: it combines a rendering/UI thread with background sampling threads, performance counter readers, and registered COM callbacks. Changes to grouping semantics can inadvertently affect reference counting, handle lifetimes, or teardown ordering.
A plausible, evidence‑backed hypothesis:

• The close (WM_CLOSE → WM_DESTROY) path for Task Manager no longer fully releases a background object (a timer, COM object, performance counter handle, or worker thread).
• With references held, the process cannot exit even after its visible window is destroyed.
• Launching Task Manager again spawns a new process that creates another set of sampling threads while the prior instance remains resident, producing multiple taskmgr.exe entries.

This lifecycle/regression class is common when UI code and background services are modified in the same change set: a seemingly local fix to grouping logic can accidentally change object ownership semantics and prevent a clean exit sequence. The hypothesis matches observed behavior and the KB notes, but the exact root cause remains unconfirmed by Microsoft at the time of reporting. Treat the technical explanation as plausible but not authoritative until vendor engineering publishes a post‑mortem.

---

Cross‑checks and verifiable facts​

• Microsoft released KB5067036 as a preview update on October 28, 2025, delivering OS builds 26200.7019 and 26100.7019. This is documented in the KB metadata and repeated across independent reporting.
• Multiple reputable outlets and community threads reproduced the orphaned Task Manager instances and measured the per‑instance memory consumption in the 20–30 MB range. These independent reproductions corroborate the basic resource‑leak claim.
• The bug is not universal—some systems with the preview behave normally. Variability suggests environment‑specific triggers (driver interactions, third‑party hooks, staged feature flags, or OEM modifications). This pattern is consistent with staged rollouts and preview updates.

Important caution: a few outlets and posts provide precise CPU percentages per orphaned instance (for example, a claimed 0.9% per tskmgr.exe), but those figures vary between reports and depend heavily on sampling methodology, machine load, and how long an instance runs. Those specific per‑instance CPU numbers should be treated as observation, not definitive attribution, unless reproduced in a controlled lab with instrumentation. Flag any single precise CPU claim as unverified unless it’s supported by reproducible telemetry.

---

Practical mitigation: immediate workarounds that work now​

Because the orphaned taskmgr.exe instances are in‑memory processes, they do not survive a reboot. Until Microsoft issues a fix, the following mitigations will clear or avoid accumulation:

• Use Task Manager’s built‑in controls instead of the window Close (X):
• Open Task Manager → right‑click the Task Manager entry → End task. This reliably terminates the process.
• Kill all Task Manager instances from an elevated command prompt:
• Run as Administrator: taskkill /im taskmgr.exe /f — this forcibly terminates every taskmgr.exe instance in memory. This command is blunt but effective.
• Use PowerShell as an alternative:
• Elevated PowerShell: Get-Process -Name taskmgr | Stop-Process -Force to stop all copies programmatically.
• Reboot the PC to clear lingering instances when convenient.
• If the preview update is unacceptable for production work, uninstall KB5067036 using Settings → Windows Update → Update history → Uninstall updates, or follow your organization’s update‑rollback procedures. Note: combined SSU/LCU packages have specific uninstall constraints; consult your update management practice before wide rollbacks.

These mitigations address the symptom; they do not fix the underlying teardown logic. For any system where Task Manager is a core troubleshooting tool or where helpdesk workflows repeatedly open/close Task Manager, avoid installing the optional preview on production devices until Microsoft confirms a patch.

---

Risk and impact analysis​

Home and casual users​

Most casual users will never notice the issue. If Task Manager is opened infrequently and machines are rebooted regularly, the likelihood of building up many orphaned instances is low. The small per‑instance memory footprint means short sessions will remain unaffected in practice.

Power users, developers, and IT pros​

These groups are at highest risk: they routinely open/close Task Manager dozens or hundreds of times per day as part of diagnostics and will see resource creep quickly. Helpdesk and debugging workflows that open Task Manager repeatedly can accumulate dozens of orphaned instances and hit responsiveness or battery life.

Laptops and low‑RAM systems​

Devices with limited RAM or constrained battery budgets will feel the impact sooner because even modest memory and CPU aggregation forces paging, increased disk I/O, and higher power draw from periodic sampling spikes.

Enterprise fleets and managed environments​

Preview updates exist to surface exactly this kind of environmental regression before broad distribution. Deploying optional previews widely in production was always discouraged; this regression reinforces that policy. Administrators should treat KB5067036 as a pilot/ring candidate only and block it from broad rollout until Microsoft publishes a fix or a known‑issue entry for Task Manager lifecycle problems. Collect reproducible diagnostics (ProcMon traces, ETW, tasklist/Get‑Process outputs, and winver) and file Feedback Hub or a Microsoft support case if the issue affects production endpoints.

---

Forensics and troubleshooting guidance for advanced users​

If you need to collect evidence for a support case or to speed a root‑cause analysis:

• Capture process lifetime traces with ETW/procmon filtering on taskmgr.exe.
• Use Process Explorer to inspect thread stacks and active handles for orphaned taskmgr.exe instances.
• Record tasklist or Get-Process outputs before and after open/close cycles (include PID, memory, CPU, and loaded modules).
• Reproduce the issue with minimal third‑party software running; test in Safe Mode and on a clean image to isolate driver/OEM factors.
• Record winver and the exact OS build (26100.7019 / 26200.7019 are known impacted preview builds).

Providing these artifacts to Microsoft will accelerate triage if you file a support case or submit a detailed Feedback Hub report.

---

What Microsoft (and vendors) should do next​

• Publish an explicit known‑issue entry or KB update acknowledging the Task Manager close‑path regression, including guidance for affected users and administrators.
• Prioritize a targeted fix that restores correct teardown of Task Manager background objects while preserving the intended process‑grouping improvements.
• For staged rollouts, enhance preview telemetry for lifecycle events (open/close) of system utilities to detect regressions early.
• OEM and driver teams should review their hooks that interact with Task Manager (shell integrations, performance counters, diagnostic utilities) to ensure they’re not exacerbating the condition on specific hardware.

Given the reproducible nature of the issue and that the change set explicitly modified Task Manager internals, a narrow, surgical fix to the teardown path is the most likely remediation route. Historically Microsoft has patched similar preview regressions quickly once confirmed and prioritized.

---

Recommended actions for readers (quick checklist)​

• Avoid installing optional preview updates like KB5067036 on production devices unless you are in a pilot ring.
• If you already installed KB5067036 and see duplication:
• Use Task Manager’s End task control rather than the window X.
• Or run taskkill /im taskmgr.exe /f from an elevated Command Prompt to remove all instances at once.
• Collect diagnostic traces (ProcMon, ETW) if you plan to open a Microsoft support case.
• Reboot periodically if you must continue using the preview on a device where the bug impacts workflow.
• Report your findings via Feedback Hub to increase visibility and prioritize a fix.

---

Strengths, weaknesses, and wider implications​

Strengths of Microsoft’s rollout model​

• Staged previews and optional updates let Microsoft test changes in a controlled way and expose environment‑specific regressions before wider distribution. The preview channel has done its job here by catching a lifecycle regression prior to broader release.

Weaknesses exposed​

• Preview changes that touch core utilities can have outsized operational impact. Task Manager is a trust anchor for troubleshooting; regressions in such utilities amplify support load and reduce confidence in preview cadence.
• The variability of impact across devices underscores the complexity of Windows’ hardware and software ecosystem: small changes can interact with OEM drivers, third‑party tools, and telemetry flags in surprising ways.

Wider implications for IT and support teams​

• This incident is a textbook reminder to maintain conservative deployment rings for even minor optional updates.
• It also highlights the need to gather reproducible telemetry and to automate lifecycle tests (launch → close → reopen) for system utilities as part of validation suites.

---

Conclusion​

The KB5067036 preview produced a surprising and practically meaningful regression: Task Manager’s close button can fail to terminate the app and repeated open/close cycles spawn multiple taskmgr.exe processes that quietly consume RAM and occasional CPU. Multiple independent reproductions and community tests confirm the phenomenon and show that per‑instance memory usage typically sits in the low tens of megabytes while CPU spikes are small but aggregate over many instances. Practical mitigations—End task, taskkill, reboot, or uninstall of the preview—are available now, and administrators should treat this update as a pilot‑only candidate until Microsoft issues a correction.
This bug is a reminder that even the most mundane system utilities deserve rigorous lifecycle testing: when a utility meant to diagnose problems becomes part of the problem, trust and productivity suffer disproportionately. The fix is most likely to be surgical and focused on Task Manager teardown logic, but until Microsoft confirms a root cause and ships a patch, the mitigations above are the practical defense for power users, IT teams, and anyone who relies on Task Manager for troubleshooting.

---

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

Microsoft has confirmed that an optional Windows 11 preview update (KB5067036) can leave Task Manager processes running after you close the window — producing multiple background taskmgr.exe instances that can potentially degrade device performance until they are terminated or the system is rebooted.

Background / Overview​

KB5067036 was published as an optional, non‑security preview cumulative update for Windows 11 on October 28, 2025, and it updates systems to OS builds 26200.7019 (25H2) and 26100.7019 (24H2). The package bundles visible UI changes (including a refreshed Start menu and updated taskbar battery icons) along with a set of under‑the‑hood fixes — specifically a change intended to improve Task Manager’s process‑grouping behavior.
Preview updates are delivered as optional packages to gather broader field telemetry before wider distribution. That staged rollout model means some fixes or features are enabled gradually or server‑side, and not all devices see the same behavior at the same time. That variability likely explains why the Task Manager symptom is reproducible on many installs but not universal.

---

What happened: the Task Manager close‑path regression​

Shortly after KB5067036 shipped, multiple independent testers and publications reproduced the same odd behavior: when you close Task Manager using the window Close button (the “X”), the visible window may disappear while the taskmgr.exe process remains running in memory. Reopening Task Manager then spawns another live taskmgr.exe process, so repeated open→close cycles accumulate multiple background Task Manager processes.
Microsoft has acknowledged the behavior, telling reporters that the lingering instances “consume system resources and potentially degrade device performance.” That admission confirms the symptom is genuine and not merely a UI artifact.

The observable pattern​

• Open Task Manager (Ctrl+Shift+Esc).
• Close it using the top‑right Close (X) button.
• Reopen Task Manager and check Processes → Background processes: additional “Task Manager” (taskmgr.exe) entries appear.
• Repeat the open→close cycle and the count can increase each time until you explicitly kill the orphaned processes or reboot.

---

How bad can it get? Performance and resource impact​

The impact depends on two variables: how often Task Manager is opened and closed and the baseline system resources (RAM, CPU, and power profile). Community reproductions and hands‑on tests commonly report per‑instance RAM usage in the ~20–30 MB range; small by itself but additive when dozens or hundreds of orphaned instances accumulate. Several testers performed stress runs (dozens to hundreds of open/close cycles) to demonstrate multi‑gigabyte accumulation on heavily exercised systems.

• On a 32 GB machine, tens of lingering Task Manager instances may be negligible.
• On low‑RAM laptops, virtual machines, or battery‑sensitive devices, dozens of orphaned processes can push the system into swap, produce UI stutters, slow app launches, and increase battery drain.

Microsoft notes the typical impact of a few Task Manager processes is minimal, but the vendor explicitly warns that many accumulated instances can meaningfully slow other apps and affect device performance. That matches the independent observations.

---

Who is most at risk?​

• Power users, developers, and sysadmins who frequently open Task Manager for diagnostics are most likely to notice the problem because their workflows repeatedly open and close the tool.
• Low‑RAM systems and older laptops will hit performance pain points faster as orphaned RAM usage compounds.
• Managed enterprise fleets are exposed operationally if preview updates are deployed outside pilot rings, because help desks may see an uptick in incidents and remediation work. Treat optional previews as test artifacts for pilot rings, not for broad production installs.

---

How to verify whether your PC is affected​

• Press Win+R, type winver, and confirm your OS build (look for 26200.7019 or 26100.7019 if KB5067036 is installed).
• Open Task Manager (Ctrl+Shift+Esc). Close it with the Close (X) button.
• Reopen Task Manager and switch to Processes → Background processes. If the number of Task Manager entries increases each time you repeat open→close, your device demonstrates the issue.

Alternative checks from an elevated shell:

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

If multiple taskmgr.exe entries appear, those are active processes and need to be terminated to reclaim memory.

---

Immediate mitigations and safe workarounds​

There is no single “fix” until Microsoft ships a corrective package, but practical containment steps work reliably:

• Use Task Manager’s End task option (right‑click the Task Manager entry in Processes) to terminate it cleanly instead of clicking Close (X). This avoids leaving the process resident.
• Kill all Task Manager instances in one command from an elevated prompt:
  taskkill.exe /im taskmgr.exe /f
  This forcibly terminates every running taskmgr.exe process.
• PowerShell alternative: Get-Process -Name taskmgr | Stop-Process -Force.
• Reboot to clear accumulated orphaned instances when convenient — these processes are in‑memory only and do not survive a restart.
• If you do not need the preview features, uninstall KB5067036 (Settings → Windows Update → Update history → Uninstall updates). Note that combined servicing packages (SSU + LCU) can have complex uninstall semantics; follow guidance before rolling back at scale.

For managed fleets, deploy a simple detection/remediation script (e.g., check for >1 taskmgr.exe and run taskkill) via your management tooling until a vendor fix is available.

---

What Microsoft has said (and what that means)​

Microsoft acknowledged that when the Task Manager close button fails to terminate the process, it results in multiple lingering taskmgr.exe instances that “consume system resources and potentially degrade device performance.” That direct acknowledgement elevates the issue from a rumor to an official regression under investigation.
As of the initial acknowledgement, Microsoft had not (publicly) posted a dedicated “known issue” block in the KB entry with a timeline for a hotfix, and the company has not stated whether an out‑of‑band patch will be issued specifically for Windows 11 25H2 / 24H2 recipients of KB5067036. That leaves mitigation guidance and the community’s containment steps as the practical short‑term pathway for affected users and support teams.

---

Technical analysis: why this likely happened​

KB5067036 explicitly included a change intended to improve Task Manager’s process grouping logic — code that maps UI rows to underlying processes and attaches app entries to process trees. Lifecycle regressions of this kind commonly occur when a background sampling thread, timer, COM callback, or handle is not released correctly during the window close (WM_CLOSE → WM_DESTROY) sequence. If such a reference remains, the process cannot exit even when its visible window is destroyed; subsequent Task Manager launches create new processes, leading to duplicates.
This explanation is a well‑fitted hypothesis supported by the symptoms and the KB’s stated changes, but it is not a vendor‑confirmed root cause. Definitive identification requires ETW traces, ProcMon captures, and Process Explorer thread stacks to reveal the exact retained object or handle. Until Microsoft publishes a post‑mortem or fix notes, consider this a plausible technical hypothesis rather than a proven diagnosis.

---

Broader quality and servicing lessons​

This incident underlines recurring realities about OS servicing:

• Preview updates surface edge cases: Optional preview packages exist precisely to let the field catch rare regressions before broader distribution. That benefit comes with the cost that some pilot users will encounter problematic behavior.
• Small UI changes can cascade: A localized improvement (process grouping) can ripple into lifecycle and teardown behavior for commonly used utilities like Task Manager. Lifecycle testing (open/close/exit sequences) is critical.
• Staged rollouts complicate root‑cause correlation: Server‑side gating and environment‑specific triggers mean not every device will reproduce the issue, which slows telemetry correlation and triage.

Administrators should treat optional preview updates as test artifacts for pilot rings, include troubleshooting tools in acceptance tests, and be prepared to withhold or roll back optional previews for production devices. For home power users, the simplest rule is: if stability matters more than the preview features, skip optional updates until the vendor confirms fixes.

---

Recommendations — practical, prioritized steps​

• Pause deployment: Stop broad rollout of KB5067036 on production endpoints until Microsoft confirms a fix. Use Windows Update for Business, WSUS, or your RMM solution to enforce delays.
• Detect and remediate: Push a temporary script that checks for multiple taskmgr.exe instances and runs taskkill /im taskmgr.exe /f on affected clients. Report detections for trend analysis.
• Educate users: Tell help‑desk teams and power users to avoid using the Close (X) for Task Manager and to use End task or taskkill instead.
• Collect artifacts for support: If you need to escalate to Microsoft, capture winver, ProcMon traces filtered for taskmgr.exe, Process Explorer thread stacks, and a short recording of the open→close→reopen reproduction. Those artifacts materially speed vendor triage.
• Reboot policy: If many orphaned instances accumulate and performance degrades, schedule a restart to clear them until a patch is delivered.

---

Claims to treat cautiously or as unverified​

• Headlines suggesting hundreds of thousands of machines are affected are not substantiated by vendor telemetry published publicly; community reproductions show the problem is real but not universal. Treat magnitude claims as unverified until Microsoft shares telemetry.
• Suggestions that Microsoft intentionally fails to warn users about optional updates are opinion‑based; the company does label preview updates as optional and staged, but how clearly that is communicated to end users varies and should not be asserted without vendor policy citations. Flag any broad claims about intent as speculative.

---

What to expect next​

Historically, Microsoft has issued targeted fixes for high‑impact regressions found in preview releases once telemetry and reproducible reports accumulate. Given Task Manager’s central role and the repeatable evidence surfaced by community testing, a corrective update — either in a subsequent cumulative update or an out‑of‑band patch — is the most likely outcome. Meanwhile, expect Microsoft’s Release Health and KB pages to be the authoritative channels for a formal known‑issue entry and remediation timeline.

---

Conclusion​

The KB5067036 Task Manager regression is a practical reminder that even the most mundane OS utilities require robust lifecycle testing. The bug turns a core troubleshooting tool into a potential source of resource bloat when the close button fails to terminate its process. The immediate path to stability is straightforward: avoid closing Task Manager with the Close (X), use End task or force‑kill lingering taskmgr.exe instances with taskkill, pause optional preview rollouts on production devices, and collect diagnostics to speed vendor triage. Microsoft’s admission that lingering taskmgr.exe instances can “potentially degrade device performance” turns a noisy community bug into an acknowledged regression — now the onus is on vendor engineering to release a surgical fix and on administrators to keep pilot rings protected while that work completes.

---

Source: Windows Latest Microsoft confirms Windows 11 Task Manager bug is potentially degrading performance