2

My understanding of the issue has changed as we've been attempting to troubleshoot. It may make more sense to scroll down and read 'Update 6' first before reading through the entire body.

We appear to be having some major Windows Update issues on newer machines running 1803.

KB4483234 fails to install in a loop. If you remove it from WSUS it still attempts to install to local PCs.

After some research, my best guess is because KB4483234 is part of SSU KB4477137. In the Windows Support page for KB4483234 it says

"If you are using Windows Update, the latest SSU (KB4477137) will be offered to you automatically. To get the stand-alone package for the latest SSU, go to the Microsoft Update Catalog." https://support.microsoft.com/en-us/help/4483234/december192018kb4483234osbuild17134472

However, WSUS had individual entries for 4477137 and 4483234. I'm not entirely sure how that works, as one was released on 12/11 and the other on 12/19. But based on what I can tell, we currently have 4483234 marked as Approved for Removal and that didn't seem to take.

Even if I do

dism /online /remove-package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.472.1.0 

and then mark it as declined in WSUS this updated still shows up when I prompt Windows Update to query for updates.

So I decided to try and start removing 4477137. When I try to remove it manually with

dism /online /remove-package /PackageName:Package_for_KB4477137~31bf3856ad364e35~amd64~~17134.464.1.0 

it fails and a thorough read through the logs reveals this line:

DISM DISM Package Manager: PID=4600 TID=5116 Permanent package cannot be uninstalled. - GetCbsErrorMsg

I realize I can edit some MUM files to remove it, but I question whether that will cause more issues. I need to install it eventually to get the next rollup, no?

So, I am curious if anyone else is having issues with these two updates. I'm looking for clarification on how the two updates are connected - in that the KB article seems to suggest they should be nested under the one update, but I clearly have two updates. Ultimately, I want to know the best approach to fix this. At the moment this is affecting some of our production machines as we cannot install a windows feature when there are updates pending, but those updates just fail and go back to pending. I am at a loss!


UPDATE 1:

The only error message that seems to come up in the Windows Update logs is 0x800F0922. This seems to be a very generic message. As a result we've attempted the following:

Ran SFC Scannow and all DISM cleanup-image commands, no change.

I assigned a drive letter to the system reserved partition - is is hilariously not full (430+MB free of 500MB)

I reset the Windows Update components by renamed Windows/SoftwareDistribution and Windows/System32/catroot2, no change.

I enabled all unchecked features for .NET Framework 3.5 and .NET Framework 4.7, no change.

I completely removed all .NET Framework features, no change

I reinstalled the normal .NET features, no change.

I've run the Windows Update troubleshooter.

I've tried to install the update directly from the windows Catalog.


UPDATE 2:

A comment suggested I clean out the temp folders. I did a methodical cleaning;

I let the update fail, so there was no pending update in Windows Updates, I cleaned out my %temp% folder and windows/temp. Restarted, downloaded updates, installed, same behavior.

I did the same but throwing disk cleanup into the mix, no change.

I let the Updates download and install until they were pending restart, THEN I went through and cleaned the temp folders and ran disk cleanup again. Still no change in the behavior.


UPDATE 3:

One more thing I wanted to mention: I just re-read my original post and there is a slight omission.

KB4471324 is also failing to install. So, KB4477137 installed fine - I misinterpreted this as being connected to KB4483234 which one of the replies pointed out - but KB483234 and KB4471324 are both stuck in this loop.


UPDATE 4:

Some lines from the CBS log

Before this bit with the hash error is a long chain of registry overlap and its followed by a short block of directory overlaps. What would be modifying these files to change the hashes? Is it more likely a corruption, or something more nefarious?

2019-01-08 17:05:25, Info                  CSI    0000328a Warning: Overlap: Registry value collision found under key \REGISTRY\MACHINE\SOFTWARE\Classes\DeviceDisplayObject\AllItems\shellex\PropertySheetHandlers\{61F7B364-432C-4D04-BBC1-7FC1BF3807A8}\ for , only one component should set this value

2019-01-08 17:05:25, Info                  CSI    0000328b    One of the components setting this value is Microsoft-Windows-FDBTH, version 10.0.17134.471, arch Host= amd64 Guest= x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}

2019-01-08 17:05:25, Info                  CSI    0000328c    Previously seen component setting this value is Microsoft-Windows-FDBTH, version 10.0.17134.471, arch amd64, nonSxS, pkt {l:8 b:31bf3856ad364e35}

2019-01-08 17:05:25, Info                  CSI    0000328d Hashes for file member [l:11]'install.ins' do not match.
 Expected: {l:32 ml:4096 b:89df13e3b32a99da5730f0f3af7cef50d1eecb068ea58c377a5b797c5f592708}.
 Actual: {l:32 b:775a0c4e6371ec5b3371866cae8a52e180594178c84ae96030d367a4afa2020f}.
2019-01-08 17:05:25, Info                  CSI    0000328e Hashes for file member [l:11]'install.ins' do not match.
 Expected: {l:32 ml:4096 b:89df13e3b32a99da5730f0f3af7cef50d1eecb068ea58c377a5b797c5f592708}.
 Actual: {l:32 b:775a0c4e6371ec5b3371866cae8a52e180594178c84ae96030d367a4afa2020f}.
2019-01-08 17:05:25, Info                  CSI    0000328f CSIPERF - RegistryPI Queue 446ms
2019-01-08 17:05:25, Info                  CSI    00003290 Registry installer wrote 2291 values

