Windows 7 update success

This in from Jim in Yakima (which is where I went to high school!):

As you and untold numbers of other frustrated users have experienced, the Windows 7 update problems hit me last week. It’s taken a good part of three days to sort through this. Maybe I have; maybe not.

I was able earlier today via Windows update to complete a manual search in 14 minutes. The ensuing download of 131Mb in 12 files (screenshot below) took 4 minutes. After the download was complete, install and reboot finished what we had come to expect as “normal”. It was so normal, I was surprised … particularly after reading the horror stories in recent posts. Quite a bit happened that took me to whatever point this is. Explanation below the second screenshot, which you’ll see shows all 24 installs today, not just 12.

My two desktops (x64 Ult) have not had an update issue (last being May 10) and not a single failure in a long time. Hadn’t used the laptop for a couple months and it became the challenge. It’s x64 Home and set up similarly to the desktops. Update just ran until oblivion (my fuse is shorter than hours), so it was time to dig. All three are using WUA version 7.6.7600.320, so that wasn’t an issue. Search for solutions was on.

Ran into a program, Autopatcher, that apparently has been around for quite a while. It’s one of the offline installers and the links to MS updates seem to be well-maintained. It will download all the MSUs that are applicable to your setup, as you specify. In my case, that was about 1.2Gb of MSUs. I reasoned that, if online updating was going to be a persistent pain, I’d download the bunch and install offline, but not using Autopatcher (it doesn’t do Office 2010+ updating among other things). It does download the MSUs (and EXEs) directly from MS servers (after the legal wrangling), so they are clean.** Those files check their integrity as they run, as well. I had everything I needed through the May 10 updates. Problem was, they wouldn’t run on that laptop. The installer hung, just like Windows update. Something was interfering with both offline and online updating.

Downloaded and ran MS Fixit tool for Windows update which found and repaired registry entries related to the updater service. There was also some repair of the update datastore. When I saw “registry”, I thought “Okay, this could be it.” Restarted and then manually installed the 12 bottom updates that you see in the pic, among them KB3153199, with no problem. Now, if the MSUs will run, how about trying the regular route? Restarted and then ran Windows update. That’s when the other 12 popped up in short order. Did any of the first 12 updates play a role in this surprise? I tend to think not. When I see registry and datastore (EDB file) repair, that’s primary.

Maybe the Fixit tool does the job (it may need to be run more than once; I did and attribute success to it), maybe it was a KB, or maybe the janitor hit the turbo button on the MS TRS-80 servers.

Now it’s time to run the backup.

Jim in Yakima

** Autopatcher designates Windows updates into “Critical” (security) and “NonCritical categories. I found no evidence of GWX updates, so I suspect the developer blacklists those. I don’t endorse Autopatcher, which does not require installation, but I was happy to let it download all those updates for me.

ps – Taking the circuitous path that I did with collecting MSUs via Autopatcher is not something I’d recommend … for nearly all users. The normal update process (when it works) is best.

pps – Wish I knew what the corrupted registry entries were. Fixit just “fixes it” without a log that I’ve seen. What I’d like to discern is, “how did this occur?”

ppps – I use a “secondary” program, Windows Update Notifier, developed for Windows 8 (because it doesn’t have a notification icon, or such?). It also works on Windows 7, even though it’s not necessary. In my trials over the last couple days, WUN wasn’t getting through to the MS servers, either. That’s when I knew it was a client-side problem.