• Thread Author
ExplorerPatcher’s latest release finally restores several long-broken customizations for Windows 11 24H2 and includes a practical — if controversial — workaround that lets the utility avoid the upgrade safeguard that Microsoft introduced for 24H2 builds. The update, published as release 22631.5335.68.2, re-enables the Simple Window Switcher (SWS), fixes the “disable rounded corners” regression, expands taskbar and ARM64 support, and renames a helper binary to sidestep Microsoft’s compatibility checks — changes that make Windows 11 24H2 installable again for some users who were previously blocked. (github.com) (neowin.net)

Futuristic cyber scene with an ExplorerPatcher overlay, glowing Start menu, and an 'Upgrade Block Bypassed' sign.Background​

Windows customization tools such as ExplorerPatcher have long been the go-to solution for users who prefer a more classic taskbar and Start experience, or who want to remove design decisions introduced in recent Windows 11 feature updates. Microsoft’s Windows 11 24H2 introduced internal changes that caused several ExplorerPatcher features to break, and Microsoft also took steps that prevented machines with known UI-modifying utilities from upgrading cleanly to some 24H2 builds. ExplorerPatcher’s maintainers responded with a substantive update that both adapts to the internal API changes and changes how one of its helper components is named and registered — effectively bypassing the upgrade guard that was preventing a subset of users from downloading or installing 24H2. (neowin.net)
This story matters because it sits at the intersection of user customization, system stability, and platform security policy. The update is technically proficient and user-focused, but it also raises hard questions about long-term compatibility, security, and what it means when third-party tools alter or patch system components.

Overview of the release: what changed in 22631.5335.68.2​

The official release notes (public GitHub release 22631.5335.68.2) list multiple fixes and feature restorations. Key items include:
  • sws (Simple Window Switcher): Added support for Windows 11 24H2, addressing performance regressions and hangs that had been reported by power users. (github.com)
  • ep_dwm: Added support for 24H2 and the helper binary ep_dwm.exe was renamed to ep_dwm_svc.exe to bypass upgrade blocks. The release also notes that ep_dwm is now always unregistered on uninstallation. (github.com)
  • “Disable rounded corners” option fixes so the setting no longer unchecks itself after Explorer restarts on specific 24H2 builds — a much-requested fix. (neowin.net)
  • Taskbar fixes: Multiple taskbar-related fixes, ARM64 support, localization improvements, and fixes for DPI and hotkey behavior. EP’s taskbar implementation was marked compatible again with 24H2 and several Windows 10/11 builds. (github.com)
  • Setup and robustness improvements: More helpful failure messages (line-number diagnostics), safer uninstall behavior for components, and file-packing improvements for the installer. (github.com)
Those are the high-level items; the release notes provide a detailed changelog for advanced users and testers. The project explicitly labels this build as a pre-release and includes warnings about antivirus false positives and the general risk of using taskbar replacements on mission-critical systems. (github.com)

How the 24H2 “upgrade block” worked — and what ExplorerPatcher did​

Microsoft’s safeguard​

When Windows 11 24H2 started rolling out, Microsoft added compatibility checks that could block systems from upgrading if modifications to critical UI components were detected. The intent, based on Microsoft’s public guidance and community reporting, was to prevent unstable or unsupported modifications from causing failed upgrades or leaving systems in inconsistent states after a feature update. These checks flagged aftermarket shell or shell-adjacent modifications, including some ExplorerPatcher binaries. Community coverage documented instances of systems not being offered the 24H2 upgrade because of those third-party customizers. (neowin.net)

ExplorerPatcher’s technical workaround​

Rather than removing the functionality, the ExplorerPatcher developer changed the implementation so the component that was being flagged would no longer trigger the same block. Concretely, the release renames ep_dwm.exe to ep_dwm_svc.exe and adjusts registration behavior so the helper is unregistered on uninstall; the release notes describe this as a method to “get around 24H2 upgrade blocks.” On GitHub the release explicitly lists the rename and the registration/unregistration changes as part of the 22631.5335.68.2 update. (github.com)
This is a surgical fix: rename and behavior changes to avoid a compatibility filter that checks filenames, registry entries, or active module registrations. The result is practical — it makes 24H2 upgrades possible for users who rely on ExplorerPatcher — but it also moves the conflict into a policy space where Microsoft and third-party developers are implicitly negotiating via engineering tricks rather than coordinated compatibility support.

What this means for users: features restored and new capabilities​

