Win7's Windows Update may be made of squirrels

[mikeymikec]

I have a customer's laptop in which had a problem with WU in that a WU check would never complete as well as a CPU core being saturated. I tried everything I could think of to fix it (MS fixit utilities, nuking softwaredistribution, sfc /scannow, chkdsk /f /v /r, windows update readiness tool, etc), but to no avail. I got the customer to agree to me backing up the data and wiping the installation and install Win7 (64) from scratch. With all new Win7 installs, I put on the update that's supposed to fix W7 WU problems (the one in the sticky) before the machine checks for any other updates. On the old install, the computer had this update already.

Then the new installation had almost the same problem (same symptoms, just different results in windowsupdate.log) after installing about 95% of the updates post SP1 (no extra software installed, just Win7 HP 64 and a couple of downloaded drivers). After the problem started, I left the machine running (disabling sleep mode) for about 1.5 days, during the entire time a core was being saturated. I threw in a couple of reboots and tried a few things to fix it, nothing worked.

This morning I thought I'd try a tactic that has worked for me before (and I had tried it on the previous installation but without success), being that if just plain WU is on the machine, then change it to Microsoft Update ('check for updates for other MS products'), the easiest way to accomplish this is to install MSE. I remembered that the installer I have on USB is old enough that it ends up triggering an MSE client update as well so it's time to update my installer, so I fired up IE on the laptop, direct it to the MS site and tell it to download MSE. Once the installer had downloaded (not run yet), I noticed that all of a sudden CPU activity was extremely erratic, and to my surprise, TrustedInstaller was using a lot of CPU time rather than svchost.exe. Sure enough, after about ten minutes the machine had returned to idle and updates were waiting to install. Since then, the WU client has seemingly worked fine (I'm going to tell it to manually check for updates now and see what happens).

I checked windowsupdate.log and it had apparently just decided to get a move on at the point when I was telling the machine to download MSE. My only theory is that perhaps SmartScreen (triggered by me downloading an exe) gets downloaded updates through WU like MSE does, and that gave the WU client the kick in the ass it needed.

In the couple of minutes it took for me to write the last few sentences, the machine has finished running a manual check for updates and returned to idle.

The portion of the log in question (I believe at about 21:30 last night I had run the windows update readiness tool then after it had finished that, I left the machine saturating a core again.

2016-10-16    21:30:41:569    2572    8d0    COMAPI     - ServiceId = {2ee26adc-24f8-4c3d-9388-b9bd2d35624d}
2016-10-16    21:30:41:678    2572    8d0    COMAPI    IUpdateService removing volatile scan package service, serviceID = {2EE26ADC-24F8-4C3D-9388-B9BD2D35624D}
2016-10-16    21:30:41:678    948    bc8    Agent    WARNING: WU client fails CClientCallRecorder::RemoveService with error 0x80248014
2016-10-16    21:30:41:678    2572    8d0    COMAPI    WARNING: ISusInternal::RemoveService failed, hr=80248014
2016-10-17    03:00:10:006    948    538    AU    Forced install timer expired for AUInstallType = 4
2016-10-17    03:00:10:006    948    538    AU    UpdateDownloadProperties: 0 download(s) are still in progress.
2016-10-17    03:00:10:006    948    538    AU    Setting AU scheduled install time to 2016-10-18 02:00:00
2016-10-17    03:00:10:006    948    538    AU    Successfully wrote event for AU health state:0
2016-10-17    07:33:23:919    948    644    AU    Getting featured update notifications.  fIncludeDismissed = true
2016-10-17    07:33:23:919    948    644    AU    No featured updates available.
2016-10-17    07:35:51:808    948    a48    Agent    Update {BE1A890E-593C-4EB2-9ADE-A09B4E8AD0D5}.202 is pruned out due to potential supersedence
2016-10-17    07:35:51:808    948    a48    Agent     * Added update {94FDBC91-8954-4F4F-B82F-44B02752D74A}.205 to search result

After this portion of the log is about three pages' worth of it saying "oh yuh, I do have a load of updates to process".

One thing that really bugged me this time around was that on a few occasions when the machine was saturating a core, the log's last line would say this:

956    668    AU    No featured updates available.

Yet CP > WU would claim that the last time it had checked for updates was before the last time it had successfully installed a portion of the initial slew of updates.

 

[Chiefcrowe]

That's pretty crazy. Not sure why that would be going on...

I recently was having trouble on 2 computers and i followed these steps, including the convenience rollup for a total of 5 steps. That worked fine although I had to sometimes do more than 1 reboot between these updates for some reason.

(Here's the link to the original post I got this from too: https://forums.anandtech.com/threads/fix-for-windows-7-update.2471653/page-2)

Assuming you are already starting from Service Pack 1 base (install SP1 for Windows 7 if not already). In Windows Update settings, turn off Windows Updates checking ("Never check for updates"), then install:

1. System Update Readiness Tool (32-bit / 64-bit) - optional may skip if no prior update problems
2. Windows Update Agent 7.x (link)
3. April 2015 Servicing Stack (link)
4. June 2016 Update Rollup (link)

Do NOT defer any restart prompts. i.e. If prompted to restart, then restart now not later. After complete, then turn Updates Checking back on to your preference such as 'Automatically check' or 'Download but let me choose updates to install'.

If you want to include the large SP2-esque Convenience Rollup, I would recommend doing it for Step #4 then move June 2016 Update Rollup to #5.

 

[mikeymikec]

Yeah, I've seen that post. I would guess that since the update that largely fixed Win7 WU I've done at least 5 Win7 clean installs in my line of work using my usual technique and this is the first time I've had a problem with it. Who's to say whether if I use his suggested technique whether I would see the problem again next time, or vice versa?

I'd be happier with my SmartScreen theory if in fact there were any signs of its involvement in the WU log. The SmartScreen FAQ says this:

SmartScreen checks the sites you visit against a dynamic list of reported phishing sites and malicious software sites. If it finds a match, SmartScreen will show you a warning letting you know that the site has been blocked for your safety.

But it doesn't mention by what mechanism it works. I would be surprised if it checks the list every time (as there would be a latency hit at the very least), so I assume something must get downloaded and updated locally.

My only other theory is that maybe if I had restarted the computer after running the Windows Update Readiness Tool (which doesn't ask you to restart), perhaps that would have been the end of the problem? Obvious flaws in that theory as well.

 

[Chiefcrowe]

The restart theory seems good, maybe. I restarted after each step even if it didn't ask me to do so.