Microsoft, probably: “StartAllBack? Nope, ya little twit, you will use our start menu AND YOU WILL LIKE IT! No installing any of that crap on your our computer!”
Apparently it’s not that the software is broken, it’s that the software being installed breaks Windows Update. There are reports from people that uninstalling StartAllBack, updating the OS, then reinstalling it back (renaming the install executable first) works fine.
As much as being affected by this is frustrating to me (though this is all happening still on the dev channel, so for me it’ll be a problem for the future), I understand Microsoft’s rationale here. They can’t be expected to support every third-party tool that can break the OS, and it’s known that both ExplorerPatcher and StartAllBack relies on many hacks using undocumented APIs to work.
In the last few decades that I’ve been using Windows, I never felt compelled to use shell replacements or customizations - the default experience always worked fine for me with a few tweaks. So, if anything I’m more frustrated at Microsoft that I’m forced to use StartAllBack, because MS went and removed options from the shell that existed forever and always took for granted, and then some.
I’m using StartAllBack on my 22H2 Win 11 Pro ARM VM without issue. Works perfect, uses less resources than the default shell, and Windows updates are still coming in.
This isn’t preventing Windows Updates, though, it’s preventing major upgrades (i.e. 22H2 to 23H2). You still get security updates and maintenance updates, and I believe you can also force the upgrade if you so wish, you just don’t get auto upgraded because of known compatibility conflicts.
Microsoft, probably: “StartAllBack? Nope, ya little twit, you will use our start menu AND YOU WILL LIKE IT! No installing any of that crap on
yourour computer!”deleted by creator
Apparently it’s not that the software is broken, it’s that the software being installed breaks Windows Update. There are reports from people that uninstalling StartAllBack, updating the OS, then reinstalling it back (renaming the install executable first) works fine.
As much as being affected by this is frustrating to me (though this is all happening still on the dev channel, so for me it’ll be a problem for the future), I understand Microsoft’s rationale here. They can’t be expected to support every third-party tool that can break the OS, and it’s known that both ExplorerPatcher and StartAllBack relies on many hacks using undocumented APIs to work.
In the last few decades that I’ve been using Windows, I never felt compelled to use shell replacements or customizations - the default experience always worked fine for me with a few tweaks. So, if anything I’m more frustrated at Microsoft that I’m forced to use StartAllBack, because MS went and removed options from the shell that existed forever and always took for granted, and then some.
deleted by creator
I’m using StartAllBack on my 22H2 Win 11 Pro ARM VM without issue. Works perfect, uses less resources than the default shell, and Windows updates are still coming in.
This isn’t preventing Windows Updates, though, it’s preventing major upgrades (i.e. 22H2 to 23H2). You still get security updates and maintenance updates, and I believe you can also force the upgrade if you so wish, you just don’t get auto upgraded because of known compatibility conflicts.
Gotcha, thanks for the clarification