Has Microsoft (finally!) solved the Windows 7 slow-update problem?

Topic

New Reply

Volume Z just posted a link to this report from Microsoft employee Karthikeyan Kesavan : This has been fixed and it should take less than 30 minutes n
[See the full post at: Has Microsoft (finally!) solved the Windows 7 slow-update problem?]

Reply | Quote

Replies

Wow, the last time I checked over 24 hours.
Today 8 minutes!

Reply | Quote

I just tested on a Windows 7 x64 virtual machine that does not have KB3172605 installed, and is missing many security-related Windows updates. Windows Update check took 11 minutes, which I believe is less than it took previously with the exact same configuration.

Reply | Quote

It worked for me!

I changed auto updates to ‘never’ after that annoying popup window for Win 10 showed up.

I have a total of four computers with Win 7. (2) 32 bit, and (2) 64 bit.
I installed KB3172605 on all of them, and updates went from taking days, to minutes. One was taking up to 5 days….

FYI, KB3020369 had already been installed on 5/13/2015.

Bill

Reply | Quote

Confirmed
on a clean installl, stuck or delay no longer oocur
however, i did not test installing updates to see if the issue happens later

Reply | Quote

Who cares anymore. The damage has been done.

The solution — provided by Canadian Tech, not MS.

MS created this problem. Deliberate or not, they have no right to make claim to having fixed it.

‘MS finally solved it’ – fake news !

Reply | Quote

Woody, this is the fix I applied a couple of weeks ago after one of your Ask Woody readers suggested it. It’s basically the same as your fix, but I found it a little easier to follow and apply. My problems were slow to non existent Windows Updates and slow to non existent download and install of updates. This fix corrected both problems. I would say it works.

Reply | Quote

To be clear, I didn’t say MS solved it. I said MS claims it’s been solved.

No fake news around here.?

Reply | Quote

I got the fix thru you, not MS by the way!
🙂

Reply | Quote

Great news!

So what did they fix? And why did it take two years to fix it?

Reply | Quote

Hi Woody,

they obviously adapted KB3078601, the Monthly Rollup, KB3128019, KB3128022, KB3128024, KB3128025 and KB3128037 to the default Update Clients. The issue was always due to inappropriateness of only a few updates – the ones identified by Dalai. 🙂

Reply | Quote

Yup, it is much quicker (only took 3 mins instead of 40mins +). I am still being assaulted by MS Essentials definition updates every 2 hours tough, hope it gets fixed too

Reply | Quote

I can’t say for sure, but it’s all in the metadata, they either expired old ones or pushed new ones to handle the supersedence chain

if i was a conspiracist, i would say why they waited until there cumulative model is ready to fix the issue 😉

Reply | Quote

The solution does not involve installing any update, it’s fixed at the metadata level (i.e. MSFT side)

Reply | Quote

There were many expired updates in the last few days. I provide the list here and let anyone else to make sense of it:
KB2567053
KB2617657
KB2639417
KB2641653
KB2660465
KB2709162
KB2718523
KB2731847
KB2761226
KB2778344
KB2778930
KB2779030
KB2808735
KB2829361
KB2850851
KB2876315
KB2883150
KB2893984
KB2913602
KB2930275
KB3000061
KB3002885
KB3013455
KB3034344
KB3057839
KB3070102
KB3095649

Reply | Quote

I am not sure I can corroborate. But, I can address likelihood. Yes, it would appear that in at least three instances today, Windows Update checked for updates rapidly for my Windows 7SP1 x64 system. This system has been updated fully under the new model through December 2016 (KB3207752 applied 01/08/2017). NOT fully updated under the old model. Neither KB3161608 nor KB3172605 were ever applied due to my lassitude and uncertainties about how they would affect the system Bluetooth. NO January 2017 updates have been applied yet.

My habit for the past few months has been to apply the Security Only Quality update (the SOQU, “sock you”) very soon after it was issued and then wait to apply the Security and Quality update (the SAQU, “sack you”) several weeks after it was issued. And, for several months now there has been, for my system, a brief window only when Windows Update would get anything at all. That was after applying the SAQU at the end of a given month, but before MS update Black Tuesday in the succeeding month. Usually had to wait about 10 minutes for the updates to present then. Any other time, I usually gave up after 1/2 hour to an hour, with nothing.

Today, when I should be getting nothing, instead:

Check for updates: 13:19,
updates presented: 13:21;

Check for updates: 13:56,
updates presented: 13:57;

Disconnect from internet, shut down system, snack break, check Bluetooth 14:25 to 14:35 (it still works);

Check for updates: 14:55,
updates presented: 14:56!

Shall we now sing high praise to mighty Redmond?

Regards,
shopper55

Reply | Quote

Is it just me or is this a problem that is never actually fixed even after it is said to be resolved? It’s like sequel after sequel of a bad film.

Let us examine what incentive Microsoft has to actually resolve it, shall we?

It frustrates users that their manually-initiated updates get stalled, and it’s just that many more people each month who will decide to throw out their old system and try Windows 10 and/or Microsoft hardware. Maybe only thousands of people or so a month, but that’s thousands more on Win 10 – the place where Microsoft intends to make more money off them.

Not to mention those systems pushed over the edge to failure by hard CPU loops causing much heat…

So… They could do the right thing, or the thing that gets them closet to Nadella’s goal.

-Noel

Reply | Quote

AHA!

Reply | Quote

Thanks
i hope they expire more and more 🙂

Reply | Quote

This explains why 20 hours ago I could not reproduce the issue discussed in the other thread about KB2990214 and I said that 7.6.7601.320 was behaving potentially better than KB3050265. 🙂

Reply | Quote

Adapted them how? isn’t those are Office patches?

Reply | Quote

See my comment here 4 days ago
https://www.askwoody.com/2017/windows-7-8-1-patches-are-up/comment-page-1/#comment-114363

Reply | Quote

I see what do mean now, after checking @ch100’s list of expired updates
those updates are the base now for supersedence chain, and the older updates they supersede are removed

i guess they didn’t bother to do the same for Vista, since it’s 3 months away from EOL

Reply | Quote

I’m guessing MS decided to hold out as long as possible before deciding to do something about this.

With the inconvenience they caused to Windows 7 users, they thought there was more chance of getting them to give up and move to Windows 10.

Must have reached a point where the adverse publicity was getting so bad that MS finally realized there was a good possibility of losing Windows customers altogether to Android or Linux instead of Windows 10.

Also, seeing as a lot of companies still use Windows 7, pressure was probably being put on MS from the business community as well.

Reply | Quote

I did three tests today in the same Windows 7 x64 virtual machine. Each test was done after restoring the same virtual machine snapshot.

Test 1: wuaueng.dll v7.6.7601.19161 (from KB3138612). Windows Update check took 11 minutes. This is the same test that I mentioned in my first comment.

Test 2: wuaueng.dll v7.6.7600.320 (the oldest version currently allowed with SP1 installed). Windows Update check took at least 30 minutes. I ended the test after 30 minutes while Windows Update was still checking for updates.

Test 3: wuaueng.dll v7.6.7601.23453 (from KB3172605). Windows Update check took 9 minutes.

Conclusion: In some circumstances, Windows Update check in Windows 7 can still take more than 30 minutes if you use some older versions of the Windows Update client.

Reply | Quote

Likely there is very little interest for Vista and Windows Server 2008 (R1) due to the number of customers involved.

Reply | Quote

That’s right.

See The FlyingDutchman2’s post at this page:

https://answers.microsoft.com/en-us/windows/forum/windows_vista-update/updates-not-working-it-has-been-searching-for/92cd6922-17f6-4730-b46b-91a480b95dd3?page=32

If your Vista installation is eligible for at least one of those updates (i.e. MS Office 2003/2007/2010 installed), the issue takes effect.

If your Vista installation is eligible for the Cumulative Security Update for IE (i.e. IE9 installed), the issue takes effect.

The triggering updates for IE9 and MS Office were identified by me.

The critical updates for MS Office have now been made suitable in Windows 7 not only for Update Client 7.6.7601.23453, but also for earlier ones – and so have KB3078601 and the Monthly Rollup. 🙂

Reply | Quote

Noel, it is also Windows 2008 R2 involved.

Reply | Quote

