Still no answer to the source of Win7 slow scanning

Topic

New Reply

It’s an interesting question: When did the Win7 update scan slowdowns start, and why? ch100 has been running extensive tests, starting with Win7 SP1,
[See the full post at: Still no answer to the source of Win7 slow scanning]

Reply | Quote

Replies

Unfortunately Woody I’m not set up to do such testing. However, with all the bright people working on this and no solution in sight, we should seriously consider the possibility that MS is doing this on purpose to aggravate Windows 7 and 8 users and herd them to Windows 10 and that they could be “moving the goalposts” to prevent a solution.

MS has already proven with W10 that they are not above using such low-life tactics to get what they want.

Reply | Quote

“But the Win7 update scan slowdown has led to the loss of hundreds of millions of work hours”

But added hundreds of millions of leisure hours for people who just had to sit and watch their screens doing nothing?

” – and sucked up enough electricity to power a small city.”

How do you know? Where’s the meter?

Reply | Quote

Lesseee… 1 billion machines stewing for 3 or 5 or 7 hours, once or twice a month, for three or four or six months.

Lemme crank up the back of an envelope. Say the PC soaks up 100 watts while searching (it’s spinning at least one of the cores up pretty high). Five hours, once a month, for four months. 2 KW for one PC.

1 billion Win7 PCs, say a tenth of those run Windows Update (maybe overstated). Is that 100,000,000 * 2 KW, which is 200,000 MW? Or did I slip a decimal point or two?

Yeah, I figure that’d power a small city for a year = roughly 50 MW.

Most people who get stuck in the Win7 update scan can’t do much more than sit back and wait for it to finish. I hear lots of complaints from people who say they can’t do anything with their machines. Even those who can work with one core maxed out are going to get a, uh, suboptimal experience.

(Good to see you back.)

Reply | Quote

For those who started with an d are sitting and waiting, would not it be advantageous to shut wu down and continue working? Are is common sense left the human race?

Reply | Quote

Why do you assume that ALL Windows 7 PCs suffer from slow updates? I support thousands of Windows 7 PCs throughout the US and Canada, and I haven’t heard of a single instance of slow Windows Updates causing any problems amongst those, even after reinstallations of Windows 7.

Reply | Quote

You misunderstood me 😀
i didn’t say KB3095649 broke WU, i said it’s the first version of win32k.sys that started to temporary fix WU slowness

the source of WU slow scanning is within WU engine itself
it’s not caused or triggered by any patch

if i’m a developer or a programmer (which i’m not), i would compare these two decompiled files:
wuaueng.dll 7.6.7601.23453 from kb3172605
wuaueng.dll 7.6.7601.19161 from kb3138612
to see what’s actually changed

Reply | Quote

Without the “speedup” patch, IMMEDIATELY after MS releases the updates on patch Tues, the scan time goes to hours (or days).

In Oct we won’t have the SINGLE “speedup patch.

Ought to be interesting (aggravating, frustrating).
Unless MS fixes what they broke (on purpose?).

Reply | Quote

Saw it in May of 2015. Sustained high CPU usage, 2.5 GB of extra ram usage. Combined with unreachable microsoft DNS and windows update servers hosted in Brazil. October 2015 released the update to fix “high CPU”, it fixed only the high memory usage. June 2016 they fix the high CPU usage.

Image restore a PC with all MS updates as of first quarter 2015, no updates have a chance to install (not even updates to windows update). High CPU usage is almost immediate when checking for windows update. Something changed on the server side.

Reply | Quote

Well, that’s it for me Woody. I’ve never had any problems updating my Win 7 Ultimate 64 bit until last month. Used to be about twenty minutes for all the security patches to be downloaded and installed. As of last month, it won’t update or takes more time than I can afford to let it.I will now disable Windows Update and am not updating it anymore. I work and play with my PC so, I don’t have time to play with MS anymore. I do have a another PC with W10 on it and Rarely open it. It is a piece of crap as far as I’m concerned. I’ll just deal with whatever comes along from now on, on my own. And yes,I’ve tried those methods that are supposed to work but, no joy on this end. Thanks for all your effort and hard work. I think evryone here appreciates it immensely.
Athlonite.

Reply | Quote

