yes I have, ExplorerPatcher is a shell replacement for explorer.exe and it uses strict default values of windows as well as default registry strings that control the windows interface. The code from Windows 10 is still in windows 11, it's just deactivated.

ExplorerPatcher  simply changes the code back to default settings for explorer.exe which is the Windows shell. As stated on other sites, you can even use Notepad.exe as the shell if you know the right command string. I absolutely do not recommend that method because you need to be certain the app you are replacing explorer with can handle the same amount of data flow as Explorer.exe.

when the ARM update was pushed out, it went to PC users as well as mobile uses and ARM is for mobile devices, not home computers. When that happened, the ARM coding glitched the PC shell default settings. Which is what resulted in this nasty frozen desktop issue.

******

I am on a home PC with windows 11 pro - current version
I have start11 v2, window blinds, fences 5, deskscapes and cursorFX. All of which are up to date and worked flawlessly "prior" to the ARM update.

I do not and never will use crowdstrike. It's very insecure!

In regard to the PC FIX that I posted, I only used ExplorerPatcher to force the windows shell to revert back to the default registry settings and immediately uninstalled it. It fixed the massive cpu drain and desktop freezing.

The issue is nothing to do with ARM what so ever.  The 2.1 update introduced the ARM support for all customers, but only runs on an ARM machine (obviously), but the update also had some bug fixes, one of which related to the search box on the taskbar and positioning of it.

The problem right now seems to be linked to having two settings enabled.

1) Enhanced taskbar in Start11

and 

2) The search box on the taskbar showing as a box.

I imagine your installation of ExplorerPatcher turned that off.

Note that the issue will potentially be more obvious with CrowdStrike as it seems to be putting itself in places you wouldn't expect.

As a heads up, ExplorerPatcher does not exactly work as you think.  It isn't about changing registry entries, it is literally patching addresses in explorer and associated dlls in memory to make it bypass checks which turned off the old code.  Plus some fixing because the old code isn't fully functional anymore.  

---

As a temporary fix, clicking in the search box will fix the problem until next login.

We are working on an update to resolve this issue for those who are encountering it.

We have put out a beta update which should address this : https://forums.stardock.com/530383/start11-v211-beta-feedback-thread

as I said "twice" before, ExplorerPatcher fixed the glitch that was caused. It does not come back on reboot and I can use the search with or without the box and the enhanced taskbar works as it should.

I have rebooted for updates several times already and the glitch doesn't resume.

That was my point. It removed your glitch. Obviously Stardock is obligated to issue an official fix, but for those of us who have work to get done without being forced to fistfight our computers, this option saves a great deal of nonsense!

I use start11 for strict accessibility reasons. So it was very frustrating when things went haywire.

Whilst I am glad your issue was resolved before, I can assure you the issue would return if the conditions were the same.  Being search box enabled and enhanced taskbar enabled at login.  There may have been a timing sensitivity to it given restarting explorer doesn't trigger it however so if anything slowed down or speeded up the login process then it might have changed the conditions slightly.

So I think it may have been luck as to why it resolved it for you, but as long as you are not having the problem that's what matters.

I ought to mention it had nothing to do with ARM support but was linked to a fix for the Windows search box positioning that 2.1 had.

The 2.11 beta has a fix for the code that triggered this and thanks to everyone who reported this and apologies for the issue slipping past QA testing.

Unsure if it related, but a Widget update appears to have made Start11v1 somewhat unresponsive as well. No CPU spikes, but turning of the Widget in Windows Taskbar Settings, or, based on similar comments made in the Start11v1 1.55 thread, turning of Enhance Taskbar in Start11, appears to fix the unresponsive issues.

v211 beta release looks good (on my system at least) - Windows Explorer behaving normally again.  Good job guys!