I started testing on Windows 2008 R2 which is of more interest to me than Windows 7, but also because I know that Windows 7 will be covered by many other posters here soon. 🙂
The results for Windows 7 and 2008 R2 should be the same.

I installed a VM with 2 CPU cores and 12 GB RAM and installed .NET Framework 3.5.1, Desktop Experience and IIS and enabled Remote Desktop to get most updates available.
First scan took few minutes, maybe 10 minutes, I don’t know exactly. I installed all 146 Important Updates, 4 of them failed. This is not good practice, but I wanted to see how much RAM will cache on a beefed-up machine and it took all RAM for caching. The best practice is to install only about 25 updates at a time to avoid RAM issues.
After reboot, I allowed .NET Framework to do its recompile routine and Trusted Installer to finish and after that I ran another scan. It took few more minutes and now I have 8 Important updates available and 66 Optional (including Recommended).
First scan was done under agent 7.6.7601.320.
For the second scan, I assume the agent included in KB3138612 is the one in use, as this patch was installed after the first round of updates.
KB3172605 is Recommended and was not installed and is not even offered yet.
I think the test is relevant up to this point and while I will complete the rest of the installation, further results are no longer relevant.

All scanning was done while Never check for updates was set.

There is a slight chance that with the setting on Auto or any of the other configurations, a scan would be triggered while another scan takes place and this would interfere. Normally the new scan would be placed in a queue, but I wanted to avoid that possibility.

Reply | Quote

There is always WU MiniTool with the option to include superseded to get around this issue in Vista.

Reply | Quote

To be clear, it seems that now a clean install of Win 7 SP1 will no longer experience any slow or broken scanning by Windows Update, ie when the users click “Check for updates”, about 200 pending important updates will be shown within minutes, n not after many hours or never.
……. Previously, the users had to manually install KB3020369 & KB3172605 & etc to fix this issue for a clean install of Win 7 SP1 – courtesy of Canadian Tech, Volume Z & friends.
.
This latest fix from M$ comes belatedly, about 15 months after the issue of slow scanning of WU for a clean install of Win 7 SP1 first cropped up in Aug 2015, which also happened to be soon after Win 10 was launched on 29 July 2015.
……. Looks like M$ only provided this long-awaited n permanent fix after failing to get the majority of Win 7 users onto Win 10. In this case, M$ are both the problem-maker or trouble-maker n the final solution-provider.

Reply | Quote

Test 4: same conditions as Test 2. Windows Update was still scanning 65 minutes after it started.

Reply | Quote

A thought that has been niggling me in the back of my mind these last few weeks/months and that is AI.
You don’t suppose the reason for all these mixups that have been happening with WU could be because MS are relying on AI to programme/maintain their WU.
After all they did make a lot of their staff redundant recently. This sort of scenario has revealed a lot of failings recently around the world where AI has been deemed to be the ultimate cost saving method of doing business… and there are many red-faces who have had to revert back to the ‘human approach’ Just my 2 bits! LT

Reply | Quote

It’s strange, on a Pre SP1 Home version of 7, WUD works pretty quick, after SP1- it does take forever, until the patches from the .de site are applied.

MS claims they fixed it, LMAO. Really!?

Reply | Quote

Hello all, It must be many are/were suffering from the slow downloads of updates but I and a friend have not had any issues for the last few months with windows 7. One to three minutes is normal for our “check for updates”. I still get KB3177467 offered to me -after- I install the current “security only” update and hide the rollup. I am afraid to install the KB3177467 because I am having no issues at the moment so “if it ain’t broke…” Thanks Woody for all the great help you (and other followers) give.

Reply | Quote

Weird, I did repeated tests with 7.6.7601.320 and it was as quick as it should be.
One of the tests was done yesterday for a different issue, not realising that the expiring of all those updates has such a huge effect.
How much RAM does your VM have? This is a critical issue with older agents. I have been running 64-bit VMs with 6 GB and 12 GB. I think anything less than 6 GB RAM tends to be limiting at least in relation to WU, although 4 GB seems to be OK for most other purposes.

Reply | Quote

They do it regularly for:
– Windows 10 (all builds)
– MSRT
– MSE / Defender / FEP / SCEP

Not regularly maintained for:
– Windows 7 / 2008 R2
– Windows 8.1 (I monitor only 2012 R2, but should be very much the same)
– Office any version

Maybe with the CU/Rollup system fully in place, they will start doing the same that they do for Windows 10.

Reply | Quote

I think few people here keep posting about how KB3172605 fixed it for them which, while it is great for those posters, is not related to the current topic.

Reply | Quote

@ Lizzytish ……. I doubt it. AI in Windows is mainly for a virtual/digital personal assistant for the users, eg Miss Cortana. AI is still a work-in-progress n quite prone to errors/miscommunication/misinterpretation. It would be very foolish for M$ to use AI to “assist” users for their Windows Update processes.
.
About the prevalence of buggy Windows Update in Win Vista/7/8.1 lately, actually M$ laid-off their QA staff/testers just b4 the launch of Win 10 on 29 July 2015, …in their stead, M$ relied on Windows 10 Insiders as free alpha-testers n Win 10 Home users as free beta-testers for their updates/upgrades. But for Win Vista/7/6/8.1, M$ mostly had to rely on ALL the respective users as both their free alpha- & beta-testers = more problems with updates.

Reply | Quote

@ win7user ……. Fyi, the above article is referring to a clean install of Win 7 SP1, n not an up-to-date n running Win 7 SP1.

Reply | Quote

Yes, I agree, much better.

Thanks to Woody!

Reply | Quote

Tests 1 through 4 were done on a virtual machine with only 1024 MB of RAM. I realize that’s under the minimum specs from Microsoft for Windows 7 x64, but it usually works well enough for me.

Test 5: Same conditions as Test 2 and Test 4 but instead with 1946 MB RAM, the most that VirtualBox would allow. Results: Windows Update was still scanning 30 minutes after it started.

My recommendation is that people should be using Windows Update client v7.6.7601.23453 from KB3172605 because its algorithms are much more efficient in time and perhaps also memory compared to some older Windows Update clients. However, if one has a good reason to avoid KB3172605, then due to Microsoft’s very recent server-side changes of expiring some Windows updates (that ch100 has mentioned), one may now be able to use older Windows Update clients. Be aware though that if you use a Windows Update client older than v7.6.7601.23453 from KB3172605, Windows Update scans might become unacceptably slow again in the future.

Reply | Quote

less than 5 minutes… and lve avoided upgrading since july 2016 when l comitted the horrible mistake of upgrading via internet to win10 from a pirate version of win7

Reply | Quote

It’s just you.

Reply | Quote

🙂

Reply | Quote

Woody,

I don’t know about everyone else, but I have not had a problem with update check speed since November. WUMT hasn’t taken more than 5 minutes. Today’s check only took minutes.

IF I recall correctly, I followed your suggestion to install either 2 or 3 updates (I don’t recall the exact number) and after that update scans have been under 5 minutes every time.

Just my 2 cents worth.

Dave

Reply | Quote

Are you in Group A?

Do you have KB 3172605 installed?

Either seems to be sufficient to get rid of the abysmally slow scans.

Reply | Quote

Woody,

being in Group A was never sufficient to get rid of them.

The issue got/gets (Vista) triggered by regular release of ever new updates (considered magic patches) that pose problems to the Windows Update Client.

There is no way of preventing this through activities of whatever type on your local installation.

Regards, VZ

Reply | Quote

Absolutely agree with you about KB3172605.
The issue here is that most people don’t have a clue about Catalog or manual installation of patches unless they are instructed by someone who has the knowledge. Even most sysadmins would not know what many of us here know about WU.
I think I actually diagnosed correctly why scans take longer for you in testing and many others using computers with limited amounts of memory.
While I understand that you are limited in what you can use for virtual machines, for everyone else, the general advice is to have minimum 4 GB RAM for 64-bit systems and minimum 3 GB of RAM for 32-bit systems.
The value which I generally recommend of 6 GB as being the sweet spot is based on working with Windows 7 and above and Windows 2008 R2 and above for the last 7 years in hundreds of virtual machines. I understand that 6 GB is not a “normal” value for physical machines unless using triple-channel memory which is rare, but in most regular situations, 8 GB is the recommended value and using Windows 7 64-bit.

