Windows 7 Slow Windows Updates

We are past the end of the free update period for Windows 10.  While the free Windows 10 upgrade converted a great many systems, there are still a large number of machines on Windows 7 which technicians will need to support until January 2020, the date when Microsoft stops releasing security updates for Windows 7.  In addition, Windows Vista systems will need to be supported until 4/11/2017 and there are even some Windows 8 systems still out there that will need to be supported until January 2023.

Windows 10 cannot update all Windows 7 systems. The most common reason a machine doesn’t get updated appears to be a lack of video drivers in Windows 10 for the “inexpensive” video chipsets. For example the Silicon Motion LynxEM+ (SM712) video chip was used by Intel on it’s S3420GPLC Xeon-class motherboard; SMI never released drivers past Windows 7. Fortunately as this is a motherboard, a video card can be inserted that IS supported, but that’s not an option for a laptop. For example the Intel Mobile 4 Series Express Chipset is a laptop chipset that Intel never released Windows 8 or Windows 10 drivers for and the chip was used on a number of Dell laptops.

As a result, technical people will have to continue supporting these systems and one of the biggest obstacles to continuing support of Windows 7 is Windows Update slowness on a fresh Windows Vista, or Windows 7 installation (Virtually all Windows 8 systems can be updated to Windows 10 – and they should be)

When an older system has a disk crash and a new blank disk is installed, the operating system has to be reloaded. Most recovery media out there for Windows 7 is “Windows 7 with Service Pack 1” and has NO patches or updates applied.

The problem is that as of (6/16) for a basic Windows 7 Pro 64 bit there are 222 patches that have to be loaded after the operating system (and any needed device drivers) are loaded. As of 3/17 that is close to 300. A responsible tech would never reload an operating system then give it back to a user unpatched so after reloading the OS a tech has to re-apply patches and the time this process takes is where the problem is.

Simply turning on Windows Updates and assuming that the user will leave the machine switched on and plugged into the Internet for a week while Windows Updates works away in the background is simply not good enough. A user is exposed to threats while this is going on and their machine can get cracked. Before the PC leaves the shop it MUST have all updates!

The OS reload itself does not take a lot of time. And installing even 222 patches is tolerable. It is even possible to create a “slipstream” install that contains all of the patches and install that, however that does not eliminate the slowness problem for subsequent updates that come out after the slipstream.

The problem is in the “Checking for Updates” section of Windows Updates. Until the first part of 2017 Microsoft did not address the slowness issue and if patches are installed in order, it can take days to get a system to the 2017 patchlevel where the slowness issue is addressed.

People have complained for years on technical forums of how Windows Update is slow. In the past much of this could be put down to simple impatience – if you read complaints from a few years back people are complaining about update times requiring 20-30 minutes in the “Checking for updates” process of Windows Update.

But ever since the beginning of 2016 things have gotten completely out of hand with Windows Update on Vista, Windows 7 and Windows 8. (Windows 10 is not affected by this since the updates mechanism was changed)

To give an example I reloaded Windows 7 Pro 64 bit on a Dell Latitude E5500 in mid 2016.  This system has a Core2 Duo CPU running at 2.0Ghz and 4GB of ram. I took about 2 hours to load Windows 7 SP1 and all of the laptop-specific drivers. After doing this I turned off power management (so the laptop would not shut down on AC power and go into hibernation) and then triggered Windows Updates. The Checking for Updates progress bar was then displayed for the next 26 hours before Windows Updates finally presented a list of updates. During this time the second core of the CPU was running almost 100% utilization.

A few days earlier I loaded patches on a Dell Lattitude 3470 that had a Core i3 6100 cpu running at 2.3Ghz and 8GB of ram. This system took 5 hours to complete the Checking for Updates progress
bar.

I also had to load Windows Vista Business 32bit on a Dell Vostro 1510 with a Core 2 Duo CPU and Mobile Intel 965 Express chipset (another video chipset unsupported on Windows 10) and this one was somewhat interesting – update searching for the first inital 100 updates (pre SP1) took a couple hours but then SP1 wouldn’t install at all until I separately downloaded it and installed it from the SP1 installer. I also had to deselect most of the initial 100 updates and install them 25 at a time to get them to take.  Then after SP1 was installed, updates went pretty quickly until after SP2 was installed. When SP2 was loaded, the system installed Windows Update Agent 7.6.7600.256 and after that the “Checking for Updates” phase took 8 hours as of the middle of 2016.

