Finally an excuse to make my first post here! And it just so happens to be down to an issue installing Windows Updates on a customer’s server at work that was running Windows Server 2022.
In all fairness, it was one of my colleagues that had sunk quite a bit of time into the issue at first. They pretty much exhausted all options that they could think of (Windows Update Troubleshooter, SFC, DISM, etc) before asking if I could take a look.
Well, it nearly got the better of me too! I put a couple hours aside one afternoon, reviewed the steps my colleague had tried and tried a couple of more things – some of which were things that had already been tried, and a couple of variations which included…
- Manually downloading the update from Microsoft and installing it in CMD using WUSA
- Manually downloading the update from Microsoft, expanding it and installing using DISM
- Trawling through the CBS.log file to see if I could see anything obvious
That last point did give me one bit of a nugget in the following snippet…
2025-03-03 13:49:26, Error CSI 000006f9 (F) STATUS_SXS_ASSEMBLY_MISSING #6714083# from CCSDirectTransaction::OperateEnding at index 0 of 1 operations, disposition 2[gle=0xd015000c]
2025-03-03 13:49:26, Error CSI 000006fa (F) HRESULT_FROM_WIN32(ERROR_SXS_ASSEMBLY_MISSING) #6713949# from Windows::ServicingAPI::CCSITransaction::ICSITransaction_PinDeployment(Flags = 0, a = Microsoft-Windows-Slb-Mux-Deployment, version 10.0.20348.1547, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}, cb = (null), s = (null), rid = 'Microsoft-Windows-Slb-Mux-Package~31bf3856ad364e35~amd64~~10.0.20348.1547.270bcb39b42d1ee0b13e2bdf1d3231e1', rah = (null), manpath = (null), catpath = (null), ed = 0, disp = 0)[gle=0x80073701]Now, I’ve come across similar errors in CBS.log in the past on older version of Windows Server. However, in those instances – it’s usually been complaining about missing Language Packs and installing the language pack it was complaining about would typically be the fix.
This time however, it was complaining about a missing assembly called “Microsoft-Windows-Slb-Mux-Package~31bf3856ad364e35~amd64~~10.0.20348.1547.270bcb39b42d1ee0b13e2bdf1d3231e1“. Quite a mouthfull and after a bit of searching the vasts of the internet, the results seemed to indicate that this particular assembly is related to the Azure platform and therefore typically manifests itself on Azure based Server 2022 VM’s.
A bit odd then, as this particular server was a VM on an on-premise host that hadn’t even touched Azure. With this in mind though, I fell down the rabbit hole of trying to rebuild the Windows Component Store using the following commands:
dism /Online /Cleanup-Image /StartComponentCleanupFollowed by…
dism /Online /Cleanup-Image /RestoreHealth /Source:C:\Windows\WinSxS /LimitAccessUnfortunately, that didn’t seem to work either and by this point, I was mentally preparing myself with the fact that I’d have to pursue the “In-Place Upgrade” route to fix this rather annoying update issue.
That was until I stumbled across a post on Reddit by u/FCA162. Said post had a snippet from CBS.log with an error very similar to the one I posted above, the exception being the “missing” module in this instance was called “HyperV-HvSocket-Package~31bf3856ad364e35~amd64~~10.0.20348.1.6cdd0ff9c702dc036c10279b44e48d03“.
The post goes on to say that this is most likely caused by an improper shutdown while the server was in the middle of a servicing operation (which in all honesty, could very much be plausible in this situation). It also goes on to explain that the states of some of these packages are stored in the Windows Registry and it’s accompanied by the following script which basically marks any corrupted packages as absent from the system.
$name = 'CurrentState'
$check=(get-childitem -Path 'HKLM:\software\microsoft\windows\currentversion\component based servicing\packages' -Recurse).Name
foreach($check1 in $check)
{
$check2=$check1.replace("HKEY_LOCAL_MACHINE","HKLM:")
if((Get-ItemProperty -Path $check2).$name -eq 0x50 -or (Get-ItemProperty -Path $check2).$name -eq 0x40 )
{
write-host (Get-ItemProperty -Path $check2).PSChildName
Set-ItemProperty -Path $check2 -Name $name -Value 0
}
}Given that there was nothing else really left to lose at this point, I ran the script on the server, rebooted the server and set the update going again.
Not holding out much hope, a couple hours later I connected to the server only to find the update had successfully installed! Saving me the hassle of going through the pain of an “In-Place Upgrade”.
So there you have it! Now, your mileage with this may very well vary – but it’s one of those things to add to your arsenal of things to try going forward if you come across this rather stubborn error.
Credit: u/FCA162 over on Reddit – Patch Tuesday Megathread (2024-09-10) : r/sysadmin