Reply | Quote

Being at RAM, the page file IN USE should never be larger than 200 MB. The safe value which I use is 512 MB and set the debug file to small or None.
The 200 MB is in use by the system in most cases, but beyond that, this to me indicates lack of enough RAM and the system slows down dramatically in such conditions. This does not apply to older systems like Windows XP as they had different memory management.
Please do not argue with me on this subject, I will not reply, because it will never end. Read these articles instead.
https://blogs.technet.microsoft.com/markrussinovich/2008/11/17/pushing-the-limits-of-windows-virtual-memory/
https://www.citrix.com/blogs/2011/12/23/the-pagefile-done-right/

Reply | Quote

Did an install here this weekend and added KB3172605 but the image was pre-updated up to July last year inc. (in)famous KB3125574 and it was the usual 10-12 mins for the updates to flow. So on the positive side it doesent wreck anything. Is there somthing we are missing here as to why folks are still having this problem? as we have had a ton of solutions and M$ seem to be in the dark. Is it System arch?, Installed software incompatabilities?, older Machines? (this ones 16 years old ne’er a problem here) got me stumped. With a clean install I just use, and have for some time, the old standbys KB31338612, KB947821 preinstalled or after from the desktop (gets it down to the usual 10-12mins).
Hey this is M$ and these “infernal machines.” Dont suppose it was meant to be easy despite the “brave new world” outlook they were vaunted as a long time ago lol

Reply | Quote

MS claims to have fixed it but it should have been a higher priority than it was. MS seems to have forgotten that W7, Vista, etc users are customers (even if indirectly) who should not be angered. When angry enough, customers will find other solutions. And other solutions already exist for most users (Apple, Chromebooks, Linux, etc.).

Reply | Quote

This thread is about verifying and discussing that Windows Update now works without the nees for installing any updates manually

Reply | Quote

Is the test with v7.6.7600.320 done on clean install or already updated with some updates?

because i tested v7.6.7600.320 working on clean install

however, KB3138612 still the next best thing after KB3172605
maybe even better for some, since it’s important, does not need prerquisites, only have WU components

Reply | Quote

Read my posts here and abbodi86’s posts and you will have the whole picture.
1. By expiring (“pulling” to use Woody’s favourite) certain superseded updates, the calculations have been done a lot easier for the early WU agents which allow the completion of scans in reasonable time.
2. For systems with lower resources and in particular low RAM, the calculations may still prove too heavy and those systems may benefit from KB3138612 or KB3172605 which are optimised to use less RAM during scanning and calculating dependencies. I am wondering if this limitation of RAM in use would impact the speed of the calculations for systems with enough memory though.

Typical values for RAM used by older agents are in the range of 2 GB and also TrustedIntaller.exe uses other about 2 GB RAM if many updates are installed at the same time. Limiting the number of simultaneous updates installed to about 25, would assist with lowering RAM consumption by TrustedInstaller.exe.

Reply | Quote

+1

Reply | Quote

I’ve seen those recommendations before, and I agree with them :). Thank you for sharing.

Reply | Quote

On a computer with some updates installed already, but also with many security updates not installed.

I agree with what you said about KB3138612 being the second best Windows Update client.

For those that don’t know, a few months ago abbodi86 provided a method of installing just the Windows Update client part of KB3172605, but I don’t recall which post contains it.

Reply | Quote

+1 🙂
7.6.7600.320 works well now, but like few other versions later, it tends to take too much RAM and for systems which don’t have enough, it causes a problem.

Reply | Quote

Guess what all have in common!
They are all superseded by KB3185911 🙂

http://wu.krelay.de/en/2016-09.htm

Not sure if someone in Microsoft used Dalai’s research or they found it by themselves, however Dalai was right on the money!
Well done 🙂

Reply | Quote

KB3185911 is now superseded by 2 rollups:

KB3207752 – December, 2016 Security Monthly Quality Rollup for Windows 7
KB3212646 – January, 2017 Security Monthly Quality Rollup for Windows 7

To assist Woody and his Group B users, now I will tell you the best kept secret. If you want to have good scanning experience and keep it going, please do yourselves a favour and install manually or in any other way KB3185911, even if it may not come on Windows Update, because it will not come, unless you hide the superseding updates.

KB3185911 is the mother of all speed-up patches and KB3172605 is topping it up at the Windows Update agent level. Both should be installed for best experience, while any of them is good enough.

Group A users have had KB3185911 sorted automatically as part of the rollups in December and January. This explains why some users without KB3172605 still have had good updating experience since December 2016 rollup release and installation.

Still interested in having a hard time and stay in Group B?

Reply | Quote

As an experiment, on my Windows 7 x64 machine (Group B), I uninstalled KB3172605 and searched for Windows updates. Windows was able to complete the search in a few minutes, which was not the case (never-ending search time) before KB3172605 was installed a few months ago.

Reply | Quote

I think you are right 🙂
See my post above, December 2016 and January 2017 patches had already short-circuited the offending patches which are now expired.

Reply | Quote

Then try to rebuild WU database
stop WU service, delete this folder contents
C:WindowsSoftwareDistributionDataStore

then open WU and check
i suspect that the old metadata already stored in DataStore.edb may cause the issue

Reply | Quote

So that’s the trick!

I wonder if those in Group B who didn’t install 3172605 (or 3185911) still have slow scans?

Man, Microsoft sure makes this difficult….

Reply | Quote

+1

Reply | Quote

At a second thought, I think the missing KB3185911 was worked around by removing all those expired patches.
And this would explain why missing KB3172605 does not matter or does not matter so much anymore.
People without KB3172605 or another later WU agent should still watch the RAM because the old agents tend to use a bit too much of it.

Reply | Quote

Thanks for confirming. 🙂

Reply | Quote

@abbodi86 See my other post, KB3185911 is now the base of the supersedence chain.
Also under the Package Details tab, you will see my list 😀
https://catalog.update.microsoft.com/v7/site/ScopedViewInline.aspx?updateid=e3c83c7e-55ee-49a4-a8e6-66df82119e89

Reply | Quote

+1 🙂

Reply | Quote

Woody, it’s more confusion being spread. The days of slow scans are over regardless of Group affiliation. It’s ch100 who makes it difficult now. Coming up with KB3185911 a month after its supersedence.

The two remaining triggers for Windows 7 were KB3178601 and the Monthly Rollup. KB3185911 didn’t play a role anymore a month before Microsoft’s fixing the issue, let alone after.

Now that the issue is fixed, no activitiy beyond installing KB3138612 or KB3172605 can speed up Windows Update any further.

No users without KB3172605 still have had good updating experience since December 2016 rollup release and installation. It’s just plain wrong.

Reply | Quote

This is the same list with their release date (in Australian format – dd/mm/yyyy)

KB2567053 – 11/10/2011

KB2617657 – 08/11/2011

KB2639417 – 13/11/2011

KB2641653 – 13/03/2012

KB2660465 – 14/02/2012

KB2709162 – 12/02/2012

KB2718523 – 10/07/2012

KB2731847 – 14/08/2012 updated 10/10/2012

KB2761226 – 13/11/2012

KB2778344 – 12/02/2013

KB2778930 – 08/01/2013 updated 12/02/2013

KB2779030 – 11/12/2012 updated 20/12/2012

KB2808735 – 09/04/2013 updated 24 April 2013

KB2829361 – 14/05/2013 updated 16/12/2013

KB2850851 – 09/07/2013

KB2876315 – 10/09/2013

KB2883150 – 08/10/2013

KB2893984 – 10/12/2013

KB2913602 – 14/01/2014

KB2930275 – 11/03/2014

KB3000061 – 14/10/2014

KB3002885 – 11/10/2014

KB3013455 – 10/02/2015

KB3034344 – 10/03/2015

KB3057839 – 09/06/2015

KB3070102 – 14/07/2015

KB3095649 – 30/10/2015

Here the list of superseded updates expired stops at the first update which was presented by Dalai as speeding up Windows Update, which is KB3124000
http://wu.krelay.de/2016-02.htm

All the patches in the list are updates/patches to Windows Kernel-Mode Drivers w32k.sys

So be aware that when you avoid patches to w32k.sys, you actually slow-down your WU scans 😀

