XPost: alt.comp.os.windows-11   
   From: nospam@needed.invalid   
      
   On Sun, 1/25/2026 4:48 PM, chrisv wrote:   
   > Frank Slootweg wrote:   
   >   
   >> CrudeSausage  wrote:   
   >>>   
   >>> You're going to tell me that you've never had an update take hours to   
   >>> complete?   
   >>   
   >>  Indeed, I never had that. We're talking Windows 11 here, which mostly   
   >> uses modern hardware (because of TPM and stuff) and probably SSDs.   
   >   
   > I've not seen it on Win11, but I know that earlier versions (can't   
   > remember if it was 7 or 10 or both) had a problem that could cause   
   > updates to take hours.  There were a couple of individual updates that   
   > could be done first, to "fix" this problem.   
   >   
      
   The suoersedence calculation done by the Windows Update stack,   
   is a compute bound activity, in which, the longer the OS exist and   
   things are patched, the longer it takes to figure out whether an incoming   
   package should be used, and something else purged.   
      
   At one point, Vista SP2 was in such bad shape, the calculation   
   could run for *days*. Today, if you install Vista SP2, you will   
   notice it never completes (you are never shown a list of updates   
   that you could install). And that is because the signing of   
   WSUSSCN2.cab is now SHA2 and that Vista stack only knows about   
   SHA1 for signing.   
      
   When Windows switched to "Cumulative" this and that, the jumbo update   
   style, the calculation NEVER stopped doing what it was doing in the   
   WinXP era. You're dealing with a 2GB WSUSSCN2.cab file which is   
   analyzed *three sentences* at a time. It's a huge huge data   
   processing thing. Patches only contain a tiny portion of that file   
   (relevant bits). But the Microsoft Baseline Security Analyzer,   
   it checked the entire file, in order to compute what security   
   patches were missing (it did not handle Optional ones).   
      
   IT administrators will tell you that "some of the wheel spin could   
   have been stopped if Microsoft curated the repo better". The Administrators   
   would manually operate their own WSUS servers, knowing what order   
   to install things, to stop the insanity.   
      
   This also led to the WSUSOffline project, having several levels   
   of script for tipping Windows Update upright. One of the things done   
   after collecting certs early on, is a set of five updates that   
   prune Internet Explorer and kernel file and gdi-something-or-other.   
   These were executables that got changed every month, and they are   
   responsible for a lot of the calculation delay.   
      
   On Windows 7, on corporate machines having 2GB of RAM (the call   
   center machines), the Windows Update calculation was running every   
   hour or two, to "see if there were incoming updates". The updates   
   are not "sent" to you, the need of them is "calculated". Well, when   
   the process to do that would start, it was *consuming all RAM*   
   on the 2GB machines :-) Leading to corporate staff not being able   
   to do anything. An emergency patch went out, which *compressed*   
   the blasted data structure. What this does, is trade calculation   
   execution time, versus memory footprint. IT Admins were quite   
   thankful that this came out, as the machines could now be used   
   by staff (even if one core was railed doing that background stuff).   
      
   If you prune the supersedence tree, by patching the naughty bits   
   first, then the other patches can finish a lot faster.   
      
   With the invention of Cumulatives and the bundling of   
   Cumulative and Servicing Stack Update into one file, we   
   have the worst of all possible worlds. Now, you cannot   
   craft install sequences to prune anything, and you   
   are depending on the curation skills of Microsoft staff.   
      
   The process can be accelerated by:   
      
   1) CPU speed, to the expected extent.   
   2) Memory bandwidth, typical acceleration coming from   
      a processor with a larger L3.   
   3) Some sort of magical cleaning process for your WinSxS   
      side by side tree. There are a thousand packages at least   
      in that tree, and the scanning for updates, involves that   
      tree. If you're doing this on a HDD, then shame on you :-)   
      I purposely run one machine here on an HDD, for modeling   
      purposes (to reproduce user observations of trouble).   
      
   The option to "ReBase" the OS, seems to be disconnected and   
   does not do anything. That's an attempt to remove some history   
   so the calculation runs faster.   
      
   As a user, if you lack the skills (or the interest) in fixing   
   your C: contents, you can do a Repair Install, using a DVD   
   of the same version as your winver.exe tells you is present.   
   If it says 26100.1234, then you would use a 26100 DVD. You   
   have the option of disconnecting the network cable while   
   doing that, or leaving the network cable connected.   
   (I prefer disconnection, for better control over proceedings.)   
      
   The Repair Install will do some of the patching, before the   
   desktop appears again. Repair Install is a relatively   
   low-friction way of dealing with complex issues outside your   
   pay scale. Since some packages have "side effects" like   
   fiddling something in UEFI, some packages still have to   
   run on their own. There will be incoming patches to install   
   the 2023 item in UEFI, this year, before the signing on   
   something expires (affects Secure Boot only).   
      
   The Migration Logic was recently changed on Windows. Migration   
   was simplified, to a scary extent. This can shave an hour   
   off the Repair Install time, on those pesky machines with   
   their HDDs. The Migration logic used to study each installed   
   application like a forensics researcher. Today it just gives   
   the App a little slap and sends it on its way (registry entries   
   and all). That's just my subjective guess as to why that happens   
   so fast.   
      
   It takes willful ignorance, to reduce these computers to puddles   
   of goo. If you're receiving notifications that problems exist,   
   you're supposed to do *something*, not give the provider company   
   the finger so your "story of disaster" can be more impressive.   
      
   It's a lot like the kids that jump up and down in the   
   elevator at the mall, until they break part of it. If the   
   car plunged to the basement, the news would be full of   
   "elevator company takes unnecessary risks, some of our   
   finest youth killed". When in fact, it is willful stupidity   
   that will kill those people. The elevators in question, were   
   reduced from examples of moderate quality elevators,   
   to those puddles of goo. Now, the elevator pushes its own   
   buttons. And so on.   
      
   Windows Update has a Pause button. It's not ideal, but   
   for the complainers, it does allow them to schedule   
   downtime to better fit their workflow. And I don't   
   like Windows Update, any more than anyone else. It does   
   not have princely behavior, and is not a shining beacon   
   of how to do it.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)