Same virtual machine, trying directly on Windows Update online. After installing the agent 7.6.7600.320 which cannot be blocked with normal methods and nothing else installed (no speed-up patch manually installed), Windows Update is still stuck after 7 hours of scanning. The VM has enough memory and CPU resources to cope. There is a long list of downloaded patches in the SoftwareDistribution cached database, but after that list, nothing happens for 7 hours+.
Next, using Windows update MiniTool on a brand new Windows 7 SP1 installation coming with the original agent 7.5.7601.17514 and the scanning completes in about 15 minutes. 532 patches if I select the superseded ones to be shown. This should in theory be the full repository for Windows 7 64 bit. Normally there should be about 220 patches visible, as the superseded are hidden without a third party tool.
The only error in the log which seems to be consistent is a misplaced entry in the Windows Update database which points to an expired non-existent update, at least not the one in the database.
updateId = {818701AF-1182-45C2-BD1E-17068AD171D6}.104, hr = 80242013
The one generating the error is KB2799494 release 104 (non-existent), the existing one, superseded though is version 204. This should not and nothing indicates that this is the source of slow scanning. This update, a Security update is not in the supersedence chain with any of the known speed-up patches.

As I can see in the log it takes about 2 seconds for the Windows Update MiniTool to continue from the point where the official agent got stuck for more than 7 hours. This is a new machine and the MiniTool does not use the results of the previous scanning. And in addition, the MiniTool should use the same Microsoft agent behind the scenes, only that it directs it through APIs to do something differently I believe.

Reply | Quote

@Woody:

Unfortunately I do have the ability to set up “testing”. I wish that I did.

I did not make notes, however I first noticed the slow-down problem in December 2015. I remember because it was horrendous!

I never had any problems previously. I NEVER forgot it, and then it slowly became worse and worse, finally becoming the “searching for never-ending updates” MONTHLY NIGHTMARE.

One question with October 1st rapidly approaching:

****IS there now a recommendation that the “updates setting” be set to “NEVER”. Seems that I’ve seen a few reference to this.****

I’ve always used the “Check for updates but let me choose whether to download and install them”.

Thank you! 🙂

Reply | Quote

Aren’t we mixing up power and energy here? It’s a long time since I studied electronics, but it seems that the example PC is going run at 100 W max. however long it runs. I think that the 2 kW quoted should be 2 kW.h (kilowatt-hours) of energy (not power). So the end result would be 200,000 MW.h.

A 50 MW city would consume 50 * 24 * 365 MW.h in one year which, according to my calculator, would be 438,000 MW.h (assuming that the city ran at 50 MW throughout the day). Of course if the assumption is that it only consumes 50 MW during peak hours, then your estimation could be spot on.

However, I’m old and don’t guarantee I have got this right. Sorry if it turns out that I’ve been talking up my own whatsit!

Reply | Quote

I struggled with that too, opting to calculate the total amount of energy consumed.

But I may be wrong!

Reply | Quote

Fascinating.

I get lots and lots (and lots) of mail from people who’ve hit the problem. If your clients have all of the old Win7 patches installed, they’ll avoid the Win7 slow scans. But then again, they’ll all be on Windows 10, eh? 🙂

Reply | Quote

CH100, what is this “Mini Tool” you are talking about?

I had to update a friends’ machine today (win7 pro x64, french) that I had turned off WU on april 1st 2016. I installed the march windows update agent (KB3138612) and after about 1 hour of nothing happening, I scuttled it. Then I followed CandianTechs’ previous article and installed KB3172605 and let it do its thing. Finally, about another hour-and-a-half later, nothing was happening and I had to leave it at that. I never completed the other steps listed in his article. Of course, the machine still works OK but now its in an undefined/incomplete update state. I left the WU service running but in the control panel -> Windows Update, I left it on “Check for updates but let me choose…”.

Maybe your mini tool can straighten things out, or not?

Reply | Quote

@Walker Thanks for the information related to December 2015. Maybe I should expand my testing to December 2015 as I was close and a lot of factors and few posters indicated something that has happened around that time.

Reply | Quote

Thanks for clarification. So the slowness may have been there before KB3095649. I am testing against WSUS declining all later patches which may not be exactly the same with the experience which users had on windows Update late 2015.
Maybe using WU MiniTool in which I can synchronise superseded updates and install only until a particular date would be more relevant for testing.
I am not a developer either, the closest that I can get to what you propose is by using Process Monitor.
I tend to consider wuaueng.dll 7.6.7601.19161 from kb3138612 comparable in quality with wuaueng.dll 7.6.7601.23453 from kb3172605 while what you say somehow the opposite.
I tend to think that 7.6.7600.320 is actually the worst one against which we should compare.

