随着我们一直在尝试排除故障，我对这个问题的理解发生了变化。在阅读整个正文之前先向下滚动并阅读“更新 6”可能更有意义。
我们似乎在运行 1803 的较新机器上遇到了一些重大的 Windows 更新问题。
KB4483234 无法循环安装。如果从 WSUS 中删除它，它仍会尝试安装到本地 PC。
经过一番研究，我最好的猜测是因为 KB4483234 是 SSU KB4477137 的一部分。在 KB4483234 的 Windows 支持页面中，它说
“如果您使用的是 Windows 更新，最新的 SSU (KB4477137) 将自动提供给您。要获取最新 SSU 的独立包，请转到 Microsoft 更新目录。” https://support.microsoft.com/en-us/help/4483234/december192018kb4483234osbuild17134472
但是，WSUS 有 4477137 和 4483234 的单独条目。我不完全确定它是如何工作的，因为一个在 12/11 发布，另一个在 12/19 发布。但据我所知，我们目前将 4483234 标记为已批准移除，但似乎没有采取。
即使我这样做
dism /online /remove-package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~17134.472.1.0
然后在 WSUS 中将其标记为拒绝，当我提示 Windows 更新查询更新时，此更新仍然显示。
所以我决定尝试开始删除 4477137。当我尝试手动删除它时
dism /online /remove-package /PackageName:Package_for_KB4477137~31bf3856ad364e35~amd64~~17134.464.1.0
它失败了，仔细阅读日志会发现这一行：
DISM DISM 包管理器：PID=4600 TID=5116 无法卸载永久包。- 获取CbsErrorMsg
我意识到我可以编辑一些 MUM 文件来删除它，但我怀疑这是否会导致更多问题。我最终需要安装它才能获得下一个汇总，不是吗？
所以，我很好奇其他人是否对这两个更新有问题。我正在寻找有关这两个更新如何连接的说明 - 因为知识库文章似乎建议它们应该嵌套在一个更新下，但我显然有两个更新。最终，我想知道解决此问题的最佳方法。目前这正在影响我们的一些生产机器，因为当有更新待处理时我们无法安装 Windows 功能，但这些更新只是失败并返回待处理状态。我很茫然！
更新 1：
Windows 更新日志中似乎出现的唯一错误消息是 0x800F0922。这似乎是一个非常笼统的信息。因此，我们尝试了以下方法：
Ran SFC Scannow 和所有 DISM cleanup-image 命令，没有变化。
我为系统保留分区分配了一个驱动器号 - 可笑的是未满（430+MB 没有 500MB）
我通过重命名 Windows/SoftwareDistribution 和 Windows/System32/catroot2 来重置 Windows Update 组件，没有任何变化。
我为 .NET Framework 3.5 和 .NET Framework 4.7 启用了所有未选中的功能，没有任何变化。
我完全删除了所有 .NET Framework 功能，没有任何变化
我重新安装了正常的 .NET 功能，没有任何变化。
我已经运行了 Windows 更新疑难解答。
我尝试直接从 Windows 目录安装更新。
更新 2：
一条评论建议我清理临时文件夹。我进行了有条不紊的清洁；
我让更新失败，所以 Windows 更新中没有挂起的更新，我清理了我的 %temp% 文件夹和 windows/temp。重新启动，下载更新，安装，相同的行为。
我做了同样的事情，但将磁盘清理加入其中，没有改变。
我让更新下载并安装，直到它们等待重新启动，然后我检查并清理了临时文件夹并再次运行磁盘清理。行为仍然没有改变。
更新 3：
我还想提一件事：我只是重新阅读了我的原始帖子，并且有一点遗漏。
KB4471324 也无法安装。因此，KB4477137 安装良好 - 我将其误解为连接到其中一个回复指出的 KB4483234 - 但 KB483234 和 KB4471324 都卡在此循环中。
更新 4：
CBS 日志中的一些行
在这个带有哈希错误的位之前是一长串的注册表重叠，然后是一小段目录重叠。什么会修改这些文件以更改哈希值？它更可能是腐败，还是更邪恶的东西？
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}
更新 5：
检查 install.ins 文件。其中有 8 个，4 对 x64 和 x86 风格。最近的是
C:\Windows\WinSxS\amd64_microsoft-windows-ie-adminkitbranding_31bf3856ad364e35_11.0.17134.407_none_99e01535d6e245c0\install.ins
上次修改时间为 2018 年 11 月 9 日。
[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
更新 6 和可能的原因
所以，我们处理的初始参数是错误的。这并没有影响 1803 上的所有机器。我们只有 1803 上的几台随机机器，以及大量相同的新机器。我们运行 1803 的两台笔记本电脑最终完全遇到了其他一些更新问题。上述问题完全是新一批机器独有的。
购买新机器有两个原因，一个是为了升级我们的两个高端部门，另一个是作为使用 MDT 自动化 PC 部署概念的最终证明。因为它们都是相同的硬件，而且我们还没有 VLSC 许可证（我们想首先证明购买的合理性），所以我捕获了他们的 OEM 基础映像，将 Chocolatey 安装放入其中，然后使用 Chocolatey 批处理脚本点击它，并将其弹出到具有 GPO 的部署 OU 中，以便通过 MDT 进行部署。这是这些机器在以这种方式部署后遇到的第一个累积更新。
我们现在有了 VLSC 基础镜像，我用新的基础镜像将相同的任务重新部署到相同的硬件上，一切似乎都没有问题。
我仍然很想看看我是否可以修复当前部署的图像。我部署了 13 台 PC 和两台备用计算机，但我宁愿不通过进行另一次完全交换来打扰我们所有的 Web 开发人员和图形设计师。但我至少有一个“修复”在桌子上。
我更改了帖子标题以反映一些不断变化的参数
