Some people learn to live with Windows and make the best of it. Others refuse, and turn to third-party tools to bring back bits and pieces of prior capability that MS has removed. Ditto for adding functionality missing but desired in Windows. When MS released its “Moment 2” updates on February 28, it announced that KB5022913 may break customization tools in common use.

If KB5022913 May Break Customization Tools, Then What?

If an update breaks a third-party tool, users have two choices:
1. Remove the third-party tool, and continue forward with the update.
2. Uninstall the update, and keep using the third-party tool.
Of course, neither option is perfect but sacrifices are sometimes necessary here in Windows-World.

Here’s what the announcement says, verbatim (emphasis mine, for easy identification of possible offenders in the first paragraph; emphasis in the second paragraph is Microsoft’s):

After installing KB5022913 or later updates, Windows devices with some third-party UI customization apps might not start up. These third-party apps might cause errors with explorer.exe that might repeat multiple times in a loop. The known affected third-party UI customization apps are ExplorerPatcher and StartAllBack. These types of apps often use unsupported methods to achieve their customization and as a result can have unintended results on your Windows device.

Workaround: We recommend uninstalling any third-party UI customization app before installing KB5022913 to prevent this issue. If your Windows device is already experiencing this issue, you might need to contact customer support for the developer of the app you are using. If you are using StartAllBack, you might be able to prevent this issue by updating to the latest version (v3.5.6 or later).

Notice that MS puts the onus for figuring things out if Windows doesn’t work properly with such a third-party tool on that tool’s developer. This could make life extremely interesting for related tech support operations.

To Tweak, or Not to Tweak?

With apologies to Hamlet (and Shakespeare), the real question is how much, how often and what kinds of tweaks Windows users can safely make to their own installations? I’m of the opinion that “less is more” because it involves fewer things that could go wrong, and fewer such things to keep track of.

That said, I do indeed enjoy tinkering with Windows. I don’t see what MS is doing here as a general injunction against such efforts. Instead I see it as a warning against “unsupported methods” that some developers use. I agree with MS that on principle such tools are best avoided. But that puts an interesting burden on users to figure out what’s working and what’s not. I can tell you from copious personal experience that diagnosing and pinpointing trouble can be difficult and time-consuming. Indeed: the MS workaround seems like a well-intentioned way to shortcut that work, and bypass related problems.

Note Added March 2 AM

This morning, the first thing I saw on WinAero was a story entitled “A new version of ExplorerPatcher fixes issues with Windows 11 “Moment 2” Update.” According to WinAero principal Sergey Tkachenko, at least one set of already-identified problems is addressed. I guess that’s the kind of response you’d hope for, if you were an ExplorerPatcher user. While I am not, I see plenty of people over at ElevenForum who use (and praise) it.

Another item has joined the list of offenders, though: Stardock’s Start11 (says Neowin). That one, I do use, on some of my Windows 11 PCs. Guess I’ll have to watch closely and take evasive action as needed.

Stay tuned: this looks like it could get increasingly interesting…

For some time now, my spouse Dina has resisted upgrading to Windows 11. Her 11th gen Dell 7080 Micro meets all of the hardware requirements. But she’s not ready to take the plunge. Thus, when somehow, someway Windows Update started the Windows 11 upgrade process on her PC, I got a little worried. I shouldn’t have bothered — part-way into the install process, the installer halted the upgrade. Why? Because of a compatibility hold, Start10 blocks 11 upgrade on that PC.

Easy Fix for Start10 Blocks 11 Upgrade, But…

Yes, I know: if I were simply to uninstall Start10, the upgrade would proceed without further demur. Ironically, it serves as a form of insurance in this case. When Dina’s ready to upgrade, I’ll upgrade her (and install Start11 on the resulting build to minimize the impact of that change). That’s when I’ll take Start10 off the board, then…

The frequently-offered upgrade got started somehow in the last week. Somebody must’ve clicked the “go-ahead” button without really understanding what was going on. If it happens again, I now know that the upgrade process will quit before it gets to the post-GUI install phase.

Shoot! It might even be the case that now the compatibility hold is known to the Windows Installer, it won’t even try again. I certainly hope so. But sometimes, here in Windows-World what looks like a curse is actually a blessing. Of course, that vice is often versa, so it doesn’t always (or only seldom) works in one’s favor.

