Jump to content

KB3083710 and KB3102810 (needed for windows update?)


Nomen

Recommended Posts

Did you notice the large number of comments on Woody's blog?  The problem seems pretty widespread.

I'm starting to wonder whether the delay may be dependent on the number of updates available, noting that I saw the whole process complete fairly quickly when I was doing a controlled incremental test and had only 3 Important and 3 Optional updates left.

It really feels like something Microsoft is doing to penalize those who would 1) remain on an older OS, and 2) choose to take control of their updates.

Speaking of my stupid fast Win 8.1 workstation, for what it's worth I also went through some controlled testing with Windows Update on it yesterday evening, and even though I'd not updated it since January, the available updates were found right away - no delay.  Either it's not an issue with Win 8.1, or it is intermittent, or something.

I'm not sure that the latest Windows Update process won't sneak GWX or something similar in, and I am not sure that it would help future update speeds, but at this point I'm of the opinion that if you want to continue to partake in Windows Update operations that you probably should install the latest updates to Windows Update itself.

But that of course is up to each and every person - as it should be!

That being said, I have a Win 7 system over in the corner of the office that serves as a small business server and I don't plan to update it any time soon.  It's already accumulated 90+ days uptime and is running flawlessly.  If it works, don't fix it.

-Noel

Edited by NoelC
Link to comment
Share on other sites


The system I'm working on is Win-7sp1 Ultimate, 32bit.  Started with SP1 cd image, rolled in about 200 updates into the image, made sure none of them were ones to be avoided.  After install, performed activation, then brought up the Windows Update through the control panel, set it to check but not download.  Checking and getting the list seems to go smoothly.  First time I was told 72 important updates and 70 or 72 optional updates.  Not selecting any optional updates (yet).  Before doing anything I downloaded IE9 offline install (so I went from IE8 to IE9).  In the Important update list, I de-selected IE11, and "update for win 7" kb3020369, kb3138612, and win7sp1 kb976932 (3.9 mb).   I figure I'll get those after all the other updates (which are listed as security updates).

So far I must have about 30 of those 70 (my list is down to 40).  It says the amount to download currently is 174 mb (52 for malicious software removal tool, 2 updates are 20.5 mb each, another is 11.6 mb, all others seem smaller, not sure how it comes to 174).

 

I was watching the network bandwidth window, and after 2 hours the number of received bytes increased by 60,000 (bytes?).  The data stream from MS appears to be extraordinarily slow. I checked the machine's internet connectivity (speedtest.net) and it was sending and receiving to the limit of the connection I have, so no problem there.  I left it to run overnight, I'll see tomorrow where it stands.  
 

Link to comment
Share on other sites

OK, I went ahead and installed the updates.  I went through the list and hid all of the updates listed on decorso's list.  Then I selected all remaining updates, including the optional ones, and let them all install, which took quite awhile.  How long exactly I don't know because it did it in the background while I did other things for a couple of hours including eating dinner so I didn't care.  Then I restarted the system, twice, and ran CCleaner after each reboot including the registry cleaner.  Then I re-scanned for updates.  This time the scan only took a few minutes and it came up with one IE update for me to install and one optional update on "the list" which I hid.  Installation just took a couple of minutes.  Then I restarted the system, twice, and ran CCleaner after each reboot including the registry cleaner.  Then I re-scanned for updates again.  The scan only took a few minutes and it came up clean.

So I'm not sure what the rhyme or reason is for the long time that scanning for and installing updates takes some of the time, but it doesn't seem that hiding any or all of the updates on decorso's list has anything directly to do with it, including KB3083710 and KB3102810.  At least that is my experience on my Windows 7 x64 system where  I have it set to never check for updates and I have the "recommended" box un-checked.

Cheers and Regards

Link to comment
Share on other sites

Somewhere in all this I ran across a mention of or link to instructions on how to optimize the servicing database, and I meant to get back to that and look it over in more detail, but now I've lost track of it.  Anyone know more?

-Noel

Link to comment
Share on other sites

9 hours ago, NoelC said:

Somewhere in all this I ran across a mention of or link to instructions on how to optimize the servicing database, and I meant to get back to that and look it over in more detail, but now I've lost track of it.  Anyone know more?

I assume you meant the comment at Woody's that said:

Quote

1. Used jwoods suggestion for defragmenting DataStore.edb in administrative mode.

I was curious about that as well, but I didn't see any link in that thread to what it referred to.  I didn't look further, but I assume that you, or jaclaz, can find more info.  I also saw mention that at least the search portion of the task might be sped up by using the setting "Check for updates but let me choose whether to download and install them", but at this point I'd rather decide when and if my system contacts MS.

Cheers and Regards

Edited by bphlpt
Link to comment
Share on other sites

You mean this reply at Woody's?  March 18, 2016 at 7:25 pm by jwoods:
 
Quote

This works in Windows 7 to defrag DataStore.edb…

1. Open an elevated Command Prompt (Run as administrator).
Type or cut and paste the following commands.