Restored and improved features​

  • Simple Window Switcher (SWS): After reports of high CPU use, slowdowns, and hangs, SWS has been reworked for 24H2 compatibility. Power users who prefer an alternative Alt-Tab experience will likely see reduced lag and fewer corner-case failures. (neowin.net)
  • Disable rounded corners: The setting that reverts application window corners back to sharp edges has been corrected and no longer deactivates itself after Explorer restarts on patched 24H2 builds. This closes a prominent user complaint that surfaced after the 24H2 rollout. (neowin.net)
  • Taskbar behaviour and ARM64 support: The EP taskbar now supports the Windows 11 24H2 code paths more broadly, with ARM64 builds included and multiple localization additions. Hotkey and DPI behavior issues have been patched. (github.com)

Usability additions​

  • Installer improvements: Better diagnostics for install failures (line-number output) make troubleshooting easier for advanced users. The installer also includes updated unpacking behavior to reduce failures caused by locked files. (github.com)

Risks, trade-offs, and long-term considerations​

ExplorerPatcher’s update is pragmatic and technically impressive, but the approach carries non-trivial risks that users — particularly IT admins and less technical users — should weigh carefully.
  • Security and support posture: ExplorerPatcher modifies and in some cases patches system components at runtime. That behavior can look similar to malicious techniques used by exploit code or cheats, and historically antivirus products (including Microsoft Defender) have produced false positives against ExplorerPatcher builds. GitHub’s release page explicitly warns about potential Defender flags and advises adding exclusion paths to avoid install/uninstall breakage. Running such a tool increases attack surface and complicates vendor support scenarios. (github.com)
  • Stability and update fragility: Any time you patch Explorer or twinui-related binaries, future Windows updates can break the tool or cause Explorer to fail to start. ExplorerPatcher has repeatedly patched itself quickly in response to breaking Microsoft changes, but relying on a community project for continued compatibility introduces operational fragility. Enterprises should not deploy ExplorerPatcher on mission-critical machines without thorough testing. (github.com)
  • Policy vs. engineering workaround: The rename of ep_dwm.exe to ep_dwm_svc.exe is effective, but it’s a workaround rather than a formal compatibility agreement with Microsoft. That means Microsoft could (and may) change its detection heuristics, licensing, or enforcement measures, at which point ExplorerPatcher would either need a new workaround or lose functionality. This dynamic creates an unstable baseline for long-term deployment. (neowin.net)
  • Legal and enterprise governance: Organizations must consider corporate policy and compliance when choosing to run tools that replace or patch shell components. That includes support contracts, auditability, and risk assessments. ExplorerPatcher’s open-source status helps transparency, but it’s not the same as first-party support from Microsoft.

Practical installation and safety checklist (for enthusiasts and power users)​

If you decide to test or adopt this release, follow a conservative, repeatable process:
  • Back up system state and create a recovery point (System Restore) or full image backup.
  • Test in a virtual machine or a spare device running the identical Windows 11 24H2 build you plan to use.
  • Download the release assets from the official ExplorerPatcher GitHub release (22631.5335.68.2). Note: the release is marked pre-release; decide whether you want pre-release code on main systems. (github.com)
  • Add Defender exclusions before installation to reduce risk of deletion or quarantine during setup. Suggested paths (published by the project) include:
  • C:\Program Files\ExplorerPatcher
  • %APPDATA%\ExplorerPatcher
  • (the release notes include a recommended PowerShell snippet to add these exclusions). (github.com)
  • Install and verify that Explorer launches and the desired EP options (SWS, disable rounded corners, taskbar settings) work.
  • If any instability occurs, uninstall using EP’s uninstall option; the release notes state ep_dwm is always unregistered on uninstallation now. Test uninstall paths to ensure Explorer recovers. (github.com)
Numbered uninstall steps (recommended):
  • Open ExplorerPatcher settings and perform a graceful uninstall.
  • If Explorer does not recover, sign out and sign back in, or reboot.
  • If Explorer fails to start, use Safe Mode or an administrative PowerShell session to remove the installed EP files and restore from backup.

Alternatives and defensive options​

For users who want similar visual customization without deep system patching, consider these alternatives:
  • Paid, supported Start/taskbar editors such as Start11 (from Stardock) provide a commercial support channel and avoid many low-level system patches.
  • Built-in Windows personalization options can remove some friction (taskbar left alignment, icon spacing, Start > Folders), but they cannot fully replicate the Windows 10 shell behavior.
  • If you must use ExplorerPatcher, restrict it to non-essential machines or test rings until you are comfortable with the update cadence.
