A previous post describes how I used AOMEI Backupper to image my Windows 10 installation and restore it to a USB drive, referred to here as a Windows To Go (WTG) drive although, technically, it was not exactly that.
With the Win10 desktop thus transferred to the WTG drive, the latter functioned as if it were the desktop, with all my programs and settings in place. The WTG drive might run more slowly (worst on a cheap USB; not so bad on a Samsung FIT, whose larger models were also faster; best on an SSD). But it would run.
As that previous post also indicates, however, the day came when it was time to upgrade to a newer version of Windows 10 – and at that point, Windows Update (available through Win-I – that is, hold the Windows Key, near the bottom left corner of a standard keyboard, and hit the I key) refused to proceed.
What I experienced back then, I was now seeing again. This time, I was trying to update the WTG drive from Windows 10 2004 to Win10 21H2. Windows Update replied thus:
Your device is missing important security and quality fixes.
Some update files are missing or have problems. We’ll try to download the update again later. Error code: (0x80070003)
Feature update to Windows 10, version 21H2
We couldn’t install this update, but you can try again (0x800f0831)
I scrolled down the Windows Update screen > View update history. There, I saw that I was getting the first of those two error codes (0x80070003) for “Failed to install” in connection with a Cumulative Update for Win10 2004 (KB5008212). Since I was hoping to upgrade from 2004 to 21H2, I could hope that that problem would go away when that upgrade succeeded.
Therefore, I turned to the second error code (0x800f0831), pertaining to the failure to update to 21H2. For this, I lost some time fooling with Microsoft‘s suggestion – which was, in effect, to proceed as follows:
- Use Everything to find CBS.log (typically found in C:\Windows\Logs\CBS). If the first line in CBS.log is already timed after your update attempt, re-run Windows Update and return to these steps as soon as it fails.
- Run Event Viewer (i.e., Win-R > eventvwr > left pane > Windows Logs > System > right pane > Filter Current Log > Filter tab > check Error box > Event sources: WindowsUpdateClient (check box and hit Enter) > OK.
- Open CBS.log. Copy all lines from the time of your most recent update attempt. Import them into a spreadsheet. Slice the rows into multiple columns. Sort by various columns (e.g., one containing the words “Info” and “Error,” which you may want to limit to just five characters). Filter to include or exclude desired text, or use Ctrl-H to remove redundant verbiage. In my case, most Error lines began with “Failed to resolve package” and ended with “[HRESULT = 0x800f0831 – CBS_E_STORE_CORRUPTION’.”
- Search Microsoft Update Catalog for the package ID of the missing package. The ID in question was apparently supposed to be something like KB5003173. The Error lines in my spreadsheet didn’t contain any KB (KnowledgeBase) IDs. Instead, they largely consisted of things that led to nothing in the Update Catalog (e.g., “Microsoft-Windows-Client-LanguagePack-Package~31bf3856ad364e35~amd~en-US~10.0.19041.1110”). I suspected the reason was that these specific packages were part of a larger, consolidated update – in this case, the upgrade to 21H2. So there wasn’t any smaller update to install, in a bid to help the larger upgrade.
Of course, I could try to download the whole feature update from the Microsoft Update Catalog. Despite repeated searches, however, I did not find it there. Later, I found a Microsoft webpage that seemed to confirm that this Feature Update was not available through the Microsoft Update Catalog.
A different approach, recommended by the seemingly knowledgeable 250 Hello (Milne, 2021), was to run commands that would hopefully clean up the system. The first of these was chkdsk /b. That could take a long time, but it was a standard recommendation and presumably worthwhile. I had recently run it, so I didn’t run it again. Next, Milne cited Microsoft in support of his claim that most sources recommended starting with dism /online /cleanup-image /restorehealth. If (perhaps after a second run) that DISM command reported no errors, I could then wrap up with sfc /scannow – re-running that command, too, if it found issues. In this case, the DISM command produced “Error: 0x800f081f” and “The source files could not be found.” For that, Milne elaborated on more complex steps (see also SuperUser). I was hesitant to follow him in that. My prior experience with DISM told me that I did not want to go there – that DISM could be a huge time sink and still might not help.
Before going any further with DISM, I returned to the idea of downloading and installing the entire Feature Update manually. Multiple sources offered guidance in that. By “manual,” it appeared that they meant, not what one might consider the relatively manual process of downloading the update and entering a command or taking some other step to install it. They just meant that they were using the Windows Update Assistant via the standard Windows 10 download webpage instead of using the more automated Windows Update tab that I had been trying to use (above) in the Settings (Win-I) dialog in Windows 10.
One such source, ITG (Ashiedu, 2022) basically told me to go to that Windows 10 Update webpage > Update Now (presently citing the November 2021 Update) > run the downloaded file (in my case, Windows10Upgrade9252.exe) > click Update Now > click Next immediately. When I was doing this writeup, that worked. Previously, it had not worked. Possibly it had helped to run the foregoing commands. But I think the real explanation – which was not evident in Settings > Windows Update – was just that, as Ashiedu said, I needed at least 10GB of free space. My USB drive had ~8GB free. I would have thought that was enough, but apparently not. What had changed, in this course of this struggle, was that I had used AOMEI Backupper to clone the USB drive while it was running, and had then used AOMEI again to restore that clone to a larger USB drive.
Unfortunately, those steps were only a partial solution. After some time of downloading and installing, the updating process terminated with an error:
Windows 10 Setup
Sorry, we’re having trouble determining if your PC can run Windows 10. Please close Setup and try again.
That was ridiculous: I was running this updater on a Windows 10 system. Clicking the Close button on that dialog resulted in another error:
Something went wrong
Select Try again, and if that doesn’t work, contact Microsoft support for help.
Error code 0x80070003
That was the first of the two error codes listed above – the one that I had hoped to bypass. This seemed to say that I was going to have to install the Cumulative Update for Win10 2004 (KB5008212) after all. Since that update did have a KB code associated with it, I could try manually downloading it through the Microsoft Update Catalog. A search for KB5008212 x64 10 2004 eliminated some of the catalog’s many offerings that were not right for my machine. I clicked Download on the one I wanted, and clicked again on the little dialog window that opened from that. When I had the completed file in my Downloads folder, I double-clicked on it. It ran – but, regrettably, it ended with “The following updates were not installed” – specifying, you guessed it, the one update that I had tried to install (i.e., KB5008212). There had not been any particular explanation of why the “manual” approach would fare any better than the Windows Update approach – and as I now saw, it didn’t.
SoftwareTested (2021) offered several suggestions that mostly focused on malfunctions in Windows Update. Since I had just done a successful installation of other updates, I did not think this was my problem. I did at least try their first suggestion, however:
- Run the Windows Update Troubleshooter via msdt.exe /id WindowsUpdateDiagnostic. Unhelpfully, it returned “Troubleshooting couldn’t identify the problem.”
- Reset all services related to Windows Update via Win-R > services.msc > make sure that specified services have Automatic startup type and Running state (namely, Windows Update Service, Background Intelligent Transfer Service, and Cryptographic Services).
- Reset Windows Update folders via net stop wuauserv > ren C:\Windows\SoftwareDistribution SoftwareDistribution.old > net start wuauserv > reboot.
- Replace spupdsvc.exe by using cmd /c ren %systemroot%\System32\spupdsvc.exe spupdsvc.old
In response to one intractable situation, Dalchina (a very informed participant on the often helpful TenForums) recommended an in-place upgrade repair. I had worked through a similar process in a prior post, but in that case I was only doing a repair, not a simultaneous upgrade. For an in-place upgrade repair, Brink’s well-known tutorial offered numerous tips and caveats worth reading. Brink began with options to run the upgrade from a Windows 10 ISO, USB installation media, or the Media Creation Tool. I preferred to keep a copy of the ISO to avoid the need for repeated downloads of that relatively large (~4.3GB) file, if I ever needed it again. In that case, Brink suggested several ways to download the ISO. Among those methods, the simplest was to run the Media Creation Tool available on the Windows 10 download webpage. After a few initial steps, that tool gave me the option to “Create installation media” including an ISO. I chose that option and specified an ISO. When that was finished downloading, I double-clicked on it to open it > double-click on the setup.exe file in its top folder > proceed through the initial questions. But that approach failed with the same “Sorry, we’re having trouble determining if your PC can run Windows 10.”
At present, it appeared that I had tried most of the suggestions offered by established sources. There might be an indefinite number of other things to try, but probably the more sensible response would be to return to DISM and work through that in more detail.
The only other thing I could think of was that maybe the updater was having a problem with the USB installation. Conceivably Windows Update would work better if I cloned the USB installation to an internal drive and tried updating that. I doubted it – I’d had problems with Windows Update on internal drive installations too – but it was a possibility, if I felt like doing the work.
At present, I was not inclined to pursue such matters further. I intended, instead, to update the Windows 10 desktop installation to 21H2 at some point. Then I would clone that installation to this USB drive, and perhaps that would take care of these problems. In the meantime, it seemed I might have to settle – not for the first time – for a Windows system whose updater was not working properly.