Reply | Quote

@Bob… I think you are a developer and you did some research about svchost.exe and CPU looping in the past. Any chance to have a look at what @abbodi86 proposed and maybe enlighten all of us?

Reply | Quote

Do a search for Windows update MiniTool. It is a tool written by a Russian developer MisterX and which seems to me to be very light and useful. It uses the same Windows Update Agent in the background. If it is as slow as Windows Update, enable the check box to get the superseded updates too.
I think it is featured on high-tech forum sites like https://forums.mydigitallife.info/
Try this site for downloading, but do not expect any support from anyone here, as it is not actively promoted by Woody or anyone else.
http://www.majorgeeks.com/files/details/windows_update_minitool.html

Reply | Quote

Try Dalai’s method http://wu.krelay.de/en/ in addition to what you have already installed. Canadian Tech’s patches don’t need to be uninstalled, they are actually useful. In particular start with KB3185911.

Reply | Quote

I have several machines that still run W7. On each one of them I found it would take days~weeks to do the update scan. But once each one of them had finally completed the scan and installed the updates they’ve all been doing well. Knock on wood!

Reply | Quote

Re kb3095649 Just wondering if this has been installed should it be uninstalled.

Reply | Quote

It looks like Microsoft never fixed the documentation but, as far as I know, there’s no problem keeping it installed.

https://www.askwoody.com/tag/kb-3095649/

Reply | Quote

After further testing being greatly assisted by Windows Update MiniTool, which uses the same Microsoft Windows Update client but enables more options and has a very intuitive user interface, I found that starting about May 2015, svchost.exe copes harder and harder with the supersedence calculations. This is not due to one patch or another, although it is likely that one of the kernel security patches each month to contribute more to the load due to a longer supersedence chain. On my VM with relatively fast 2 vCPUs and enough memory, the calculation time increased from about 2 minutes in May 2015 to 16 minutes in August 2015 and keeps growing. At the same time, the original svchost.exe – agent 7.6.7600.320 uses more than 2 GB of memory and about 50% of the 2 CPUs. Probably the CPU performance greatly influences the calculation time. However there will be a point later in time when not even very fast CPUs would be able to perform the calculations in less than few hours.

Reply | Quote

I’m confident that kb3138612 comparable in quality with 7.6.7600.320, because both need the win32k.sys magical patch

wuaueng.dll 7.6.7601.23453 from kb3172605 is a whole new level of quality, independent from any other patch, and fixes the above two versions issues:
7.6.7600.320: high cpu/ram consumption, long stall scan
7.6.7601.19161: long stall scan

Reply | Quote

Interesting. So the Win7 update scan slowdown isn’t from just one patch, it’s the cumulative effect of several, between May and August 2015.

The first version of KB 3035583, the infamous “Get Windows 10” patch, came out in late March 2015.

http://www.infoworld.com/article/2903005/operating-systems/what-we-don-t-know-about-mystery-windows-patch-kb-3035583.html

Reply | Quote

Yes, the update came in March, but it was not activated until the first of June
meaning, it stats getting info and showing upgrade ads.. etc.
https://forums.mydigitallife.info/threads/61435

Reply | Quote

Fascinating! So I wonder if there’s a connection between GWX and the Win7 scan slowdown….

Reply | Quote

KB3035583 is no longer there, it has been entirely removed, so even if this was true, I have no way of testing. I think the only relation with those months in 2015 is the increasing complexity and this is probably reflected exponentially in the increased calculations required to present only the latest updates.
If I use WU MiniTool which has an option not to calculate anything, which means to present all patches available regardless of supersedence, there is no significant difference from one month to another or from one year to another in the scanning time which is very fast. Continuing testing, December 2015 jumped to 45 minutes.

Reply | Quote

What I actually found until now is that there is no relation to the GWX patches, just a coincidence. Those patches are no longer represented at Microsoft but we still have the long scanning time, at least in specific conditions, which means not installing any of the speed-up patches of any flavour.

Reply | Quote

Yep. I understand there’s no overlap in specific DLLs.

But… is it possible that there’s an intentional (or even unintentional) link between the GWX effort and the lack of interest in Win7 update scan support?

Reply | Quote

You’re right… you can even find support there as well: http://forums.mydigitallife.info/threads/64939-Windows-Update-MiniTool

