There’s three points to this: First off, I remember talk from Linux distro maintainers that delta patches might not always be as efficient as one might expect. I believe efficient delta-patching requires a whole lot of intervention alongside the whole pipeline, so your compiler doesn’t start putting out equivalent, but different, instructions throughout your binaries and now the patches fail. While it’s possible that MS isn’t bothering hard enough for this to work, I suppose this is a minor point.
Utterly significant is that Windows Update is a perennial source of problems and had become very slow on Windows Vista and 7 computers. I have dug rather deep into this (it was many years ago), yet I've never found a full, right down to the metal, public explanation for this. Apparently, Windows has used (and might still be using) a kind of component-based architecture, very advanced by itself. Components can depend on each other and can supersede each other. According to tales, in order to enable update supercession, the Update services had to check every update against every other update in the whole catalog (database). This made it end up at least with quadratic behaviour and is (again, according to some) the primary reason why my HDD-based Vista SP2 computer took in the realm of—possibly more—than three quarters of an hour of one (of two, relatively weak) cores working hard and 700–800MiB of RAM to arrive at the conclusion that no applicable updates had been published. The whole update architecture seems to have been intractable garbage for the common case, advanced as it may have been. Imagine the wasted computing power accross all machines. In fact, even Win11’s update check is kinda slow.
So, what Microsoft has done is they’ve decided, at some point in time, that they would henceforth only roll out cumulative monthly updates (if I recall correctly), that have all the previous updates since some point in time (I think they started out with, since the last major update, but might be even more since then?) This enabled them to simplify their algorithm, but it means there will be lots of redundant changes delivered to you. (By month four, you'll install updates 4, 3, 2, 1, month five, 5, 4, 3, 2, 1, month six, 6, 5, 4, 3, 2, 1, …)
Now a minor point again, no matter whether they actually only delta file-wise (and I, too, remember hearing about something like that), it’s the natural run of things that changes all over the place would start accumulating, thus more and more approaching a full update.
Heh, funny thing about that, Windows is used on some 1.6bn devices (1.6KKK, not to be confused with the other triple-K) worldwide, so if 0.01% of setups were failing, that’d still be 100,000 or so of very angry people … (Might be just about in the right ballpark? What kind of time frame are we talking about, broken devices total at any given point in time? Might be at most an order of magnitude less, wordwide?)
Standard advice is: Have you tried a clean clean install? Where you nuke your disk before installing? Very weird. Are these alll the same models of computers, or various? There’s a mechanism to install drivers from your UEFI, if that is the cause, that’d be rad. I don’t think it’s malware.
There’s one simple trick Microsoft (or any OS could have implemented back in 2001 with XP, or even before: Instead of restarting and then idling ad infinitum, hand the user a restart-to-standby button. With the re-opening of programs Windows has received at some point in time (I’ve used Vista for years, but did that already have it? Win7, -8?) many users could have had painless restarts who previously might not have felt like it. Of course, there’s strings attached, not all programs seamlessly resume where you’ve left off, but for many, it could have been good enough.
It’s paramount for that that Windows would actually reliably force a power-down state. Either standby, and if that cannot be reached for whichever reason, force a shutdown. This would remove concerns about the computer running indefinitely.
)