Hey folks! I've been scratching my head on this one for a while. I've stumbled across a number of similar sounding problems on this forum and the people here seem really nice and helpful, so here goes! I hope it's at least entertaining...
Backstory Part 1:
This actually started maybe a year ago, windows update just kinda... broke and went into a reboot loop (it would start up, attempt to apply upgrade, splash a terminal so fast I couldn't read it, and then say it was reverting settings... reboot, repeat to infinity). (In hindsight, 1y later, I *suspect* the disk might have filled in between a prepare/apply of an update and things broke and were left inconsistent, I dunno). Eventually I got the system up on a rescue disk (PS: writing a windows ISO to a bootable USB device from Mac is fun), fixed a broken boot setting (a boot tab entry without a drive letter? wtf?), bcdedit/bcdboot'd my way back to a functioning system. Until the next time windows update ran. Windows update started giving errors "A current driver on your PC may be better than the driver we're trying to install. We'll keep trying to install." Okay so at this point I can't update windows any further, but whatever.
Backstory Part 2:
At some point windows update and/or some other mechanism in win10 started popping up these windows saying "you need to restart to get the latest upgrade" with a 30 minute timer. Like it could manage to get past this other error in some scheduled task version of the upgrade, I really don't know. But if did that, at best it would reboot, apply, fail, revert, and go back to the previous 1709 version again. Worst case it would go back into the revert/reboot loop and require the rescue disk dance, again. Okay, so those are annoying, and I disable windows update. Apparently you can only do this for a short period of time. Eventually it re-enables itself, and worse, stops prompting to reboot and just reboots the system every now and then to apply this update. Literally windows update is getting passive agressive on me. I find various threads online about disabling WUA, BITS, etc, but there are literally a dozen different hiddent at-boot mechanisms and scheduled tasks that all re-enable windows update. Ultimately, the only thing I could do was take ownership of the SoftwareDistribution directory and remove write permissions. Problem Solved! Sorta.
So this was all about 1y ago, like I said. Recently, I was finally motivated to try and fix this upgrade situation, mostly because I had to upgrade the OS+drivers to play the PC version of Red Dead Redemption 2 and I read some article somewhere where windows said they made a bunch of fixes to their updater. It's still f'd. I've scoured the internets, and tried a whole host of different things, which lead me to think that my WinSXS directory is corrupt. I'll try to provide some actually useful debugging information below:
Windows version: Windows 10 Pro ver 1709 build 10.0.16299.309
Things I have tried so far, in various combinations:
These last two steps are what have given me a scent trail that I'm now following. They both fail in exactly the same way: after running setup.exe there's a few reboot's worth of applying updates to the computer before it eventually fails, reverts, and plops me back at 1709, again. But then I get an error about the upgrade:
"the installation failed in the safe_os phase with an error during replicate_oc operation"
I'm led to believe "OC" is "Optional Components" and that this is microsoft's helpful way of telling me that it got to a late stage in the upgrade and was doing this last step, which failed, and rolled all the way back.
So what optional components do I have installed? I open the "list windows optional features" thing through the control panel and get a blank white screen. that's weird. so I ask DISM:
Well that's weird...
relevant section that makes me scratch my head from DISM log:
and in the CBS log:
Note that these WinSXS files are present, and seem to my naive eyes to be correct and not corrupt. However I'm thinking that some set of registry keys or package management metadata is involved and is maybe incorrect. But this is beyond what I know (Debian package management is a bit more straightforward, I gotta say). I do note that the build version in the winsxs dir seems like it might be different than DISM + the OS reports (251 vs 15 vs 309 respectively) but as mentioned above, I can't upgrade SSU even via the CAB and I don't know where this metadata would be to investigate further. I see other build versions in the winsxs dir as well.
So anyway, my suspicion is that this is in fact the cause of not being able to list the optional components, which is what's breaking the in-place upgrade from ISO, and likely at the root of all the other problems that I'm having. What do you think? I've seen a number of posts in this forum using an SFCFix app where files are copied around, registries are mucked with, etc with great success. I'm wondering if that's something we can do here, too? Or do you know if there's a way to disable the replication of optional components in the upgrade process? Any other thoughts?
Okay, phew. Thanks for bearing with me on this, and thanks for your time!
Backstory Part 1:
This actually started maybe a year ago, windows update just kinda... broke and went into a reboot loop (it would start up, attempt to apply upgrade, splash a terminal so fast I couldn't read it, and then say it was reverting settings... reboot, repeat to infinity). (In hindsight, 1y later, I *suspect* the disk might have filled in between a prepare/apply of an update and things broke and were left inconsistent, I dunno). Eventually I got the system up on a rescue disk (PS: writing a windows ISO to a bootable USB device from Mac is fun), fixed a broken boot setting (a boot tab entry without a drive letter? wtf?), bcdedit/bcdboot'd my way back to a functioning system. Until the next time windows update ran. Windows update started giving errors "A current driver on your PC may be better than the driver we're trying to install. We'll keep trying to install." Okay so at this point I can't update windows any further, but whatever.
Backstory Part 2:
At some point windows update and/or some other mechanism in win10 started popping up these windows saying "you need to restart to get the latest upgrade" with a 30 minute timer. Like it could manage to get past this other error in some scheduled task version of the upgrade, I really don't know. But if did that, at best it would reboot, apply, fail, revert, and go back to the previous 1709 version again. Worst case it would go back into the revert/reboot loop and require the rescue disk dance, again. Okay, so those are annoying, and I disable windows update. Apparently you can only do this for a short period of time. Eventually it re-enables itself, and worse, stops prompting to reboot and just reboots the system every now and then to apply this update. Literally windows update is getting passive agressive on me. I find various threads online about disabling WUA, BITS, etc, but there are literally a dozen different hiddent at-boot mechanisms and scheduled tasks that all re-enable windows update. Ultimately, the only thing I could do was take ownership of the SoftwareDistribution directory and remove write permissions. Problem Solved! Sorta.
So this was all about 1y ago, like I said. Recently, I was finally motivated to try and fix this upgrade situation, mostly because I had to upgrade the OS+drivers to play the PC version of Red Dead Redemption 2 and I read some article somewhere where windows said they made a bunch of fixes to their updater. It's still f'd. I've scoured the internets, and tried a whole host of different things, which lead me to think that my WinSXS directory is corrupt. I'll try to provide some actually useful debugging information below:
Windows version: Windows 10 Pro ver 1709 build 10.0.16299.309
Things I have tried so far, in various combinations:
- sfc /scannow (no corruption)
- dism /online /restorehealth (no errors reported)
- dism restorehealth against a 1709 ISO's install.wim file (no errors reported)
- various versions of batch scripts that stop wua/bits/etc, rename SoftwareDistribution and Catroot2 folders, and start back up again
- doing a clean boot and trying all the above again
- downloading and installing the latest 1709 cumulative servicing stack upgrade from the ms update catalog (error: this update is not applicable to your computer. wtf?)
- downloading and installing the latest win10 cumulative update from the ms update catalog (same error)
- taking the .msu file from the above SSU cumulative update, unpacking the .cab files, and manually dism addpackage'ing them (same error in the output of the dism command)
- running the setup.exe from within the 1709 ISO to do a repair/upgrade install
- running the setup.exe from within the latest 1909 ISO to do a repair install
These last two steps are what have given me a scent trail that I'm now following. They both fail in exactly the same way: after running setup.exe there's a few reboot's worth of applying updates to the computer before it eventually fails, reverts, and plops me back at 1709, again. But then I get an error about the upgrade:
"the installation failed in the safe_os phase with an error during replicate_oc operation"
I'm led to believe "OC" is "Optional Components" and that this is microsoft's helpful way of telling me that it got to a late stage in the upgrade and was doing this last step, which failed, and rolled all the way back.
So what optional components do I have installed? I open the "list windows optional features" thing through the control panel and get a blank white screen. that's weird. so I ask DISM:
Code:
C:\windows\system32>dism /online /get-features
Deployment Image Servicing and Management tool
Version: 10.0.16299.15
Image Version: 10.0.16299.309
Error: 0x800f0805
The specified package is not valid Windows package.
The DISM log file can be found at C:\windows\Logs\DISM\dism.logWell that's weird...
relevant section that makes me scratch my head from DISM log:
Code:
2019-11-19 16:50:53, Info DISM DISM.EXE:
2019-11-19 16:50:53, Info DISM DISM.EXE: <----- Starting Dism.exe session ----->
2019-11-19 16:50:53, Info DISM DISM.EXE:
2019-11-19 16:50:53, Info DISM DISM.EXE: Host machine information: OS Version=10.0.16299, Running architecture=amd64, Number of processors=8
2019-11-19 16:50:53, Info DISM DISM.EXE: Dism.exe version: 10.0.16299.15
2019-11-19 16:50:53, Info DISM DISM.EXE: Executing command line: dism /online /get-features
...(a bunch of Info level stuff, LMK if you want the full files)...
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 Failed opening package @Foundation. - CDISMPackageManager::Internal_CreatePackageByName(hr:0x800f0805)
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 Failed to get the underlying cbs package. - CDISMPackageManager::OpenPackageByName(hr:0x800f0805)
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 The specified package is not valid Windows package. - GetCbsErrorMsg
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 Failed to open the Foundation package. - CDISMPackageManager::OpenFoundationPackage(hr:0x800f0805)
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 The specified package is not valid Windows package. - GetCbsErrorMsg
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 Failed to open the Windows Foundation Package as a fall back. - CPackageManagerCLIHandler::ProcessCmdLine_GetFeatures(hr:0x800f0805)
2019-11-19 16:50:54, Error DISM DISM Package Manager: PID=4904 TID=7772 Failed while processing command get-features. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f0805)and in the CBS log:
Code:
2019-11-19 16:50:54, Info CBS TiWorker starts successfully.
2019-11-19 16:50:54, Info CBS Lock: New lock added: CCbsWorker, level: 5, total lock:3
2019-11-19 16:50:54, Info CBS Universal Time is: 2019-11-20 00:50:54.233
2019-11-19 16:50:54, Info CBS Failed to find a matching version for servicing stack: C:\windows\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.16299.251_none_16dd4c82321e5ccc\ [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
2019-11-19 16:50:54, Info CBS Failed to find servicing stack directory in online store. [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
2019-11-19 16:50:54, Info CBS Loaded Servicing Stack v10.0.16299.251 with Core: C:\windows\winsxs\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.16299.251_none_16dd4c82321e5ccc\cbscore.dll
2019-11-19 16:50:54, Info CSI 00000001@2019/11/20:00:50:54.235 WcpInitialize (wcp.dll version 0.0.0.6) called (stack @0x7ffe78694519 @0x7ffe78dbc1c6 @0x7ffe78dbc688 @0x7ff7e1272c32 @0x7ff7e12735b8 @0x7ffea74a6d23)
2019-11-19 16:50:54, Info CBS Lock: New lock added: CCbsSessionManager, level: 11, total lock:8
2019-11-19 16:50:54, Info CBS Lock: New lock added: CSIInventoryCriticalSection, level: 64, total lock:9
2019-11-19 16:50:54, Info CBS NonStart: Set pending store consistency check.
2019-11-19 16:50:54, Info CBS Session: 30777148_2418234269 initialized by client DISM Package Manager Provider, external staging directory: (null), external registry directory: (null
2019-11-19 16:50:54, Info CBS Not able to find an installed package package from moniker: @Foundation [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE]
2019-11-19 16:50:54, Info CBS Failed to resolve package from moniker [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE]
2019-11-19 16:50:54, Info CBS Failed to create open package. [HRESULT = 0x800f0805 - CBS_E_INVALID_PACKAGE]
2019-11-19 16:50:54, Info CBS Failed to OpenPackage using worker session [HRESULT = 0x800f0805]Note that these WinSXS files are present, and seem to my naive eyes to be correct and not corrupt. However I'm thinking that some set of registry keys or package management metadata is involved and is maybe incorrect. But this is beyond what I know (Debian package management is a bit more straightforward, I gotta say). I do note that the build version in the winsxs dir seems like it might be different than DISM + the OS reports (251 vs 15 vs 309 respectively) but as mentioned above, I can't upgrade SSU even via the CAB and I don't know where this metadata would be to investigate further. I see other build versions in the winsxs dir as well.
So anyway, my suspicion is that this is in fact the cause of not being able to list the optional components, which is what's breaking the in-place upgrade from ISO, and likely at the root of all the other problems that I'm having. What do you think? I've seen a number of posts in this forum using an SFCFix app where files are copied around, registries are mucked with, etc with great success. I'm wondering if that's something we can do here, too? Or do you know if there's a way to disable the replication of optional components in the upgrade process? Any other thoughts?
Okay, phew. Thanks for bearing with me on this, and thanks for your time!