As of March 2017, reloading Vista Business x86 on a 3GB of ram Dell Vostro 1510 ran “Checking for Updates” for close to 2 weeks before I finally gave up and halted it, then used some additional techniques detailed at the end of this article to get it updated.

As of January 2018, I ran a Windows Update check for update on an HP laptop running Vista, it took 6 WEEKS for it to finish “Checking for Updates” and return with an update list.

Once ALL updates are applied to a system, then the time spent on checking for new updates is short. It is that initial update load that takes hours. Even if you use a program like AutoPatcher from http://www.autopatcher.net/ or a slipstream installation, while the inital patchload will be fast – subsequent updates from Windows Updates will still have to overcome that initial hurdle that takes hours.

Why is this happening? Microsoft has remained pretty tight lipped as to why but investigations by many admins on the Internet have led to 2 major issues. The first is inefficient sorting algorithms in Windows Update. The second is un-expired superseded updates from the Windows Update servers on the Internet that Microsoft runs. There is also another issue which is once the updates are selected, at times it can take hours to download them but this is more because of spikes in in Windows Update Server use and it doesn’t always happen.

Microsoft is aware of these issues. For the first issue they have released a series of updates:

Installing and searching for updates is slow and high CPU usage occurs in Windows 7 and Windows Server 2008 R2

Windows Update Client for Windows 7 and Windows Server 2008 R2: December 2015

Windows Update Client for Windows 7 and Windows Server 2008 R2: February 2016

Windows Update Client for Windows 7 and Windows Server 2008 R2: March 2016

The first, KB3102810, is not installed in a Windows 7 system that is updating from the global Windows Update servers, and the remaining 3 are “hidden” updates, meaning that Windows Update will install them but not list them in the installed updates. (probably so the user cannot remove them) There are various guides on the Internet saying to install 3102810 first on a virgin system that give complicated instructions like don’t turn on updates, disconnect from the update service, etc. when installing it. But it is mostly a waste of time. Some people have reported after installing them that they get uninstalled later on, and most people report that their speed effects do not last. As a tech with a new system you can try installing KB3138612 on Windows 7 and see if that helps with CPU utilization and initial load speed, although doing that has never worked for me.

Microsoft also released a Knowledgebase article on how to check to make sure you are running the latest Windows Update (and how to manually install it if you aren’t) for Windows 7:

https://support.microsoft.com/en-us/kb/949104

As of this writing for Windows 7 Pro 64 bit the version of Windows Update is 7.6.7601.19161 this is from KB3138612.

Microsoft also released a Convenience Rollup Update here:

Convenience rollup update for Windows 7 SP1 and Windows Server 2008 R2 SP1

that is somewhat like a Service Pack 2 for Windows 7 – and it does install a lot of patches – but after it’s installed, triggering a “Checking for Updates” in Windows Update will still cause hours of time to be spent on Windows Updates searching for new updates that were released after April 2016.

These help a part of the problem – slow sorting algorithms on the Windows Update client on the Windows 7 system that chew up CPU and ram. But – if the Windows 7 client CPU is fast enough then it will have enough CPU and ram for even the older inefficient update client to run at maximum speed, and as a result the fixes in these KB’s won’t speed anything up.

The second reason – undeleted superseded updates – CANNOT be fixed at the client if using Microsoft’s Windows Update servers on the Internet. Microsoft has remained completely silent on the issue with the global Windows Update servers but it’s possible to piece together what the problem is by looking at the operation of the WSUS server on a corporate Windows network.

WSUS is used on larger networks of Windows workstations. It downloads all Windows Updates directly from Microsoft that apply to all of the Windows systems connected to it. It also downloads all of the superseded notices. When Windows clients on a network with a WSUS server Check for Updates, they query the WSUS server not Microsoft.

When Microsoft releases an update to an update, they issue a superceded notice on the old update. The WSUS server downloads BOTH updates the original one and the superseded one. It then gives the administrator the option to expire the original update and delete it from WSUS. (Disk Cleanup Wizard, on the Windows client computers, has a checkbox to delete old updates which does the same thing)

For sites with a WSUS server where the admin does the housecleaning and expires the superseded updates, Windows Updates works pretty fast at the Windows clients when they query the WSUS server for the latest updates.

But, at sites where the WSUS server is kind of ignored and the admin never bothers expiring the superseded updates – when the clients check for new updates and query the WSUS server – they display the same slowness as if they are querying Microsoft for updates.