Reply | Quote

I believe this may be true. My home Win 7 x64 (Group B) system does not have KB3172605. I cannot recall whether I never installed it or installed and then later removed, but probably the former and if the latter it was removed at least three months ago. In any event I can absolutely confirm that when I last ran a Windows Update check on December 1, 2016 it took a bit over two hours.

I ran a WU check about an hour ago as part of my somewhat belated Group B application of the December patches and was shocked when it took less than five minutes. The only change to Windows on the system between the two scans was the application of the December security-only patch.

Reply | Quote

Since 29 July 2015, the main AGENDA of M$ hv been to push Win 7/8.1 users onto Win 10 but overall they hv failed to achieve this(= 1 billion Win 10 devices by year 2018).
……. So, it seems M$ hv given up on this agenda n finally n reluctantly the fixed slow n/or broken Windows Update for Win 7/8.1, esp after a clean install. This problem coincidentally had begun in Aug 2015, ie soon after Win 10 had been launched by M$.
.
Also, it seems, with the Oct 2016 monthly Patch Rollups system fully in place(= woody’s Group A, Group B n Group W), M$ now feel “secure” enough about their other AGENDA, to finally fix slow and/or broken Windows Update for affected Win 7/8.1 users.
……. This other AGENDA of M$ might hv been to get their hidden Telemetry updates(= NSA spyware.?) onto Win 7/8.1 cptrs. IOW, all the monthly Rollups or WUA might contain hidden Telemetry updates, eg KB3172605 n KB3212646.

Reply | Quote

And Volume Z still doesn’t how to make Vista to update efficiently after all his experience and pretending to understand anything.
When will Volume Z provide own results, beyond presenting links here and there, confusing Office patches with Windows patches and confusing the 2 complete different issues which are the logic and effectiveness of the calculations built in the Windows Update Agent and the supersedence of updates?

And to say “No users without KB3172605 still have had good updating experience since December 2016 rollup release and installation. It’s just plain wrong.” just shows how clueless the author can be against all the evidence.

Reply | Quote

Nice 🙂

but i think KB3185911 is just one of the supersedence chain
KB3124000 is the base for the chain, all older updates it replace match (100%) the list of expired updates you posted
http://www.catalog.update.microsoft.com/ScopedViewInline.aspx?updateid=7e19592c-43f5-443b-98df-0a705035f927

meaning, KB3124000 is the last update in the chain that will be offered by WU if all newer updates are hidden

Reply | Quote

Test 6: wuaueng.dll v7.6.7600.320. Reverted to same snapshot used in previous tests, and then did what abbodi86 suggested. I ended the test after 35 minutes while Windows Update was still checking for updates.

Reply | Quote

Test 7: wuaueng.dll v7.6.7600.320. Reverted to same snapshot used for the other tests. Installed KB3185911 because other comments for this post mention that this might be a “magic patch.” I ended the test after 30 minutes while Windows Update was still checking for updates.

Reply | Quote

This month I finally applied KB3172605 to three machines that were being very difficult about finding their updates – 36+ hours with no results this month. After reboot, each of these three machines then found the updates almost immediately (<10min). I then asked all others in our group to apply KB3172605 if they were seeing major delays in scanning for updates. The two other machines where KB3172605 was applied (and had been very slow before) also rapidly completed their scans for updates. Note that six other machines do not have this update and presented their users with the updates by Thursday or Friday after patch Tuesday. Thus I would tend to confirm this is a fix for slow update scans, but I'm leery – I will wait a few more monthly cycles to become convinced.

Reply | Quote

I can confirm @MrBrian tests regarding v7.6.7600.320, it get hit by the slowness issue after installing some updates
the slowness period varies depending how many not installed updates

for me, i installed all non-superseded updates in my list, excluding only Monthly Rollup and KB3172605/KB3125574/KB3138612
the scan get stuck for about 7 minutes only

afterwards i installed KB3138612, and then no slowness occure at all, scan result is shown ASAP

i guess v7.6.7600.320 still needs another supersedence chain to be resolved/shorted 🙂

Summary:
– Default WUClient v7.6.7600.320 eliminate the issue on initial scan/clean install
– Latest standalone WUClient KB3138612 eliminates the issue afterwards
– The best practice is to make sure you choose KB3138612 wth the first group of updates to install through WU

Reply | Quote

Yep, KB3172605 still the ultimate solution, it never fails 🙂

Reply | Quote

Correct, KB3124000 is the base (the lowest in the chain and the one which is likely to do the same speed-up job or close to KB3185911) and all updates in the chain between and including KB3124000 and KB3185911 have not been expired. This coincide with the starting point of Dalai’s site in January 2016, but I believe this to be a rather arbitrary choice, which allows Microsoft to expire a large number of updates, but still keep few older w32k.sys versions available for rollback.
I didn’t analyse in detail, but I think there are other complex interdependencies and some of the expired updates may belong to other chains too. This can be seen by analysing the supersedence chains for the superseded updates. Those expired are superseded nevertheless, regardless of the chain analysed, at least according to the metadata associated.

Other supersedence cleanup has been due for a while, but this one just resolved was the one which was proven to be working for the last year and probably the most visible.

Reply | Quote

This thread gave me hope and I decided to try to update two Win 7 64bit SP1 machines One of them, which I have not updated since last summer, updated (miraculously) easily.
The other I bought in October with SP1 and a few updates installed.
The slow one does have v7.6.7600.320. I did not do any updates since then.
It does not have any of the updates recommended in this thread. I downloaded kb3138612. When I try to install it a window came up called “windows standalone installer”. It then begins to scan my system in the usual slow way. Any advice as to how to update the computer would be much appreciated.
Thank you.

Reply | Quote

@abbodi86
Thanks, very good summary and instructions which work for everyone’s use! 🙂

7 minutes is not significantly long when you ask those who used to experience 30 minutes + and in the worst situations never ending scans. 🙂

What I would like to understand though is what resources have been allocated to the machine with longer scan times for 7.6.7600.320 compared to KB3138612.

Reply | Quote

Running the test with low memory?
Unfortunately this is a limitation of the older agents.

Reply | Quote

Disconnect from the internet while you’re installing KB 3138612.

Reply | Quote

ch100,

I am on the same page as you concerning the page file. It’s been a long time I did research for myself when I noticed the official recommendations didn’t seem to make sense at all. Allowing a PC to take a lot of virtual memory seems like a very poor way to get reminded painfully you need to add more RAM or switch to a new PC.

What I did back then, was set my pagefile to 200mb-2000max and I never saw any of my computers go higher than the 200mb defined. Of course, I also disabled the debug file.

However, I have a question for you. Do you use a 512Mb-512Mb fixed and do you think it is better to use a fixed value? I quickly glanced at the link you provided and they seem to imply so, but they don’t say why.

My reasoning was set 200Mb because I never exceed it anyway so I don’t need more minimum, but allow growth up to 2Gb just in case because I don’t know precisely all the future peak commit load or whatever you call it of all my users. I never buy machines with bare minimum specs so I didn’t encounter any bad situation, but I was wondering if a fixed page file is better for whatever reason I don’t know and if 512Mb is really necessary if mine never grew out of the 200Mb min I set. Setting a variable 200-2000 eliminate the need to have more than 200Mb minimum for having a safe value since if ever needed the 200Mb would grow? I would like to know your thoughts about this.

Reply | Quote

Thanks Woody. I disconnected from the internet. Clicked open, which brought up a window “view and track your downloads”. There are 2 choices, open or save. If I click save it makes a copy. If I click open some sort of window flashes momentarily on my screen and then disappears. Thoughts? Thank you.

Reply | Quote

Or at least configure Windows Update for Never check for updates.

Reply | Quote

+1 🙂

Reply | Quote

Same real machine for both, 32bit/2GB

i’m pretty sure the amount of ram/cpu has nothing or minimum effect on the “stuck” issue

Reply | Quote

You need to Save, then disconnect (or set to Never Check), then run.

Reply | Quote

