Jump to content

KB3083710 and KB3102810 (needed for windows update?)


Nomen

Recommended Posts


15.  Uninstalled KB3139940, KB3133977, KB3137061 and started updates.  The update list still showed quickly.

16.  Uninstalled KB3139852, KB3139914 and started updates.  The update list took 25 minutes.

17.  Reinstalled KB3139852.    The update list showed quickly.

I'd say, without actually going further with testing (which I will do), that security update KB3139852 may be the one that resolves the slowness problem.

-Noel

Link to comment
Share on other sites

It turns out KB3102810 isn't installed on my system, so I can't uninstall it to see if it makes any difference.  I didn't ever see it offered.

Maybe it's superseded?  Were you thinking I should try installing it directly from the web page?

Perhaps that KB3139852 seems to fix it now the point is moot?

-Noel

Link to comment
Share on other sites

No. I think it may have been superseded by one or more of the later WU/MU updates, despite MS declaring "this update doesn't replace a previously released update" for any of the subsequent "Windows Update Client for Windows 7 and Windows Server 2008 R2: Month Year", fact is  KB3102810 is effectively the November 2015 version of that patch series (for which only the January 2016 wasn't released, AFAIK), although it's not named accordingly...

So, reasoning in this line, I guess you probably have  KB3138612, or it's predecessor on the system, and I suspect they are, in fact, cumulative. If so, try to remove the latest "Windows Update Client for Windows 7 and Windows Server 2008 R2: Month Year". and see whether the slowness returns. TIA. 

Link to comment
Share on other sites

The win-update system has been very responsive today. I've gone through the entire "important updates" list and I have downloaded everything except:

IE-11
KB3020369
KB3138612

MS confirms there are or have been problems with 369, and from a little goog'ling on 612 I'm not happy with what I read about that one. The system has IE9 (and there was some sort of roll-up update for that that came down during today's session). I don't know what I want to do with this system in terms of IE so for the moment I'm leaving it at 9.

Now I turn to the Optional Updates, and here's where I see many of the KB's on my "do not install" list turning up:

KB2506928, KB2545698, KB2592687, KB2660075, KB2726535
KB2952664, KB2970228, KB3021917, KB3035583, KB3068708
KB3075249, KB3078667, KB3080149, KB3123862

And in addition to the above, I'm also being offered these:

2574819, 2830477, 2985461, 3006137, 3013531, 3020370
3040272, 3054476, 3080079, 3092627, 3102429, 3107998
3112148, 3118401, 3121255, 3133977, 3137061, 3138901
3139923

Which I might do some research to see if they're safe. I do not want this system to ever give a win-10 popup or nag message or do anything to proactively download it.

Bottom line: I don't have 3083710 or 3102810 installed, and they have not been offered during this entire update sequence. Starting with Win7SP1 32bit with about 200 security and .net updates rolled in, the first few rounds of on-line updating were slow (in terms of downloading, not in terms of getting the list) but then the process sped up to full speed at some point while I was installing the remaining 70 security and .net updates. In terms of optional updates, I've only obtained the driver-related ones (so far) and have left the system with IE9.

 

Link to comment
Share on other sites

When I started with mid-January level software, I would see about a half hour of CPU looping both before and after the point where you select updates to install.

The update to the Windows Update process itself, KB3138612 seems to only resolve the CPU loop delay after selecting updates.

KB3139852, all by itself, solves the problem on both ends.  They must have changed something in the kernel to fix this and piggybacked it on a security update.

-Noel

Link to comment
Share on other sites

On 3/19/2016 at 9:51 AM, sdt said:
18 hours ago, NoelC said:

When I started with mid-January level software, I would see about a half hour of CPU looping both before and after the point where you select updates to install.

The update to the Windows Update process itself, KB3138612 seems to only resolve the CPU loop delay after selecting updates.

KB3139852, all by itself, solves the problem on both ends.  They must have changed something in the kernel to fix this and piggybacked it on a security update.

-Noel

yes in my experience ive needed 3102810 at minimum or sometimes a combination of 3138612 947821 and 3102810

didnt work for me.

Link to comment
Share on other sites

17 hours ago, NoelC said:

Please be more specific.  What did you install, and did you find that AFTER waiting through the install and reboot, the NEXT time it was still slow?

-Noel

the update 9852. yes! it was still slow. and high memory usage.

Link to comment
Share on other sites

Thank you for the report, sdt! Your experience squares with mine, in that it seems that different hardware platforms need different update combinations to overcome the WU/MU slowness, while some machines need none. I interpret this as meaning there probably are more than one issue behind the same symptoms.

Link to comment
Share on other sites

On mercoledì 23 marzo 2016 at 7:25 PM, dencorso said:

I interpret this as meaning there probably are more than one issue behind the same symptoms.

This is a good example of how these kinds of things are highly subjective, being old and grumpy I interpret this as meaning that the MS guys are a bunch of headless chickens that have not any idea how to setup properly their own crappy update mechanism.

jaclaz
 

Link to comment
Share on other sites

On 3/21/2016 at 7:29 AM, NoelC said:

When I started with mid-January level software, I would see about a half hour of CPU looping both before and after the point where you select updates to install.

The update to the Windows Update process itself, KB3138612 seems to only resolve the CPU loop delay after selecting updates.

KB3139852, all by itself, solves the problem on both ends.  They must have changed something in the kernel to fix this and piggybacked it on a security update.

-Noel

Here's further confimation of NoelC's findings:

2 hours ago, MrMaguire said:
Link to comment
Share on other sites

On 3/27/2016 at 7:35 AM, dencorso said:

Here's further confimation of NoelC's findings:

i think the difference is cuz of a fresh install vs "mid-january level" system.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...