In the great game of Windows Upgrades, some you win, and some you lose. Yesterday, Microsoft unleashed Insider Preview Build 19619.1000 into the Fast Ring. I’ve got 2 PCs that I routinely upgrade or update in that ring, so I started the install process on both of them. One went swimmingly, the other spent quite some time … (ahem) … dead in the water. Let me introduce those two PCs, and then I’ll explore a few topics. First, I’ll describe what didn’t work. Then, I’ll speculate on reasons why. Third, I’ll describe what fixes I considered. And fourth and last, I’ll explain what I did and the ultimate outcome: a successful upgrade to Build 19619.
Meet the Fast Ring Test PCs
Both are Lenovos. The older of the two is pretty old: my X220 Tablet was manufactured in 2012. Its basics specs are: Sandy Bridge i7-2640M dual core CPU (2.8 GHz), 16 GB RAM, 256 GB Primary mSATA SSD. The newer is an X380 Yoga manufactured in 2018. It’s got a Kaby Lake quad core i7-8650U CPU (1.9 GHz), 16 GB RAM, and 1 TB primary M.2 NVMe SSD. Normally, the X380 runs rings around the X220T. And when I started down the upgrade trail with both PCs at about the same time, the X380 zoomed ahead until it got to GUI-based OS installation. Once the installer got to 62% complete it hung there for hours. Thus, the X220T caught up pretty quickly, and proceeded all the way to a successful conclusion ahead of its usually faster cousin.
The X380 Yoga Gets Stuck
I never was able to get it past 62% complete during the GUI install phase (before the first reboot, while the previous OS is still in charge). So I forcibly rebooted and tried again. WU found the download so I didn’t have to actually download the upgrade again. (Though it counted through the download cycle, it did so quickly enough that it must have simply been checking the files already on hand.) And again the GUI install hung at the same completion level: 62% and no further. At this point, I was getting nowhere fast, and had already been noodling with it for 2-3 hours. But I did get an errorcode from Windows Update — namely, 0X80070005. So I used the Error Code Lookup Tool to look it up. Here’s what I got:
The built-in error code lookup tool comes in handy in cases like these.
[Click image for full-sized view.]
This particular error code is often called the “Access Denied” error code in honor of the second comment in the output table (“Access is denied.). According to a nice article I found at the Stellar Data Recovery website, this code pertains strictly to Windows Update. It goes on further to assert that
It occurs when the system or user lacks the required files or permissions to change settings at the time of Windows update. As a result, Windows update installation is aborted, and the user starts to experience issues like system slow down, abrupt system restart, and crash—Blue Screen of Death (BSOD).
Later in the same story we find these illuminating passages:
The Windows update error code indicates that the system user doesn’t have the required permission, or the system update is missing some critical files that are required for installing the update.
This may also indicate an underlying issue with your hard drive such as a bad sector which corrupts the system or update files downloaded and saved on your storage media.
In my experience, this kind of error often indicates an issue with the download itself (“missing some critical files” might presumably also count damaged or corrupt download elements). Indeed, I have seen this code before on other upgrades.
What Makes Upgrades Hang?
If you read your way around the discussions of this topic — and there are many, many, many — you’ll find some common threads. The access denied issue is certainly the key content for the error message, but I also see plenty of chatter related to device drivers. These may be missing, broken, or non-functional.
And certainly, whenever WU issues present, it’s never a bad idea to run the Updates Troubleshooter. Click Settings, then type “trouble” into its search box. This produces the Troubleshoot pane (it resides within Update & Security). Under the “Get up and running” heading, Windows Update is entry number 4. I actually tried it between my first and second WU-based upgrade attempt, and it claimed to fix some things. But as you know, my second attempt hung exactly where the first one did.
WU Fixes to Consider
The already-mentioned troubleshooter is a regular first stop when pondering how to get out of a WU jam. Next on the list is the dandy batch file that TenForums maestro Shawn Brink has put together in his Reset Windows Update in Windows 10 tutorial. It’s called Reset_Reregister_Windows_Update_Components.bat and it’s worth keeping around. It basically turns off all the active services on which WU depends, resets a bunch of related registry keys, cleans out the Software Distribution folder, and then turns all those services back on, so you can try again. I’ve used it on multiple occasions and it does the job nicely. If that doesn’t work, one must turn next to an in-place upgrade repair install, with the clean install as a “final solution” of sorts. That’s about it!
How I Completed the 19619 Upgrade
I might have run that batch file, except that waiting for the 2nd upgrade install attempt to fail took more than long enough for me to visit UUPdump.ml, where I downloaded the custom ISO builder for Build 19619.1000 and worked through the component download and ISO construction process that UUPdump’s brilliantly engineered scripts coordinate so nicely. Because I had an ISO file for the 19619 Build by the time WU finished up, I was ready to try a different approach. That is, I simply mounted the 19619 ISO, and then ran its root-level setup.exe program to fire off a manual upgrade, driven completely by local files. This took somewhat longer than usual to complete, with a long time between 59% and 64% complete during the GUI install phase. But it did complete successfully, and the machine is now upgraded.
It just goes to show that sometimes WU over the Internet won’t get you where you need to go. When that happens if kicking WU and its services doesn’t help, it’s time to try a different image. That’s just what I did with the 19619 ISO file I created using UUPdump.ml. This approach should also work for you, if you ever find yourself in the same situation.
Note Added May 17
As you can see from this recent Tweet, Build 19628 did install correctly through Windows Update. It had failed to do so for both 19619 and 19624, and I’d started wondering how long this might go on. MS apparently fixed it, and that tells me I was helped by the Fixes item described in the 19628 Build Release Notes that reads “We’ve fixed an issue causing some devices fail to update with error code 0xc0000409.” Also, and thankfully, the Insider Team apparently fixed the issue that forced me to re-install the FingerPrint reader after each upgrade (or perhaps, I should thank Lenovo, who just pushed a new fingerprint reader driver out last week?)
Author: Ed Tittel
Ed Tittel is a 30-plus-year computer industry veteran. He’s a Princeton and multiple University of Texas graduate who’s worked in IT since 1981 when he started his first programming job. Over the past three decades he’s also worked as a manager, technical evangelist, consultant, trainer, and an expert witness. See his professional bio for all the details.