@Alex Eiffel
I use 512MB min-max. Like you, I noticed that 200MB is enough in most cases, however I tend to set a roughly double value for added peace of mind. There are rare cases when that amount is exceeded even on machines (servers) with large amounts of memory, but they are machines not restarted in a long time, 1 year or more perhaps, and even so, they never BSOD, just pop-up and log in the System Log. Most of the times they recover, but that event in itself would be a reminder that it is time for a reboot.
That value is something that I reached by using Performance Monitor built-in Windows and not found anywhere else, except for your current post and possible another one in the past if I remember well. 🙂 It is reinforcing to find out that we both reached the same value. 😀
Setting a variable value tends to create page file fragmentation, but I don’t know how important it is.

Other considerations:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSession ManagerMemory Management
DisablePagingExecutive DWORD
Default 0
Some recommendations to set to 1. I tried and never noticed any difference, so I leave it on default as it is safer.
The idea is that setting to 1, it forces the kernel (or part of it named “executive”) to reside in memory instead of the page file. I think that with enough RAM it doesn’t matter and this recommendation may have had value in the Windows 2000 times on machines with 64MB RAM.

I read discussions that on systems taking large amounts of cache from the physical RAM, e.g. File Servers or even regular machines installing a large amount of Windows updates at a time, part of the memory which would normally be in stand-by and never released unless required by other process, would after a while be moved by Windows in the page file and as such, a larger page file would be useful. I could not reproduce this behaviour. Unfortunately, the stand-by memory is never released instantly and it is always good practice to have at least 2 GB RAM available as true “free”, not in stand-by, which means used by cache. This is visible with Resource Monitor on the RAM tab. The stand-by memory can be released only after a restart or by using the utility RAMMap from Sysinternals. There is also DynCache from Microsoft which may help, but this is recommended only in most critical situations and not recommended in general.
So keep the page file to 512-512 or if it works for you 200-200 and you should be fine. To clarify for those less experienced with this area, the debug file should be also set to None or Small.

Reply | Quote

Download the update and save it.
Go to Control PanelAdministrative ToolsServices, scroll down and highlight Windows Update Service, and in the top left click “Stop,” you will stop the Update Service.

If you do this, then double click on the update you downloaded, it has been my experience that you do not have to disconnect from the Internet. It will start installing without the long searching.

Reply | Quote

I see 2 GB in use (probably only committed) only by svchost.exe and after a while TrustedInstaller.exe drifts close to 2 GB.
This is on 64-bit machines.
With KB3138612 and few others earlier) or KB3172605, I see only few hundreds of MB used by svchost.exe, which may have an effect. Also the CPU usage is reduced with the latest agents.

Reply | Quote

Yes. All of my tests were done with 1024 MB of RAM allocated to the virtual machine, except for Test 5.

Reply | Quote

Thank you Woody and PKCano. I tried both of your solutions. Unfortunately neither worked. Disconnecting from the internet still brought up the standalone installer search bar. And stopping Windows Update Service led to the flash of a screen that disappeared again without engaging in any installation. Strange.

Reply | Quote

Sometimes I’ve gotten that flash of screen before. I’ve gotten past it by right clicking the installer and selecting run as administrator… even when I am already running as administrator. For some reason, that has worked.

Reply | Quote

Good news. I decided to investigate the flash of a screen that then disappeared. I thought it might have something to do with internet explorer, which had some checkboxes for downloads. I enabled almost everything, disabled private browsing, etc. Then I tried once again to install. Clicking open did nothing new but when I chose standalone installer it scanned for about a minute and then installed the file successfully. Now I am running Checking for Updates. Will see if it completes the scan in a reasonable amount of time.

Reply | Quote

In a few minutes the scan found 158 important/critical updates, using over a gb of memory. Any recommendations as to how to proceed? I may just bite the bullet and install everything but if there is something wiser to do please let me know. I am shocked and pleased that the scan was so fast!

Reply | Quote

I understand what you’re saying @messager7777777,
and yes, I realise that Windows’ Users are considered beta-testers….but my thinking was mainly concerning the way all these patches/updates have been compiled. With so many of them that continually bust/brick/break people’s computers so regularly – one wonders what is behind all that besides these so called boffins. As I said recently there has been some controversy about the way AI has been used to run certain number crunching programmes that has led to lots venting their frustration. It’s just a thought that occurred to me….. and in my mind you can never ever underestimate that HUMAN TOUCH. LT

Reply | Quote

@ hjf ……. I’m assuming that u bought yr Win 7 SP1 cptr 2nd-hand in Oct 2016. So, maybe, u need to first run a full antivirus scan, run chkdsk, do a disk cleanup n disk defrag(also disable auto-scheduled disk defrag), b4 doing the manual install of the KB.
……. Last resort is to do a clean install of Win 7 SP1.

Reply | Quote

Comments are slightly confusing. Some saying to apply, others saying not to.

What is people’s experience with KB3020369?

We have KB3172605 and KB 3138612.

Windows Malicious Software Removal Tool – December 2016 (KB890830) seems to be preventing other updates from updating. Thought maybe something here would assist in getting it to work.

Ran for 94 Hours but still says “Downloading” So looking for assistance.

Reply | Quote

I think the last security only update I installed on win 7 64 was October’s. Did November/December security updates get the green light yet?

Reply | Quote

Nothing confusing.
Follow Woody!
Only if you are interested in further details and other people’s points of view, then read the comments and participate.

Reply | Quote

One extra detail:
In December 2016, Microsoft expired IE9.
This resolved an old error in the WindowsUpdate.log related to an obscure Irish Language Pack bundled with IE9.
The error was
WARNING: Failed to evaluate Installed rule, updateId = {189A8F50-0C3A-4FDF-8BC2-BC23A3EB11FB}.102, hr = 80242013

https://social.technet.microsoft.com/Forums/windowsserver/en-US/6818b28f-0cd0-4591-88f1-6b34c398ffdb/update-stuck-in-wsus?forum=winserverwsus

Reply | Quote

Follow the instructions here:

https://www.askwoody.com/2017/windows-7-8-1-patches-are-up/comment-page-1/#comment-114578

Reply | Quote

You can also read my info a couple of comments above the link above

Reply | Quote

@ hjf ……. Good for u that yr problem has been solved. So, maybe it’s better to use Firefox or Chrome, instead of IE, to do this.

Some hv advised to install only about 25 updates at a time in order not to overload the cptr, unless u hv 32GB of RAM n the latest high-end cptr.
……. U should research a bit about the 158 pending updates b4 installing, eg should avoid the unnecessary WAT update, KB971033, n Telemetry updates, eg KB2952664.

Reply | Quote

Well put. I encourage different points of view! Windows is very complex. There’s no one “right” way.

Reply | Quote

It was too late to get advice here, so I went ahead and installed all 158 updates last night. Went smoothly though it took a couple of hours. Computer appears to be working fine. As far as Firefox or Chrome, I downloaded kb3138612 via Chrome. It was changed into a Microsoft file when I clicked open. Going in and changing parameters in IE seemed necessary for the computer to allow the download to be installed. The rules governing how MS files are handled may be embedded in the properties section of IE. I certainly am no expert at this, but trial and error appeared to work this time.

Reply | Quote

Good on ya.

Reply | Quote

Well done @hjf
This is the best way to learn about your system, by combining information from others with own ideas and experimenting. 🙂

Reply | Quote

Good post, only that 32 GB is a bit overkill! 🙂
I think for most people, anywhere around 6-8 GB is good enough for regular use of Windows 7 (64-bit).
I wouldn’t say no to a 32 GB RAM machine though, based on the assumption that I would run few virtual machines simultaneously on top.
I have 16 GB RAM and i7 on a 6+ years old machine which is not bad at all.
For those who are interested in upgrading RAM, although I don’t like to advertise brands, one of them was outstanding for me few times when I purchased from them and that one is Crucial, outstanding for everything, quality, information, support, prompt delivery.

Reply | Quote

don’t kidding me

few time ago I give this solution on comment on woody webside

probably “Canadian Tech” rewrite what I wrote some time ago on this website and long time ago on others

https://www.askwoody.com/2016/still-no-answer-to-the-source-of-win7-slow-scanning/comment-page-2/#comment-114005

Reply | Quote

Great answer! Thanks.

One thing. If I understand correctly that variable page file problem could be fragmentation, it would actually only occur if the initial amount of 200mb would actually be raised from the initial unfragmented amount? So having a 200-2000 would be fine until it gets higher than 200, in which case the only benefit of 2000 vs 200-200 would be to not abruptly maybe shut down a process that could have continued with more RAM, but with enough RAM virtual memory for the user to notice something is wrong because the computer would become very slow.