2. net stop wuauserv

3. esentutl /d %windir%\softwaredistribution\datastore\datastore.edb

4. net start wuauserv

 
 
 
Link to comment
Share on other sites

That was exactly it - thanks you two.  I think it's that Woody's site pushes older comments to another page that threw me off.

That database is pretty large on my test system, and I had high hopes this tool might improve things, but the defrag operation didn't take long at all (under half a minute) so I assume it didn't find much to do...

DefragInfo.thumb.png.b35637f0668370345f7

A subsequent update check, with essentially no updates available, just now took 59 seconds to find the update (both TrustedInstaller.exe and svchost.exe were clocking CPU time, but there was a lot of disk I/O), then 15 seconds to install it after pressing the [Install Updates] button.  That seemed fairly quick, but then all the latest updates are already installed, save for my fairly small exclusion list.

UpdatesInstalled.thumb.png.3c03556d2383b

I need to restore my pre-update snapshot, do this defrag, and go through the timed update test again.  I'll post on that when I find time to do the experiment.

-Noel

Edited by NoelC
Link to comment
Share on other sites

My next test went like this:

1.  Defragged the datastore.edb.

2.  Did an update check.  Noticed that initially TrustedInstaller and svhost (NETWORK SERVICE) clocked up a few minutes of CPU time, then svchost (SYSTEM) - presumably wuauserv - clocked up a solid 25+ minutes of CPU time with no I/O.  No difference in overall speed - took half an hour of hard looping to find the update list.  The problem is reproduced.

3.  Unchecked all updates and checked ONLY KB3138612 (latest Windows Update Client for Windows 7 and Windows Server 2008 R2: March 2016).

4.  The Download and install proceeded immediately.

5.  Rebooted.

6.  Defragged the datastore.edb.

7.  Did an update check.   Same behavior again from TrustedInstaller and svchost (NETWORK SERVICE) - hard looping for a couple of minutes, then 25 minutes of hard looping from svchost (SYSTEM). 

I believe step 7 proves that there seems to be NO CHANGE IN UPDATE BEHAVIOR from simply having first updated the Windows Update client to the latest.

Secondary conclusion:   Defragging datastore.edb doesn't help.

With respect, sdt, I don't think we have a complete "how-to" yet for folks looking to avoid getting stuck in this tar pit.  So far, it just seems like "wait and ye shall be rewarded" is the only thing to do.

I'm going further with this test.  Next step:  Install some of the available Security updates.

-Noel

Edited by NoelC
Link to comment
Share on other sites

The test saga continues...

8.  After the update check in step 7 above showed the list of available updates, I unchecked everything and chose all the security updates that mentioned .NET, as well as one optional one that would bring in an update to .NET.

9.  The 10 updates went in right away - no delay - and a reboot was requested.

10.  After the reboot, I again started Windows Update and asked for an update check (note that in all this, I have Windows Updates set to disabled, so nothing happened until I request this update check).

11.  Again, a couple of minutes of TrustedInstaller.exe time, along with svchost.exe (NETWORK SERVICE), accompanied by a lot of I/O, THEN the problem recurs and svchost.exe (SYSTEM) chews again through a FULL 25+ minutes of CPU time.

Conclusion:  The .NET updates don't affect this problem.

Secondary possible conclusion:  The number of pending updates doesn't seem to be affecting the length of the Waste CPU Time loops.

Next step:  Install the remaining updates either individually or in small groups to try to isolate if any of them change this behavior.

-Noel

Link to comment
Share on other sites

More half hour test cycles as I do other things...

12.  More .NET updates showed up.  I installed them and the Universal C Runtime update.  The problem remained unchanged; I actually saw a slightly longer delay - 26+ minutes of hard CPU looping on the next check for updates.

13.  I installed half the security updates pending and half of the Optional updates pending.  After those 10 updates went in, the problem remained unchanged.  25+ minutes of CPU time for svchost (SYSTEM).

14.  Installed half of what were left.  6 updates in, NO MORE PROBLEM.  The list of available updates came up in less than 3 minutes.

The 6 updates installed that appeared to resolve the problem were:

  • KB3139398
  • KB3139852
  • KB3139914
  • KB3139940
  • KB3133977
  • KB3137061

-Noel

Link to comment
Share on other sites

No can do.  I'm doing a binary search on this set of updates, bracketing the problem.  At the moment I'm down to two, and am waiting out a 25 minute delay to reinstall one of them.

The one that really does fix the slowdown must be either KB3139852 or KB3139914.  I'm betting on KB3139852, since that one changes Win32k.sys.

-Noel

Link to comment
Share on other sites

OK, will do!  I suspect at the end of this exercise I will be able to say "Install KBxxxxxxx first, then all the other update cycles will be quicker."

Thing is, I'm not sure I've seen KB3102810 go by in the lists.  But I can look again.  What exactly would you like me to test?

-Noel

Edited by NoelC
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...