This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
I've reloaded hundreds of Windows computers over the years and I like to think that I am reasonably proficient at that process. I have just encountered an issue that required a lot of time and effort to resolve and I am posting this to try and save someone else the same ordeal.
My customer had a late model, name-brand Windows 7/64 SP1 computer with a disk drive that was failing. I changed out the disk drive with a replacement and went through the recovery process, using the manufacturer-provided Recovery Media. That media is supposed to be identical to the image loaded on the drive from the factory - Windows 7/64 with SP1.
Following the reload, I followed my normal procedure and launched Windows Update. Windows Update remained at "Checking for Updates" for hours, without ever displaying any updates to install. I restarted the PC and tried again, with exactly the same result. The Software Distribution folder would get built and there were plenty of entries in WindowsUpdate.log, but eventually disk activity would cease but CPU activity would remain over 50%. And Windows Update just showed "Checking for Updates" forever.
I decided the reload must have been bad and so I repeated it from scratch again with exactly the same result. At that point I decided the image on the manufacturer's Recovery Media must be defective and so I reloaded from my MS Partner Program Windows 7/64 SP1 DVD. I had the same exact symptoms and result again. I thought that maybe I was not waiting long enough, so I left it running overnight. The next morning, it was still at "Checking for Updates".
I tried additional reloads using SURT and that also remained at "Checking for Updates" without accomplishing anything. I tried using the Windows Update Troubleshooter - with no luck. Ditto for manually resetting Windows Update and various combinations of these techniques. I verified that Windows was activated and that date/time were correctly set. Nothing made any difference.
I then started meticulously documenting everything as I went along and I think I've found a solution:
After the reload, I checked the Windows Update components in C:\Windows\System32. The components are wuapi.dll, wuapp.exe, wuaclt.exe and wuaeng.dll and all are version 7.5.7601.17514 dated 11/20/2010. Once you launched Windows update or run SURT, these are all updated directly to version 7.6.7600.320. At that point, I get the symptoms described above and there doesn't appear to be any way to recover.
When Windows Update is launched, it first updates itself automatically and without the user having any option. It appears that upgrading the WU components from7.5.7601.17514 directly to 7.6.7600.320 causes the issue. I suspect that it works fine for computers that are updated incrementally.
Once WU version 7.6.7600.320 is loaded, there is no easy recovery that I could find.
CURRENT PROCEDURE:
Credit to Canadian Tech, Volume Z and other contributors for developing this current procedure.
ORIGINAL PROCEDURE FROM JANUARY 19 2016 HAS BEEN DEPRECATED BY THE NEW PROCEDURE ABOVE:
Ken Morley
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
If it weren't for me this thread would be on page 800 by now since I'm the only one still linking to it
Far be it from me to deprive you of you triviality of correction you seem to need it even though Ken states it in the original post lol which I have serious doubts you've bothered to even read the original post and comprehend it fully :D
I didn't come up with it, and there is no reason for anyone to come up with or promote it. :p
Pot calling the kettle.. bud you've been more trivial than anyone insisting KB3083710 is unneeded which maybe so but you've been more trivial about excluding it than any normal person would be :D
It does no harm :p
You may notice when launching standalone patches that you still see "Checking for updates..." before anything gets installed. If 320 is on the system, it will hang there forever regardless of whether you are searching on-line for available updates or trying to install patches already downloaded to a thumb drive or on disk.
That's pretty trivial, Ken. This situation is experienced by users of this forum day by day, and we advise them to choose "Never check for updates" and restart. And: You will run into the same issue using KB3083710 alone. :)
VZ:
You said "If KB3083710 can be replaced by KB3102810, so can 7.6.7600.320". Have you tested that theory?
Once 7.6.7600.320 is on the system, Windows Update is broken and it becomes impossible to install any other patches, including KB3083710 and KB3102810. I'm not saying it becomes impossible to search for patches - that is a given. It's also impossible to install patches that you have already found and downloaded.
That's because standalone patches still require the WU client to be functional. You may notice when launching standalone patches that you still see "Checking for updates..." before anything gets installed. If 320 is on the system, it will hang there forever regardless of whether you are searching on-line for available updates or trying to install patches already downloaded to a thumb drive or on disk.
I'm sure that there is some way to recover a system once 320 is installed. But I know that it's going to be difficult and complex enough that it makes more sense to simply reload again.
Ken Morley