Once you notice the problem, you can either add RAM or fix it and then reset to 200-2000, effectively restarting the page file to the lower value. Do I make sense?

Reply | Quote

It is old news. This thread is not about Canadian Tech, but Microsoft expiring updates which have fixed the slow scanning for new Windows 7 installations without any need for manual patch installations.

Reply | Quote

Yes Alex, you make sense, absolutely.
My understanding is that with the default configuration, the page file does not get deleted at shutdown. There is a Group Policy for that purpose which is recommended in highly secured environments, but this would dramatically increase the shutdown time when configured.
If the page file does not get deleted/recreated at reboot, if in a previous session had increased and become fragmented, it will stay as such for future sessions. I don’t know how much impact this may have and how critical it is. Sysinternals has a utility named contig which may help with this issue.
https://technet.microsoft.com/en-us/sysinternals/contig.aspx
I used to use a little software which I think still works
http://www.dougknox.com/xp/utils/XP_PageFileMon.zip
This software can be set to run as shutdown script and log the size of the page file for the session. In the long term, you would be able to see a pattern.
To conclude, 200 MB of disk is not a huge amount of space and you can opt for a safer value which I indicated to be 512 MB, but you may also choose 1024 MB or other value that suits your applications, because this is relevant too.

The only value that is out of discussion is 0.

Reply | Quote

Great!

Now I just hope that most normal users with normal needs and a good amount of RAM (maybe 8GB to be safe?) will just follow this advice and set 512-512, 200-512 or 200-2000 instead of the idiotic default value, especially for those who uses an SSD with little space on it. You need to set the debug file to none or small: Windows+Break (or right-click then properties on My Computer), Advanced system parameters, Startup and recovery, then you can select none or partial from the drop-down list. Sorry if the names are not exact, I translate on the fly from a French version.

Disabling the hibernation file for those who don’t use it can save a lot too. But be warned that if you do, you loose the Fastboot or Faststart thing (I don’t remember the exact name of that feature that saves a copy of your RAM to the HD for “faster” boot), but anyway in real life I found this features is often slower than not using it and I don’t like the idea of not having a clean restart anyway, so I always deactivate it, especially with an SSD. So for those who don’t want the hibernation file and don’t need either hybrid sleep (which I don’t think is useful at all on a desktop), you can use the command line in admin mode and type
powercfg -hibernate off to destroy the file and completely deactivate hibernation. You can still uses the sleep mode that takes almost no power but just maintains the RAM without writing it to the disk prior to going to sleep. As always, if you are not sure about what you are doing, don’t follow this advice and then complain.

Reply | Quote

ch100:

How would I go about determining which Vista SP2 updates, if any, have been recently expired by Microsoft?