Thus, I’ll revel in this surprisingly friendly turn of events. It will certainly help to preserve domestic tranquility here at Chez Tittel. It should also suspend the too-typical “What did you do to my PC?” that “The Boss” has been known to emit after Windows Update does its periodic thing on her machine.

When this error shows up in WU, I can bail on the upgrade. Funny that it doesn’t screen in advance, but after downloading and during the GUI install phase (about 35% of the way in, if what the UI says is true). Go figure!

It’s over … for now, at least. That’s right: the Build 25267 announcement states “This will be our last Dev Channel flight for the holidays.” Hence my title for today’s post: 25267 last 2022 Dev Channel Build. I must say it went pretty smoothly, too: it took under half an hour from start to finish: download, GUI and post-GUI install, and thence to the desktop. Good stuff!

If 25267 Last 2022 Dev Channel Build, Then What?

Enjoy the holidays, I guess. According to the change log, the only noteworthy element is “more rounded corners” for the expanded search results obtained via the taskbar’s search button. The lead-in graphic shows what that looks like. AFAICT, it’s no biggie. Note: I had to fiddle with the screen cap (and blew it up to 150% for improved viewability) so it’s a little fuzzier here than in “real life.”

Poking Around Behind the Scenes

Just for grins, I took a look at the size of Windows.old after this latest upgrade, to get a sense of how big a Windows 11 image is nowadays. On both of my test machine, it came in just over 23GB in size. (One PC is a Lenovo X12 Hybrid Tablet, with 11th Gen i7-1180G7 CPU, 16 GB RAM, 1 TB SSD; the other is a Lenovo X380 Yoga, with 8th Gen i7-8650U, 16 GB RAM, 1 TB SSD.)

It used to be conventional wisdom that a Windows install required 20 GB of free disk space. Now, it looks like 25 GB is probably a safer general guideline. Interestingly, the Disk Cleanup utility reports the size of Previous Windows installation(s) as 15.4 GB, even though a properties check on Windows.old (Build 25262) returns the aforementioned sizes. Cleanup takes a little while, too: about 4 minutes on each test PC or thereabouts.

Note the reported size here is about 9 GB smaller. Interesting…

Marching into 2023

It’s still 17 days off, but 2023 is coming. I imagine we might see resumption of regular flighting the week of January 9. But heck, it’s been a busy, busy year for Windows 11. I count 32 Builds in Update History starting from March 21, 2022. And while I’ve encountered (and reported) occasional issues along the way, most have been minor. And none have stopped me from tracking along with each new Build as it’s emerged. I can only hope next year goes equally well.

Hey, it’s preview software, right? It’s supposed to do strange things from time to time. And indeed, on that front, Dev Channel Build 25252 (released yesterday) does not disappoint. What do I mean when I say that Build 25252 offers odd install behavior? At least two unusual items have popped up so far:

1. As is my usual practice, I attempted to RDP into both of my test PCs. Neither would accept a connection, and both reported “too many connections already in use” (none, in fact). But both were on the “Restart to continue install” window. I’ve never seen this result in RDP refusal before, but there you have it.

2. On the X12 Hybrid Laptop the 1st and 2nd reboots did not complete on their own. Instead, the PC shut down instead of restarting. A quick pop to the power button took care of this, but noteworthy nevertheless. I’ve seen this happen on other, earlier Dev Channel Builds on this very machine.

Feedback Hub Hears When Build 25252 Offers Odd Install Behavior

I’ll be reporting these oddities to Feedback Hub next, if they’re not already present in some form or fashion. It often gets interesting, figuring out how to describe install issues (and other Windows oddities) to synch with how others describe them there. I’m going to use RDP to jump onto both machines right now…

And that works as it should, thank goodness. I filed the RDP issue as “When Build 25252 Install Ready to Reboot, Doesn’t Accept RDP Connections.” I simply added a comment to my earlier filing on the other problem, which is named “Build 25231.1000 shuts down during install instead of rebooting.” This comment explains that the problem recurs for Build 25252.1000, and happens twice during the install process.

Another Build, Another Learning Exercise

This kind of thing is fairly routine for new Insider builds. I regard providing feedback as an important part  — indeed, arguably the most important part — of my job as a Windows Insider. After all, if nobody tells MS about little oddities that occur they may never hear about them otherwise. Reporting is a vital aspect of arming the Windows team with as much information to find and kill bugs as possible. Plus, it’s fun!