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

Sam K
  • 506
  • 5
  • 20

1 Answers1

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.)

Community
  • 1
Harry Johnston
  • 5,875
  • 4
  • 35
  • 52
  • Unfortunately the only error message that comes up is 0x800F0922. This seems like a very generic error message and we've done most of the items suggested to combat that error message. I'll update the top post with more details, but we've ran sfc and the dism cleanup-image commands. The system reserved partition has tons of free space. We enabled ALL .NET 3.7 and 4.7 components. Then removed them all. Then reinstalled the basic components. We've run the Windows Update troubleshooter. All of these steps included an attempt to install - no changes so far. – Sam K Jan 08 '19 at 13:46
  • Oh - and tried the manual install as well with no change in behavior :/ – Sam K Jan 08 '19 at 13:50
  • 1
    Have you checked for [this problem?](https://superuser.com/a/1383752/96662) 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 08 '19 at 18:10
  • I hadn't checked that problem, no, but from the looks of it my system/boot partition is indeed set to a type of c12a7328-f81f-11d2-ba4b-00a0c93ec93b I'll take a look through the CBS logs – Sam K Jan 08 '19 at 20:09
  • There are several repeating warnings and errors in my CBS log. There's tons of 'Warning: Overlap: Registry value collision found under key only one component should set this value. There's several errors towards the end, all having to do with duplicate ownership for directories, there's 6 of them. There's two hash errors for install.ins Then a few items dealing with the report after the failure, Not able to add %windor%\winsxs\pending.xml to the WER report. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND] – Sam K Jan 08 '19 at 22:27
  • 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 08 '19 at 22:52
  • Done. I just got in the for the morning so I'll delve into that portion of the error as well! – Sam K Jan 09 '19 at 13:15
  • 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 09 '19 at 17:43
  • So there's 8 copies, basically 4 sets of two for either x64 or x86. They all open in notepad++. The only difference in them is the trailing build number at the end of Wizard_Version and Version. These INS files seem to be connected to IE/Edge and those are Edge build numbers it seems. I'll post one in my OP. – Sam K Jan 09 '19 at 18:51
  • 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 09 '19 at 20:39
  • So, I've at least isolated the cause. We purchased a batch of new machines both to upgrade two of our higher end departments (art and web/ecommerce) but also as a final test for switching to automated deployments with MDT. My boss didn't mind spending the money on a VLSC license, but wanted proof of concept. So I captured the base OEM image and basically deployed it with chocolatey and a batch script to run chocolatey with our apps. It also deployed into a deploy OU with some GPOs. That went well (until now) and I now have a base image made with VLSC media. The new base image works, more in OP – Sam K Jan 11 '19 at 17:01
  • 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 '19 at 20:50
  • 1
    ... failing that, there's a reasonable chance that upgrading to 1809, or doing an in-place reinstall of 1803, will fix it. (Although it might also completely bork the machine, so be prepared!) – Harry Johnston Jan 11 '19 at 20:54
  • That's basically what I've whittled down to, though the offline update sounds like a fantastic idea actually; I'll add that to my to-do list. With the 2 spare machines I've created one machine with the new VLSC media and am experimenting with migrating my profile using USMT (I have one of the affected machines), I was going to clone my old/current desktop to the second spare and try one with an in-place reinstall and the other an upgrade to 1809 (since the web dept indicated they wanted more dark mode!) It'll probably take a few business days to flush that all through but will report back. – Sam K Jan 11 '19 at 21:11
  • The 1809 update did the trick without bricking anything, and we certainly won't use that base image anymore, thanks for the help! – Sam K Jan 16 '19 at 20:04