Concerning the "cannot repair member file" issues in CBS.log I also did a search on this form and I only find one reference referring to Windows Server 2016
here. However in my case it's not hash issues. The files are just missing. Am I correct that all I need to do to resolve them is to copy the WinSxS packages from the repair server, if they exist?
Oh, here is the latest info-pack. Since there were multiple steps that I performed here the results of each step are numbered. Different copies of the logs taken at different times in the sequences. I didn't edit them to remove duplicated log entries from the previous log, but I did make it a "solid archive" which would give better compression with multiple files potentially having large parts of the same content. I'm sure you already know that's what it does, I'm just documenting it here so other people understand what was done.
As a reminder, the history of the server prior to these changes is: Multiple fixes were applied and worked fine, including reboots, up until 7/16. The VM backs up its system state and primary data drive to its own dedicated VHDX drive which assigned to it in early June when problems were first discovered. This is done once a week. The Hyper-V host also performs a Hyper-V backup of the VM once a week. On 7/16, after applying the .4222 fix, the failing server failed to reboot. Attempts to restore to the last known good configuration failed, as well as an attempt to restore to the VM's internal backup on 7/7. Restoring the the VM using the hosts restore function returned the failing server to a bootable state, reverting the fixes between 7/7 and 7/16. Multiple attempts to re-apply the fixes fail causing a system that will not reboot. Even just restoring the backup and booting once, then rebooting (without applying any fixes) fails to reboot.
This suggests to me that at the time the host backup was made, which was before the VM's internal backup was made, the failing server had some pending operation that hadn't finished yet, and that pending operation is what is causing subsequent reboots to fail with 0xc000001a. I don't (yet) know how to determine if this is in fact the case or whether that changes the priority of what needs to be fixed next.
Anyway, after fixes and steps below were done (logs in the attachment) I'm going to reboot the server (later tonight) and hope for the best. If it fails, I'll have to revert again to the 7/7 backup.
1. dism and sfc performed
2. components scanner and extraction of missing components
3. sfcfixscript using a repair server that has already been updated to the current SSU and LCUs up through the versions specified for the missing components
4. sfcfix to apply the fixes
5. sfcfixscript again using v0.0.7 instead to avoid having to use regrecover
6. sfcfix to apply the fixes
7. unneeded log file because I'm running these from a powershell sdcript (sorry about that)
8. sfc performed
9. dism and sfc perfomed again since sfc fails at 41%
a. dism and sfc perfomed again, but using \\repairserver\C$\windows as the dism source
As for the several CBS message in the form of "[SR] Cannot repair member file [l:7]'ddp.mof' of Microsoft-Windows-Dedup-Common, version 10.0.14393.0, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35} in the store, file is missing" should I just copy them from the repair server, or is it more complicated than that?