User Rogerinfrance just posted a list of “ExcludedList-Superseded” updates in the MS Answers thread “Updates not working, it has been searching for updates for hours” (https://answers.microsoft.com/message/38395e3d-00b3-49e1-ab66-0da474a617e5). I have no idea where that list came from but it would suggest that some of the older Win32K.sys updates for Vista SP2 from Dalai’s archived web pages [e.g., KB3078601 (rel. 18-Aug-2015); KB3109094 (rel. 07-Dec-2015)] have recently had their status changed to superseded and/or expired.

I don’t see any information in the Package Details on the Microsoft Update Catalog for either KB3078601 or KB3109094 that would indicate that the Vista SP2 versions of these updates has been superseded or expired.

Reply | Quote

It most be his own list, because i only founded just 3 expired updates for Vista, others are either still valid or not even for Vista

if update is expired, it does not show in MU catalog search for the specified Windows version

i.e. the above updates list by @ch100 is expired for Windows 7, but Vista and Embedded Standard 7 still got it

Reply | Quote

@lmacri
In WSUS you would see all superseded updates in a graphical user interface. This is not available to everyone, although everyone can install a 180 days trial of Windows Server which include WSUS as a role. But this also require advanced Windows Server knowledge for configuration.
The other option which is equivalent, but require too much work is to go through the Catalog for each individual update.
I am sorry, but I am not monitoring Vista at all and haven’t used Vista in more than 6 years and I cannot provide specific information about certain patches, but what I am telling you here should help a lot.
If you don’t have other trusted information available, you can still use Dalai’s web site as the best around.
Superseded/expired updates are not harmful if they are installed, so you do not have to do anything specific about them. Their internal components are replaced by the newer updates which replace them in full or only in part. The only side effect of their existence is that they slow down scanning until a higher level update is installed (which Dalai proposes and does it so successfully through his web site). The WU scanning is made complicated by the existence of the superseded updates which need to be calculated in the process. Microsoft is reluctant to remove/expire superseded updates because technically they are valid and some people might have difficulty with certain updates, in which case they may need to install older updates, the so called “next best”. There are also people, mostly sysadmin types, who follow only documentation to the letter and install only when needed for specific fixes and such documentation in general refers to the first ever released patch for a specific issue, but not to the follow-up patches.

If you still have slow scanning, I propose you an alternative procedure which always works.

– Set WU to Never check for updates.

– Download Windows Update MiniTool and select Ïnclude superseded”. Major Geeks has the latest version but there are a number of other sites hosting it with full details about how to use it. It is however not complicated, you don’t need to install and self-explaining. Selecting Include superseded avoids all the calculations, is very fast, but will present you with all updates available, including superseded.
You have the choice to install everything, which means probably 500+ updates and Windows will take care of the order of installation or install everything available starting with the last month and after that the previous month, and again previous month and so on, until you will reach such a situation that you will have most higher level updates and your scan will no longer be slow.
If you are interested in selected updates based on certain criteria like telemetry which is discussed often here, I am not the best person to advice because I consider that people who have such criteria in mind, should not use Windows at all and use a product which they fully trust. Antivirus products and backup products are far more dangerous from a snooping perspective because of the level of access they have and need to have to the system, even higher than the owner of the system.

Reply | Quote

We are absolutely on the same page. 🙂 🙂 🙂

Reply | Quote

@Alex Eiffel
One more tweak you would like to try, if not tried already.
Under the same tab where you set the page file, set Processor Scheduling for Background services. This has the effect of allocating equal time slices to all processes with the same priority, which is normal in the current machines with many processes running simultaneously.
That setting as is out of the box is obsolete, since the times when multitasking was slow and the idea was to make the interactive foreground process faster.
Windows Update is a background process among others and will take likely much longer when the priority is set for Programs.

Reply | Quote

Some are expired only for Windows 7 64-bit version.
The best approach as it has been discussed many times is still to install manually KB3020369 & KB3172605 and with good effect (not a requirement, but to speed the scan even more), either December/January rollup or at least KB3185911.

Reply | Quote

I can happily say the slow update issue has been solved for me. All 3 of the W7 machines in my house went from 40+ hours to less than 10 minutes to search for updates.

The only non security updates these machines have are what was already on the OEM disks or what Acer had already had installed in 2015.

Unfortunately, it seems W8.1 hasn’t been fixed yet. My 8.1 machine is on hour 22 right now…

Reply | Quote

Hi ch100:

Thanks for your detailed response about Windows Server and the Windows Update MiniTool (and kudos to abbodi86 for their input as well). I’ve actually been using Dalai’s workaround at http://wu.krelay.de/en/ since June 2016 to keep my 32-bit Vista SP2 machine up-to-date, and every month my Windows Updates have run to completion in a reasonable amount of time and successfully installed my Patch Tuesday updates.

My main concern now is that there is one user in the MS Answers forum who repeatedly claims that Dalai’s recommended KB3078601 (rel. 18-Aug-2015) and KB3109094 (rel. 07-Dec-2015) were both superseded by KB3191203 in October 2016 – see his latest post today in m#l’s thread “Updates not working, it has been searching for updates for hours” (https://answers.microsoft.com/message/fe412356-1413-42b5-9d71-5ee4460f1f07). I’ve checked the Package Details for all three of those updates for Vista SP2 in the Microsoft Update Catalog and can’t find any evidence that KB3078601 or KB3109094 have been replaced (superseded) by a newer update. I hope I’m not interpreting the information posted in the Package Details for these updates incorrectly.

I found your comment that internal components of superseded updates “are replaced by the newer updates which replace them in full or only in part” to be very interesting. I wonder if “only in part” is the reason why Microsoft does not recommend Vista’s KB3191203 as a full replacement for KB3078601 and/or KB3109094 in the Microsoft Update Catalog.

Reply | Quote

no…, no, it is not just him, at least as far as he seems to be saying we should not yet break out the champagne bottles. Might wait to see what happens over the next few months.

Regards,
shopper55

Reply | Quote

You don’t know how to make sense out of Dalai’s list. You don’t know in which way installation of a magic patch is effective. I know how to determine which updates trigger the issue in Windows Vista, and the list definitely includes MS Office patches. I know what the current continuation of Dalai’s list looks like. Your perception of the issue does not contain conditionality of patches, because you don’t consider magic patches triggers of the issue.

Not a user was able to fix the issue in Windows 7 without KB3161647 before it was solved by Microsoft – other than applying temporary workarounds.

“KB3185911 is the mother of all speed-up patches”. That insight is both too late and incorrect. It used to be a magic patch aka trigger like any other, and you’ll have a hard time installing it after the January Monthly Rollup.

Reply | Quote

The first update presented by Dalai was KB3078601.

http://www.planet3dnow.de/vbulletin/threads/423516-Windows-Update-funktioniert-nicht?p=5037886&viewfull=1#post5037886

You cannot slow down anything now that the issue has been fixed. You already couldn’t when KB3161647 was in place.

Reply | Quote

It is possible, but I don’t think the Answers site is quite at the high level at it appears to be to some people.
So I am suggesting that what you found in the Catalog to be authoritative against the information found on the Answers site.
Dalai’s site proved to be very reliable and absolutely accurate for more than 1 year and as such I think you should give it credit for your good experience with Windows Update and keep patching regularly to keep your updating mechanism in top shape.

Reply | Quote

Also amazingly, Windows 2008 R2 equivalent updates have not been expired 🙁
I suppose the idea is that the server admins can cope with hardship better and complain less 🙂

Reply | Quote

Maybe it is the right time to actually install the non-security patches.
Why do you keep patching if not doing it properly?

Reply | Quote

(Or they’re getting paid more to suffer.) 😉

Reply | Quote

🙂

Reply | Quote

Just manually install KB3138615, it fixes the issue for W8.1 if you do not want July rollup KB3172614

Reply | Quote

Or they should know how to apply the known workaround/fix manually 🙂

Reply | Quote

He is right, but there is still a twist

KB3078601 and KB3109094 are superseded on the components level by 3 updates together, not just KB3191203
KB3191203 + KB3203859 + kb3205638
MU Catalog only reflect the supersedence if its replaced by one update only

on the metadata level (which is the cause of culprit), KB3078601 or KB3109094 is still needed to resolve the supersedence chain for old updates and shorten the calculation time for WU

i suggest KB3078601 because it has more updates in its chain

Reply | Quote

Hello, On Woody’s suggestion I updated the Win 7 computer and using the security only update and MRT. After hiding the rollup the KB3177467 update was offered again. Woody, you mentioned very little on this last year, should we install this if we are having zero problems getting updates? One to three minutes is normal for our “check for updates”. I am afraid to install the KB3177467 because I am having no issues at the moment so, “if it ain’t broke…”. Thanks Woody for all the great help you give.

Reply | Quote

Would you mind elaborating as to what I’m “…not doing properly”.

Reply | Quote

Same here – did exactly what win7user did and saw KB3177467 offered again as an important update. Have not installed it. Looks like it was initially offered back in October but no one said much about it.

Reply | Quote

Hi abbodi86:

Thanks for that. I didn’t know the Microsoft Update Catalog will only reflect the supersedence if it’s replaced by a single update. I recall reading somewhere that one of the AskWoody MVPs might be contributing a KB article on supersedence chains when the new Woody’s Lounge goes live so I’m looking forward to learning more on this topic.

That also gives me greater confidence that the current list of six Windows kernel-mode driver (Win32K.sys) updates and graphics component updates I’ve listed at https://answers.microsoft.com/message/1ef00080-91e9-4ffa-a5a3-92f6ecd69c32 (which are based on Dalai’s recommended speed up patches) are still a good combination for speeding up Windows Update on a computer with a clean re-install of Vista SP2. If I dropped KB3109094 from that list it sounds like I might need to replace it with KB3205638 (KB3191203 and KB3203859 are already recommended), and I don’t want to start tweaking that list unless there’s a good reason to do so since it seems to work well for users with a clean re-install of Vista SP2.

One last question (I hope). Is that metadata on supersedence at the components level only available if you have the Windows Server installed and use WSUS, or is that information available to anyone?

Reply | Quote

It is available in the Catalog for each patch.
In WSUS you have it visible in one go, but otherwise it is exactly the same.

Reply | Quote

No, components level supersedence does not have a real metadata, it is determined by the CBS evaluation (the TrustedInstaller.exe thing)

it is reflected in this registry path, each update has its own sub-key based on CBS package name
“HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionComponent Based ServicingApplicabilityEvaluationCache”
ApplicabilityState = the components level state
7 = applicable, not superseded
5 = applicable, superseded
0 = not applicable

the ApplicabilityEvaluationCache key is not persistent, it gets deleted with each update install/uninstall, and recreated with each WU scan

Reply | Quote

Side note
how do you get specific reply url in Answers site?
i only can copy the whole thread url

Reply | Quote

I misunderstood the OP enquiry then.
Not to confuse the OP, just in case:

– Component level supersedence is the one presented by @abbodi86. The components are not the patches, but their internal parts. This is actually the true supersedence in the technical sense.

– The supersedence visible in the Catalog and WSUS and which is taken in consideration by Windows Update (the scanning engine) is at patch level. However, this is not the true supersedence, being mostly for the benefit of Windows Update and largely cosmetic, although it tends to mirror reality in most cases.

Reply | Quote

“Tip of the Day: CBS Servicing States Chart – Refresher” – https://blogs.technet.microsoft.com/tip_of_the_day/2015/10/12/tip-of-the-day-cbs-servicing-states-chart-refresher/

Reply | Quote

Thanks @MrBrian
great tip 🙂

Reply | Quote

@MrBrian
A bit complex for most purposes, but for those interested, it is very good info and not easy to find, unless knowing what to ask Google. 🙂
Thanks @MrBrian and @abbodi86

Reply | Quote

Hi abbodi86:

The simplest way is to use the solution posted by Community Moderator Don Varnu in i3v’s thread “How to get a link to specific message?”(https://answers.microsoft.com/message/c4a6a3e8-3bb5-4a25-b9f0-0e4422f985cd). Click the orange RSS Feed button near the top right of each page to open a summary of the last forty posts in the thread. Then right-click the hot link (thread title) immediately above the post of interest and choose Copy Link Location. The direct link to that post that should be in the form https://answers.microsoft.com/message/&#8230;

For longer threads where you need to go back more than forty posts, it’s more complicated. Right-click anywhere on the webpage where the post of interest is located and choose View Page Source to view the HTML source code. Each post on that page will have it’s own unique message ID so I usually search for a keyword or phrase used in the reply by the author [e.g., “second post (by Anil Kumar B)”] to jump to the correct section of HTML, and then scroll up a few lines and look for the associated message ID (e.g., msgid=”c4a6a3e8-3bb5-4a25-b9f0-0e4422f985cd”). The last step is to append the alphanumeric message ID to the URL (e.g., https://answers.microsoft.com/message/ + message ID = https://answers.microsoft.com/message/c4a6a3e8-3bb5-4a25-b9f0-0e4422f985cd) to create the direct link.

Reply | Quote

So THAT’s how you do it. Always wondered about that.

Reply | Quote

While it is right that KB3078601 and KB3109094 are superseded by KB3191203 + KB3203859 + KB3205638, there is an alternative to this. It’s KB3185911 + KB3191203 + KB3203859. And it doesn’t stop here. It’s also KB3185911 + KB3191203 + KB3164033, KB3185911 + KB3191203 + KB3140735 and KB3185911 + KB3191203 + KB3087039 – due to the interchangeability of KB3203859 with KB3164033, KB3140735 and KB3087039.

So, since it is not true that KB3078601 and KB3109094 are generally required, certainly not with CRITICAL 3185911, 3191203, 3087039-3203859 installed, they’re GENERALLY OBSOLETE.

They being obsolete may not fit your metadata cause theory, but I can’t help it. Any update that doesn’t apply to the OS (e.g. by supersedence) doesn’t apply to the update issue.

Regards, VZ

Reply | Quote

Mentally bookmarked 🙂

thank.

Reply | Quote

So the scan time is reasonible without KB3078601 and KB3109094 installed?
i only talked based on experience with Win7’s KB3078601 😀

Reply | Quote

Sure. It’s been reasonable in Vista without KB3078601 and KB3109094 since October, which is different from Windows 7. KB3078601 has been a trigger in Windows 7 from the issue’s first day until its last.

But I guess we just learned KB3185911 is interchangeable with KB3205638. 😀

Reply | Quote

The December and January Rollups were no different to those of October and November issuewise. They themselves were those month’s offending patches.

Reply | Quote

+1. Kudos to abbodi86, MrBrian and ch100 for all the great info.

Reply | Quote

Good Will Hunting 🙂

Reply | Quote

I suspect that test methodology might explain some differences in observations. From what I can gather from Volume Z’s various posts in the MS Answers forum, his test bed is a Vista SP2 VM that is hosted on a 64-bit machine (I still don’t know the CPU speed and amount of RAM allocated to the VM). Many of his tests are performed by uninstalling selected updates on a patched Vista SP2 machine and then running Windows Update to see if it hangs. I believe that’s why he previously (and incorrectly) concluded that KB3078601 (rel. 18-Aug-2015) and KB3109094 (rel. 07-Dec-2015) were both superseded by KB3191203 in October 2016 – because he didn’t take into account that other updates already installed on his computer were contributing to supersedence. See his 21-Nov-2016 reply in response to my request at http://answers.microsoft.com/message/a08ef520-c6ba-401d-b248-e630f8a4a0a3 for details on how he tests supersedence.

Testing this way might produce very different results from what a user with a typical 32-bit Vista machine (CPU@1.8 GHz, under 4 MB of RAM) would see if they installed a small subset of five or six Windows kernel-mode driver (Win32K.sys) and graphics component speed up patches on a clean re-install of Vista SP2 that was missing ~200 updates dating back to May 2009.

Reply | Quote

I’m running 32-bit. 🙂

OK, so 3078601 and 3109094 weren’t superseded by 3191203 ONLY. But they WERE superseded in October, and 3191203 CONTRIBUTED to their supersedence.

Whatever way you look at it, I was right at KB3078601 and KB3109094 being obsolete as of Patch Day October when applying all other required updates.

Which is obsolete ENOUGH. 🙂

Reply | Quote

Hello Woody, Poster W72020 and I have not seen any advice on installing KB3177467.

One to three minutes is normal for our “check for updates”. I am afraid to install the KB3177467 because I am having no issues at the moment, so “if it ain’t broke…” Thanks Woody

Reply | Quote

There shouldn’t be any problem installing KB3177467.

1 user thanked author for this post.

jburk07

Reply | Quote

KB3177467 is a patch from September 2016.
You cannot reasonably expect a list of all 500+ patches released for Windows 7 with Service Pack 1 and many more before Service Pack 1 with recommendations for each, years after their release.
The MS-DEFCON system says it all.
If MS-DEFCON goes to 3 or higher, then all outstanding patches to date, including current ones have to be installed.
Individual users may have specific requirements, but in such a case they should maintain their own lists with what THEY decided not to install.

Reply | Quote

ch100, you’re absolutely right, it’s not reasonable to expect recommendations for each and every patch that’s released. It’s just that win7user and I had concerns about KB3177467 because it seemed to be withdrawn in the past few months and then re-offered suddenly. But I know all of us appreciate Woody’s and yours and all the other experienced users’ advice on this forum. Truly indispensable resource!

1 user thanked author for this post.

jburk07

Reply | Quote

@Woody:

Is there something amiss with the e-mail notifications?

I did get into this subject and saw that the above message was posted. Everything referenced on the right side of your website appears to only be referring to Windows 10 issues (I’m NOT Windows 10).

I’m looking at one posted today (above), and I did not receive a notice about it.

I haven’t received anything for any of my subscriptions.

???? I have quite a few subscriptions but no notifications today at all. Please help. Thank you.

Reply | Quote

@Woody:

I just now finally received an e-mail which notified me of this one.

Don’t know the reason for the lack of e-mail notifications. I used the link from the postings on the R. side to get into this subject.

I normally get numerous e-mail notifications, so it’s a mystery to me.

Hope and pray that if there was a problem that it was repaired. I’m happy that I did get this notification.

Really miss those e-mail notices and hope I’m not behind. Thank you for all of your help, and especially your website & InfoWorld. 🙂

Reply | Quote

It’s probably because I edited the original post to change the posting date. That had the effect of moving the post to the top of the site. There was a small Update at the end.

Reply | Quote

@Woody:

I can imagine how busy you are with the Windows 10 “activities”. You are “One in a Million”!!!

Thank you so much for “being there” for all of us! 🙂 🙂 🙂

Reply | Quote

KB3177467 was never withdrawn
it’s an exclusive update, only get offered if there are no other pending updates

Reply | Quote

Seems, Win 7 Update has recently been fixed by M$ bc after about 9 months of broken Windows Update, ie since April 2016, today my Win 7 SP1 cptr which had ran well since its purchase in 2013, auto-magically is able to update via Windows Update.
……. I did not pre-install KB3020369 n KB3172605 to get Windows Update working again = my Win 7 SP1 cptr is still using Windows Update Agent/Client version 7.6.7600.320.
……. Of course, I hid all the monthly Patch Rollups from Oct 2016 onward = Group C/W.
.
Recap: ……. Bought my Win 7 SP1 cptr in 2013 n it ran well.
With release of Win 10 on 29 July 2015, I began to hide GWX KB3035583 n Telemetry updates, eg KB2952664.
In April 2016, my cptr could not update anymore via Windows Update. Had to manually install security updates via M$ Download Center or Update Catalog.
In June 2016, M$ removed all KB updates from Download Center. So, I was forced to use IE11 at Update Catalog to manually install updates.

Feeling pi55ed at M$, in Aug 2016, I moved to Linux Mint 17.3 via an external USB hard-drive n kept Win 7 SP1 on my cptr in cold storage – until recently, ie when Win 7 Update got “fixed or unfixed” by M$.
.
I think a clean install of Win 7 SP1 should also hv no problems with Windows Update.

Reply | Quote

KB3177467 is a “special” update, in the sense that it is offered only when the backlog of updates has been flushed, either by installing everything else on offer, or by hiding everything on offer, which is very poor practice, for reasons detailed elsewhere.
KB3177467 is an “exclusive” update.
What is more unusual, but fully explained, for a new installation or an installation which is missing KB3020369, this one is not re-offered, because it is superseded by KB3177467. But at the same time, KB3177467 is not offered because it is exclusive. So the user ends up with missing one of those 2 essential Servicing Stack Updates, without understanding why is it so.
This shows even more the importance of being fully patched, otherwise those who chose to install selectively, regardless of their considerations, would have to understand all those tiny details and interdependencies.

I will repeat here for the last time my recommended order for installing immediately after a clean install. This applies to incomplete patched systems as well. Reset the SoftwareDistribution folder first, if any updates were hidden in the past.

.NET Framework 3.5.1 (this is a component which is installed by default on some editions)

.NET Framework 4.6.2

KB2533552 – the original servicing stack update (named Windows 7 Service Pack 1 on Windows Update as it is the last bit of it, not packed with the ISO). Can be installed as a single update on Windows Update.

Internet Explorer 11 from Windows Update – will install all the required pre-requisites

KB2574819 (pro and above)
KB2592687 (pro and above)
KB2830477 (pro and above)

KB3020369
KB3138613
KB3172605

Everything else coming on Windows Update.

KB3177467 will be offered last.

1 user thanked author for this post.

jburk07

Reply | Quote

Thanks again, ch100 – this is very clear and helpful.

Reply | Quote