2019-01-08 17:05:25, Info                  CSI    00003291 CSIPERF - FilePI Queue 159ms
2019-01-08 17:05:25, Info                  CSI    00003292 Error: Overlap: Duplicate ownership for directory \??\C:\windows\SysWOW64\spp\tokens\pkeyconfig in component Microsoft-Windows-Security-SPP-Component-SKU-csvlk-pack-License, version 10.0.17134.441, arch x86, nonSxS, pkt {l:8 b:31bf3856ad364e35}

UPDATE 5:

Inspected the install.ins files. There are 8 of them, 4 sets of pairs for a x64 and x86 flavor. The most recent is

C:\Windows\WinSxS\amd64_microsoft-windows-ie-adminkitbranding_31bf3856ad364e35_11.0.17134.407_none_99e01535d6e245c0\install.ins 

and was last modified 11/9/2018.

[Branding]
CompanyName=Microsoft Corporation
Wizard_Version=11.00.17134.407
Version=11,00,17134,407
Custom_Key=MICROSO
Global=1
IE4 Welcome Msg=1
Platform=2
GUID={7211FFE6-C149-11D0-AFF0-00AA003758BB}
Type=0
NoClear=1

UPDATE 6 & POSSIBLE CAUSE

So, the initial parameters we were working off of were wrong. This was not effecting all machines on 1803. We only had a few random machines that were on 1803, plus a large batch of identical new machines. Our two laptops running 1803 ended up having some other update issue entirely. The issue described above is entirely unique to the new batch of machines.

The new machines were purchased for two reasons, one to upgrade our two higher-end departments and the other as a final proof of concept of automating PC deployments with MDT. Since they were all the same hardware, and we didn't have a VLSC license yet (we wanted to justify the purchase first), I capture their OEM base image, threw a Chocolatey install into it, hit it a with a chocolatey batch script, and popped it into a deploy OU with GPOs for deployment all through MDT. This was the first cumulative update those machines encountered after being deployed this way.

We now have the VLSC base images and I redeployed to the same tasks to the same hardware with the new base image and everything seems to work without issue.

I still have a great interest in seeing if I can fix the currently deployed image. I have 13 PCs deployed and two spares, but I rather not interrupt all our web developers and graphic designers by doing another full swap. But I at least have one 'fix' on the table.

I've altered the post title to reflect some of the changing parameters

  • 1
    Clear out the temp folder. – Michael Hampton Jan 8 at 14:59
  • 1
    I made several passes at purging the temp folders and re-installing the updates with no change in behavior, updated my OP with more details. – Sam K Jan 8 at 16:34
2

You have misunderstood the support article, which says:

Microsoft strongly recommends you install the latest servicing stack update (SSU) for your operating system before installing the latest cumulative update (LCU). SSUs improve the reliability of the update process to mitigate potential issues while installing the LCU and applying Microsoft security fixes. For more information, see Servicing stack updates.

If you are using Windows Update, the latest SSU (KB4477137) will be offered to you automatically. To get the stand-alone package for the latest SSU, go to the Microsoft Update Catalog.

In other words, you should install KB4477137 before installing KB4483234, and this will happen automatically if you are using Windows Update. You still need to install both updates in order to be up to date.

Even if it were possible to remove KB4477137 it would not be helpful to do so, if anything it would be more likely to make things worse.

Instead, you need to resolve the problem that is causing KB4483234 to fail to install. I suggest you start by downloading the manual installer from the Windows Update Catalog and see if that works, and if not, what error message it gives you.

(As to why it continued to attempt to install even after you revoked the approval in WSUS, this is unfortunately typical of Windows 10. Once an update has been downloaded, the Windows Update client becomes very single-minded about installing it, and is likely to ignore any instructions to the contrary. You may also find that the "last reported" date on the WSUS server for these clients isn't changing.)

  • 1
    Have you checked for this problem? Also you should check the CBS log, c:\windows\logs\CBS\CBS.log, for error messages that might give any hints as to the underlying problem. – Harry Johnston Jan 8 at 18:10
  • 1
    IIRC, the overlap and duplicate ownership errors are normal, as is the file not found at the end. The hash errors are likely to represent a real problem, can you copy those lines into your question? – Harry Johnston Jan 8 at 22:52
  • 1
    Hmmm. I was expecting there to be some indication of which copy of install.ins it was upset about. Looks like they are text files, though, so if one or more of the copies in the SxS folder are corrupt it might be obvious just from opening them in notepad or typing them at the command line. But also, those are just Info class messages, not warnings or errors, so perhaps they're not the cause of the problem after all. – Harry Johnston Jan 9 at 17:43
  • 1
    Looks identical to one of mine, except for the Windows version number which is to be expected since I'm still on 1709. Looking less likely to be the problem, IMO. If you're willing to email me your cbs.log (the entire period from just before the start of an update attempt to when it fails) I can have a look at it if you like, see if I can spot anything else. Or you might try the Windows forums, might be someone there with a bit more experience troubleshooting this particular sort of issue. – Harry Johnston Jan 9 at 20:39
  • 1
    Probably something about the OEM image that wasn't cloneable. Not sure what further diagnostic steps to suggest, perhaps Process Monitor to see if it will capture the underlying failure? One thing you could try as a workaround is an offline update, booting to external media or the recovery environment and using dism with the /add-package option. If you're really lucky an offline install of the December cumulative update will not only work but also fix the problem, so that the January cumulative update installs normally, though that's a long shot. – Harry Johnston Jan 11 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.