Reply | Quote

@ch100: You are most welcome. I hope it will be of some help.

I read everything you post, and I am most grateful that you share your outstanding, extensive knowledge with us. It is very much appreciated. Thank you! 🙂 🙂

Reply | Quote

MDL is a great resource.

Reply | Quote

Hi CH100, thanks for your reply.

What you propose was going to be my next move as this fix from Dalai has been mentioned here numerous times.

Reply | Quote

Thanks for the thumbs up, Woody. Have gone to that website a few times over the years.

Reply | Quote

Thanks Ch100, I’m heading over there right now! New tools are always fun to play with and discover -;)

Reply | Quote

Although the vast majority of 470 Windows PCs I support are currently Windows 8.1, which aren’t having any Windows Update problems, I still have around 75 Windows 7 systems and having updated the WUA bits by manually installing KB3172605 has made all the difference for me. No problems yet with September 2016 updates, on systems where I had manually installed KB3172605. YMMV of course.

Reply | Quote

Thank You.

Reply | Quote

Just wanted to say that I bit the bullet and installed KB3185911 a few minutes ago… it cut my time checking for updates from the previous nearly 30 hours to around 7 minutes. That that one security patch made such a massive difference for me boggles my mind.

Reply | Quote

Mini Tool Downloaded and installed…

Interesting that it uses the same wsusscn2.cab file as MBSA, one of my other usual “must-have” tools.

Reply | Quote

I didn’t want to mention it, but now that Woody did, use that one for all your needs about WUMT. You may need a valid login though and very important, be aware of this https://forums.mydigitallife.info/threads/65609-Important-info-about-fake-phishing-sites!

Reply | Quote

wsusscn2.cab is only one option, but not the main one. That file is updated often at Microsoft and has as reference only security updates, not the whole catalog.
I suggest using the tool online while enabling the option “Include superseded”. That option will allow immediate scan, but present you will all updates which have been obsoleted at the same time.

Reply | Quote

Who would know, other than the M$ execs?

Reply | Quote

@Squall: KB3185911 is a temporary fix that will work from September 13 to October 10. On October patch Tuesday (10/11) the WU scan times become long again and a newer win32k.sys update will be released then to resolve the long WU scans for another 3 to 4 weeks.

I went with the more permanent solution with KB3172605 on all my Win7 PCs, which updates the WU client to v7.6.7601.23453 and does not depend on any win32k.sys updates.

Reply | Quote

@ch100
Can you be more specific? What do you want me to look at?

Reply | Quote

Unclear update to “July 2016 update rollup for Windows 7 SP1…” (KB3172605)

KB3172605 (6.1.1.2) — July
KB3172605 (6.1.1.4) — September revision

I downloaded the latest full installer for KB3172605 (you know, so windows update doesn’t take 8 hours prepare to check for update on a clean install). This appears to be 6.1.1.2.

Windows update offers KB3172605, again. Version 6.1.1.4 apparently (2016_09 13th).

Odd that the full installer isn’t the latest version.

Reply | Quote

Here are the latest results, see also https://www.askwoody.com/2016/still-no-answer-to-the-source-of-win7-slow-scanning/#comment-99196
This is related entirely to my VM simulating WU behaviour and the only thing that matters is the trend, the time for WU scanning exponentially growing from one month to another for a machine with no other patch than Microsoft’s own WU Agent 7.6.7600.320. The absolute value is not so relevant, although orientative, as this differs from one system to another, based on 32-bit vs 64-bit, CPU type, numbers and speed, RAM amount. As a suggestion, the minimum current specs should be no less than 2 Intel CPU physical cores, 6 GB RAM and 64-bit Windows 7 OS (Pro is good, Enterprise or Ultimate are the best). Anything less can dramatically reduce the performance, although 4 GB RAM would generally be OK except for specific peak load times and WU may be one of those peak times.

August 2015 – 16 minutes
September 2015 – 22 minutes
October 2015 – not tested
November 2015 – not tested
December 2015 – 45 minutes
January 2016 – 51 minutes
February 2016 – 67 minutes
March 2016 – 95 minutes – this is getting ugly, it may be the reason for the release of KB3138612, the first consistently very good WU client in a long time, i.e. few years
April 2016 2h 40 minutes (160 minutes) – it may be time to stop, but I keep going on for a while, just because I can, otherwise it seems unreasonable
May 2016 – 3h 34 minutes (214 minutes)
June 2016 – not completed after 3 hours, it is likely longer than the previous one, I quit now, there is no point to keep going on 🙁
Microsoft really need to fix their servers.