Community threads and reports emphasize that some users tolerate the occasional breakage in exchange for regained functionality — but that’s a personal and organizational trade-off.

Technical deep dive: ep_dwm, SWS, and taskbarDLLs​

ep_dwm / ep_dwm_svc​

The ep_dwm component interacts with Desktop Window Manager (DWM)-adjacent features. The rename to ep_dwm_svc.exe is primarily a compatibility dodge that prevents the upgrade guard from detecting the component in its old form. The release also ensures the component is unregistered during uninstall, which reduces the chance of residual registered components interfering with future upgrades or leaving orphaned registrations. That change improves cleanup reliability, but it doesn’t obviate the broader risk of modifying compositor-related behavior. (github.com)

SWS (Simple Window Switcher)​

SWS is an alternate Alt-Tab implementation. On 24H2, subtle changes in window enumeration and z-order handling produced severe performance regressions for SWS; the update revises the internal window iteration and event handling to match 24H2’s updated window management semantics, which reduces high CPU usage and eliminates infinite-loop conditions reported by users. For users who juggle many windows, SWS is now again a viable alternative to the stock Alt-Tab flow. (neowin.net)

ep_taskbar and taskbar DLLs​

EP’s taskbar implementation is modular and includes alternate DLLs for different Windows builds and architectures (for example, ep_taskbar.2.amd64.dll and ep_taskbar.5.dll for 24H2-specific handling). The release reintroduces taskbar DLLs in the setup and documents steps for users who need to manually install specific taskbar DLLs for particular builds. The project warns that running a Windows 10-style taskbar on production machines remains risky because Microsoft may remove legacy code paths from explorer.exe without notice. (github.com)

Verification and cross-checks​

The key factual claims in this piece were cross-checked against the ExplorerPatcher project’s official release notes published on GitHub and the independent reporting and community coverage that documented both the breakage and the workaround:
  • The GitHub release 22631.5335.68.2 contains the changelog that lists SWS and ep_dwm support for 24H2, the rename to ep_dwm_svc.exe, and the warnings about antivirus detection and stability. (github.com)
  • Independent coverage and community discussion captured the user-visible symptoms (broken rounded-corner toggle, SWS slowdowns, Microsoft upgrade blocks) and corroborated the release’s stated fixes. Community forum threads and news reporting documented both the upgrade block and the practical outcomes of the new release. (neowin.net)
Where claims were solely based on user-reported behavior (for example, precise frequency of Defender false positives across all telemetry), those remain community observations rather than quantified measurements and are noted as such.

Recommendation: who should install, and who should wait​

  • Installers likely to benefit immediately:
  • Enthusiasts who rely on specific EP features (SWS, disable rounded corners, Windows 10 taskbar emulation) and who understand the risks.
  • Testers who can validate EP behavior in a VM or non-critical device. (github.com)
  • Users who should wait:
  • Enterprise or mission-critical systems where vendor support, security posture, and update stability are top priority.
  • Users uncomfortable with making Defender exclusions or dealing with potential intermittent breakages after cumulative Windows updates. (github.com)
If you don’t urgently need the fixes, the conservative choice is to wait for a stable release (the project’s release notes label 22631.5335.68.2 as a pre-release) and to monitor community feedback for any regression reports.

Conclusion​

ExplorerPatcher’s 22631.5335.68.2 release is a strong technical response to the compatibility challenges introduced by Windows 11 24H2. It restores high-demand features, improves installer robustness, and pragmatically sidesteps Microsoft’s upgrade safeguard so affected users can continue to upgrade to 24H2. Those wins come with trade-offs: increased maintenance risk, potential antivirus friction, and an implicit arms race with Microsoft’s compatibility checks.
For tinkerers and personalization lovers, the update restores a lot of lost functionality and is worth testing on non-essential hardware. For organizations and conservative users, the sensible path remains thorough testing, isolation to test rings, or choosing commercially supported alternatives that do not rely on low-level system patching. The wider question this release surfaces — whether Windows should allow community-driven deep customizations, and how Microsoft should balance upgrade safety with user choice — remains unresolved and will likely shape future interactions between platform owners and the enthusiast community. (github.com) (neowin.net)

Source: Neowin You could well finally download Windows 11 24H2 as ExplorerPatcher fixes several big bugs
 

Back
Top