It is clear that the corporate WSUS server application distributed with Windows Server 2008, 2008 R2, 2012, and Server 2016 is the identical server application that Microsoft uses to distribute updates on a global basis. And because of this we also know WHY Windows Updates takes so long on a new installation.

It takes so long because the Windows Update client on Windows 7, Vista, and Windows 8 has to process a “supersedence chain” for EVERY UPDATE that Microsoft has ever released. In short, the Windows Update client downloads a list of updates and has to check each of them that applies to the system it’s running on and attempting to update, to see if it’s superseded, and if so then mark it not to be installed. This might even include foreign language updates that don’t even apply to it. It isn’t downloading the actual update it is just downloading the ENTIRE list of updates Microsoft has ever released for it’s version and then sorting through the list to create the last of actual updates that it will download and install. Once the updates are all applied this supersedence list is saved on the client and then future updates don’t have to generate the list and updating is fairly quick, but that initial generation is a killer.

This was discussed in the following blog post from 6 years ago titled Windows Update (svchost) is taking up 100% of the CPU

In that post one of the posters stated they had contacted Microsoft tech support and been told “The issue was occurring because the clients were trying to process a long “supersedence chain”. Our WSUS server had all of the Windows Defender definitions set on install. The older definitions should have been set to declined when a newer one supersedes it. Once we declined the older updates, and removed the clients old Software Distribution directory and ran a /detectnow. That fixed the issue.”

So it is obvious that Microsoft is not expiring old updates on the global Windows Update servers. As to why they aren’t, the answer is twofold. First, they never planned on it – the structure of Windows Updates is absolutely dependent on the existence of a “Reference” server that contains ALL updates with ALL supersedences. Even if a corporation runs a WSUS server and expires superseded updates – that WSUS server can still access the complete supersedence chain if it needs to (such as if a new version of a client system is added to the network, or the WSUS database gets trashed and has to be rebuilt) from the global Update servers.

Second is simple hubris – the “my stuff don’t stink” attitude. When Microsoft designed Windows Update they ASSUMED that their programmers were so fantastic that Windows would have VERY FEW security holes in it. They never dreamed that it would be common to distribute 300 updates to every Windows client on Earth that requested them. That is why they redesigned the Windows Update system in Windows 10. They had a huge slice of humble pie to eat.

In summary – when the poor windows technician asks “Is there a solution for slow Windows Updates” the answer is essentially no. You can speed it up on slow systems but it will still take hours on the fastest systems out there today and we have 4 more years of updates to deal with so it is clear it will become even slower. For corporations with a WSUS server there is some relief only if they maintain that server, expire updates, and when restoring an older Windows system, disable updates, join it to the domain, then enable updates. But for anyone else with an older slower system, plan on finishing the installation of Windows 7 on Friday evening, then kicking off the search for Windows Updates BEFORE installing ANY software (such as Microsoft Office) and let it run all weekend. By Monday, you should be able to move forward with applying patches. Then tell the customer or user to invest in an external USB disk and run an image backup program (even Windows Backup is good) and make regular backups of their system

Since I originally wrote this article there has been some research and work done on this issue and there now is a fix – sort of. This is discussed in these links for Vista:

Updates not working, it has been searching for updates for hours
Vista Updates just keeps Checking
windows update just seems to hang while checking.
Manual Windows Updates installation

This works with some caveats. First, Install updates then install SP2. Then download the recommended updates manually from:

Windows Updates Catalog

Then, change Windows Updates in Services to Disabled and reboot. Then once the system has completely rebooted, go back into Services, enable Windows Updates (but don’t start it) and then run the standalone installer for the update. Install the 5 updates called for and then reboot with the Windows Updates disabled, then enable Windows Updates and then start the Check for Updates

One further update as of January 2018 – for the past couple of months the initial Windows Updates from Microsoft on a fresh Windows 7 installation have been taking a surprisingly shorter period of time. I can only assume that Microsoft got enough complaints and purged superseded updates from their database. Please note that the Vista updates ARE STILL EXTREMELY SLOW. Interestingly, Microsoft still has Windows XP updates available in XP’s Windows Updates and those work normally (will complete overnight) but it’s Vista updates are virtually unusable on a Core 2 CPU. So with Windows 7 systems it is probably best to run the Windows Updates troubleshooter within the operating system, instead of the tricks in this article. If the internal troubleshooter does not work, my recommendation is instead of attempting one of the many unsupported and undocumented tricks on the Internet to get Windows Updates working again, just wipe and reload the system.