Conclusions:
There is no other root cause than the original design of the Component Based Services which is very reliable, but introduces a lot of complexity which starts causing major issues after few years, unless actively managed. We see it actively managed and with excellent results when it comes to MSE and all the other security related products for Enterprise – Forefront or System Center Endpoint Protection, all using the same engine. Also MSRT update is actively managed, same very good update behaviour is observed.
Using the WU MiniTool while enabling the checkbox “Include superseded” completes scanning in less than 5 minutes, typically about 2 minutes. This is not acceleration due to the WU MiniTool which uses the same Microsoft WU agent, but a better use of the built-in agent options, not available in the Microsoft built-in GUI. This is behaviour as expected by me, who believe that the complex supersedence not actively managed by Microsoft in their own Catalog is the root cause of the current extremely slow scanning behaviour.

Until October 2016 announced changes, which require further clarification, the only current solution to mitigate slow update behaviour is (in my preferred order of installation, but all patches mentioned are effective and better and safer together):

Download and install manually the following patches, after which use the regular Windows Update.
KB2533552
KB3020369
KB3138612 (Dalai, http://wu.krelay.de/en/)
KB3185911 (Dalai, http://wu.krelay.de/en/)
KB3172605 (Canadian Tech, actively promoted and endorsed by Woody and abbodi, mentioned by Susan Bradley in her famous spreadsheet quoting Woody)
http://www.canadiantech.info/for-techies/windows-update/windows-update-not-working/
or
http://answers.microsoft.com/en-us/windows/forum/windows_7-update/windows-7-update-solution/f39a65fa-9d10-42e7-9bc0-7f5096b36d0c

Reply | Quote

It seems to be a known issue, see few previous posts here. The current one is the one provided by Windows Update.

Reply | Quote

My understanding is that KB3185911 provides a shortcut to avoid the superseded updates and take them out of the way for svchost.exe calculations purpose. This can be proved by studying the supersedence chain in WSUS or Microsoft Update Catalog.
How does KB3172605 act then, as it is not part of a long supersedence chain, if any at all?
There are a lot of reports about how good KB3172605 is, but none seems to explain why and if it is going to last.

Reply | Quote

The long & slow WU scan problem is not only limited to Win7 systems BUT the problem ALSO occurs under Vista SP2 & Server 2008 R0 SP2 as well as I tested myself several months ago on a Vista based PC (ch100 & woody should take a note of this).

latest WUA client used on Vista SP2 was v7.6.7600.256 dated 6/2/2012 as v7.6.7600.320 dated 5/14/2014 is only offered to Win7 SP1 users.

Reply | Quote

I pretty sure CBS has nothing to do with the issue
it finishes scanning components and report it to WU before the stuck occurs

Reply | Quote

Absolutely, it is the calculation to avoid presenting the superseded updates causing this delay and nothing else.
It is obvious in the WindowsUpdate.Log and the delay can be avoided by checking the box “Include superseded” in the WU Minitool. In such a case, all updates are presented, 558 currently for me on a new SP1 clean install with agent 7.6.7600.320 and also somehow KB3024777 installed itself without warning. There is also the English Language Pack showing as installed.
This is a snippet of the latest log from my testing

2016-09-20 17:13:49:899 916 46c Misc Microsoft signed: NA
2016-09-20 17:13:49:899 916 46c Misc Validating signature for C:WindowsSoftwareDistributionWuRedir9482F4B4-E343-43B6-B170-9A65BC822C77wuredir.cab with dwProvFlags 0x00000080:
2016-09-20 17:13:49:899 916 46c Misc Microsoft signed: NA
2016-09-20 17:13:49:899 916 46c Misc Validating signature for C:WindowsSoftwareDistributionWuRedir9482F4B4-E343-43B6-B170-9A65BC822C77TMP89D0.tmp with dwProvFlags 0x00000080:
2016-09-20 17:13:49:914 916 46c Misc Microsoft signed: NA
2016-09-20 17:13:49:914 916 46c PT +++++++++++ PT: Synchronizing extended update info +++++++++++
2016-09-20 17:13:49:914 916 46c PT + ServiceId = {9482F4B4-E343-43B6-B170-9A65BC822C77}, Server URL = https://fe2.update.microsoft.com/v6/ClientWebService/client.asmx
2016-09-20 20:31:39:008 916 514 AU AU setting next sqm report timeout to 2016-09-21 10:31:39
2016-09-20 22:33:25:499 916 46c Agent * Added update {4F9AF231-5723-4A52-9293-015D4E5D4CDF}.103 to search result
2016-09-20 22:33:25:499 916 46c Agent * Added update {7363544A-FCB9-45C7-8BE3-0CC41D915671}.103 to search result
2016-09-20 22:33:25:499 916 46c Agent * Added update {A8F9826C-D3FB-479B-BC98-2019C447FB2A}.103 to search result

Reply | Quote

I am convinced that the delay shows on all operating systems which use the CBS and the root cause is the same which has been known for a while. Susan Bradley has few very convincing posts about this issue and Woody discussed it on InfoWorld a while ago. I only confirmed it by doing further testing as I am relatively new in researching this problem and I only revisited and rediscovered it due to the current issues.
svchost.exe is fully functional, but not very efficiently designed and does intensive calculations and uses a lot of memory while calculating the patches which are no longer needed if more recent ones are available.
All we do with installing different speed-up security kernel patches is to take a shortcut and avoid the most intensive calculations. At the same time, the WU client in its more recent versions seems to be improved which also helps a lot.
The symptoms are worse on older operating systems which have more patches released in time and Vista and W2008R1 may behave even worse that W7 or W2008R2.
The only reliable solution is for Microsoft to remove as many older patches as practical from WU and leave them for those interested only in the Catalog or the Download Center site. We may see this happening with the current push for the rollups but I think Vista and 2008R1 users may have to cope with the current situation and find workarounds like we do at the present time.

Reply | Quote

@Wlaker I completed my testing and the conclusion is that the time has exponentially grown to insane values starting sometime mid-year 2015 and kept growing, until the user’s CPU and memory could no longer cope, which varies depending on the PC used and also if the OS is 32-bit or 64-bit due to memory limitations for the 32-bit version.
Until then, the only valid workarounds are those promoted mainly by Dalai and Canadian Tech, both of them at the same time for additional peace of mind. They are not exclusive and both are good. After that, Windows Update should behave and take care of the rest in the normal way.
For the current round of updates, please watch closely the MS-DEFCON rating and Woody’s posts. 🙂

Reply | Quote

“svchost.exe is fully functional, but not very efficiently designed and does intensive calculations and uses a lot of memory while calculating the patches which are no longer needed if more recent ones are available.”

You bet, CH100.

This is an anecdote from last night:

I’ll spare U the details of the particular configuration & patching of my main box… Lets just say that when I started the WU service and started “check for updates” in the control panel, svchost gobbled up about 2 gigs of RAM more or less steadily, and kept doing so until 2 hours later I killed that particular instance with Process Explorer (Sysinternals).

I rebooted the box, svchost RAM usage was back to normal. I then fired up MBSA and let it do its thing. Well, immediately svchost went up to 2 gigs of memory usage again and MBSA, which usually returns a result within 20-30 minutes, actually took about 8 hours this time around. Without knowing exactly how it is tied into the WU infrastructure (besides that it is using the usual wsusscn2.cab file), I suppose it uses the same WU Agent or client file(s) as the regular WU. Since this box only had KB3138612 WU Client as the latest, I guess MBSA failed its usual speedy run for the same reason(s) fragmentally patched boxes fail but can recover by installing the monthly “(not)magic” patch.

Reply | Quote

svchost.exe should not consume so much memory with one of the newest WU clients, KB3138612 or the one bundled in KB3172605. Might be useful to install the later for performance, as according to abbodi86 it is superior to KB3138612.
I am familiar with MBSA, not in so much detail, but is it still supported in full? I thought it was silently discontinued, in the sense that some functionality works as expected, while some does not. I know about a reference to IIS which does not work correctly in Windows 7, unless the IIS 6 components (legacy) are installed.
The main reason for the discontinuation of MBSA would obviously be to replace it with a full and complicated and expensive beyond everything else product, to perform what otherwise should be a simple scan against the security database from Microsoft.

Reply | Quote

@ch100:

Thank you for posting the results of your tests, and your conclusion. It is most appreciated. I agree with you your assessment of the current situation. I will be watching very closely, the MS-DEFCON rating and Woody’s posts, as advised. Thank you once again for all of your hard work! 🙂

Reply | Quote

“If your clients have all of the old Win7 patches installed, they’ll avoid the Win7 slow scans.”

So the answer to your question is that everyone should install all patches?

Reply | Quote

Yep. Or, as I would put it, if you’re willing to install Microsoft’s new snooping software, you can get faster update scans.

It’s been that way for several months now. My big objection to installing the speedup patches is that they carry other, undefined (and likely snooping) patches with them.

http://www.infoworld.com/article/3086811/microsoft-windows/microsoft-releases-kb-3161647-kb-3161608-to-fix-slow-windows-7-update-scans.html

Reply | Quote

There was a comment made by “Bob(maybe)OrNot” from here that I still remember:
https://www.askwoody.com/2016/checking-for-updates-still-takes-forever/comment-page-1/

part of it was this:

“wuaueng.dll!CUpdateDetectInfoList::FindNewestUpdate:
Called every time wuaueng.dll!CUpdatesToPruneList::AddSupersedenceInfoIfNeeded. This may be redoing supersedence work that had already been done by the calling instance of wuaueng.dll!CUpdatesToPruneList::AddSupersedenceInfoIfNeeded
May account for ~93% of excess CPU usage. (overlaps completely with the 99.8% figure above, as do the next two)

ntdll.dll!RtlQueryPerformanceFrequency:
“Retrieves the frequency of the performance counter. The frequency of the performance counter is fixed at system boot and is consistent across all processors. Therefore, the frequency need only be queried upon application initialization, and the result can be cached.” – Microsoft

They called this function about 3,270,000 times during the 2 hour check for updates. Microsoft says “Only call this once, it won’t change between boots”, Microsoft calls it 3.27 MILLION times. Windows update is slow.”

Reply | Quote

Although wu.krelay.de went online in March 2016 I’ve been investigating this issue a LOT longer. The first occurance I remember was in August/September 2015 after asking my brother how long it takes to patch a newly installed Win7 machine. For those of you who can read/understand German, it’s “documented” in the Planet3DNow forums: http://www.planet3dnow.de/vbulletin/threads/423516-Windows-Update-funktioniert-nicht?p=5037886&viewfull=1#post5037886
For those who don’t understand German, you can use a translator like Google Translate or something: http://translate.google.com/translate?sl=de&tl=en&u=http://www.planet3dnow.de/vbulletin/threads/423516-Windows-Update-funktioniert-nicht?p=5037886&viewfull=1#post5037886

My brother’s answer (several hours) and the fact that up-to-date machines are done searching for updates in a few minutes manifested the wish to dive deeper into the issue. This wish became even stronger as we both work for a small company and manage IT systems there – which includes installing new Win7 systems. So, we could save us time (and electricity) to set up new systems.

Eventually this led to a session of seven hours (yes, seven HOURS) at the end of August 2015 with many Windows image restores, long wait times and such. As a result we found KB3078601 as the “magic” patch at that time. Since then my technique has become far less time-consuming.

Long story short: I recall August/September 2015 as the start of the slow update scan.

BTW: Sorry for wu.krelay.de being offline for several hours. We still don’t know the exact cause for this. Might have been a DDoS, maybe not. Funny thing is that I updated the site just half a day before that happened; I did’t notice it until someone made be aware of the situation.

Regards
Dalai

Reply | Quote

Fascinating! Thanks for the perspective.

Reply | Quote

@Dalai,

Thank you for providing to the public the resource of your website and the benefits from your private research —

I visited your site for the first time last week, and I appreciated your information and instructions.

I also appreciate the fact that you have an English translation on your German site.

Wuensche euch/Ihnen viel Erfolg!

Reply | Quote

+1

Reply | Quote

That comment from Bob… was memorable, no wonder that you remember it, I do it too!
I actually challenged Bob… to do further testing, subject to his/her availability in relation to a related issue in another thread. There is so much activity here, that I cannot find that post right now.

Reply | Quote

Thank you Dalai! It is consistent with my findings about August 2015, but because I have very likely better CPU and RAM than average, August 2015 simulation taking 15 minutes of scanning did not look so bad, although much worse than previous months simulated scans.
You can check my list above if you haven’t already, for my results with a VM running on my system which may generate completely different results than other systems.
Keep doing the fantastic job at wu.krelay.de 🙂

Reply | Quote