Win7的“便利汇总” - KB3125574官载取代的66个补丁的取代情况

wu733

gwaijyut 发表于 2025-7-17 10:00
更正：这里为#112楼的不严谨言论致歉。
KB3125574 对系统有新增程序集，目前检索到的有：kbdinen.dll 。暂 ...

"也就是在使用 WU 完成所有非冗余的推送补丁的安装后，继续安装 KB3125574 ，整个系统的文件升级将更加完整。"

确实如此，KB3125574对系统的部分文件更新（23403）其实就是对程序质量或程序参数的改进（非安全性更新）。但是KB3125574并不仅仅只是对官载取代的这66个补丁进行了完全的文件更新，还对其它的补丁或多或少进行了部分的文件更新。比如，KB958830（域控管理RSAT工具）、KB2533552（2011年05月09日服务堆栈更新）。

其中，KB958830是WU不推送的，而KB2533552这个服务堆栈补丁经我研究发现：KB3125574、后续服务堆栈更新以及月度汇总对其的文件更新是非常混乱的（主要体现在系统当前正在使用的文件版本往往并不是最新的（23403或24545），而且文件版本也不统一，System32下是16385版，SysWOW64下却是17514，对此我感到非常疑惑）

小歌

什么时候能出个WIN7成版

wu733

新增KB3125574官载取代以外的补丁，这个视情况和时间进行后续更新

gwaijyut

KB958830 严格来说只是一个工具包，WU 不推送才正常吧。类似的其他工具包有很多，如果都推送，除了把系统变得更臃肿，似乎没有其他好处。作为工具包，按需使用比较妥当；

KB2533552 以及后期与之相关的更新，文件版本并不混乱。看上去混乱，大概是因为 SSU 的特殊性，即不支持手动删除。其次，与 SSU 程序集的清单文件（.Manifests）也大有关联。
文字功底有点不够用，请忽视以下描述的杂乱：
1、在安装补丁之前，程序集管理器将先检查是否具备安装条件，具备则继续，否则报错；
2、如果你读过 BypassESU 源文件中有关绕过 ESU 检查的部分，会发现 BypassESU 其实是通过伪造的 Manifests 文件，以及虚构的注册表信息，模拟了一个“ESU已授权”的环境；
3、类似的，SSU 也通过 Manifests 文件，以及册表信息，应答补丁对安装环境的检测。SSU 程序集中某些二进制文件的新版本，不见得全部用于替换系统的默认文件，附加的(或更主要的)作用，是对“待安装”的补丁提供所需依赖(例如环境检测等)；
4、按微软的建议，始终应该使用最新的 SSU，基于此，我个人的看法，KB2533552，甚至 KB4490628(注)，都不再被需要；
5、最新的 SSU 不受 ESU 条件约束
注：KB4490628 为 KB4534310 提供安装环境，与此同时，微软提供了一个比 KB4490628 更新的SSU: KB4536952。明显的，这么做是为了向 ESU 过渡。这个时候的 KB4536952，还需要 KB4490628 作为前置。自 KB5031658 起，不再需要 KB4490628 作为前置补丁。

wu733

gwaijyut 发表于 2025-7-17 16:25
KB958830 严格来说只是一个工具包，WU 不推送才正常吧。类似的其他工具包有很多，如果都推送，除了把系统变 ...

关于后续补丁对这个KB2533552服务堆栈补丁的文件更新，我想没有这么简单（固化）。至于KB2533552是不是冗余（abbodi1406认为是），以及KB4490628是不是冗余，其实只要大胆去实验我相信肯定会得到答案的。

gwaijyut

wu733 发表于 2025-7-17 17:30
关于后续补丁对这个KB2533552服务堆栈补丁的文件更新，我想没有这么简单（固化）。至于KB2533552是不是冗 ...

关于 KB4490628 是否不再需要，尚待进一步验证。

KB2533552 这个补丁，抛开是否冗余不谈，为什么其程序集中的部分文件，在system32 和 syswow64 目录中存在同名文件的不同的版本，是因为，这些同名文件的来源不同。

这里提供一个分析思路：
一、准备工作：
1、从 msu 包中提取 KB2533552 的程序集清单：amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.17592_none_672ce6c3de2cb17f.manifest，以及包容器清单：_manifest_.cix
2、阅读 support 站点关于该补丁的说明，其中有一句不起眼的描述：
     注意 更新包中的文件可能会添加到 %windir%\WinSxS\ 文件夹中，而不是 %windir%\System32\ 文件夹。


二、分析程序集：
1、使用文本编辑器打开程序集清单 amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.17592_none_672ce6c3de2cb17f.manifest
      文件中的 sourceName 被显式定义，这表明，该 manifest 文件复制的所有文件都存储在更新包根目录(%windir%\WinSxS\)内的 amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.17592_none_672ce6c3de2cb17f 目录中；
2、该目录中的 39个对象，就是 KB2533552 包含的程序集。在驱动器的其他位置，如有同名文件，通过对比文件版本或hash，可判断同名文件是否同源；
     例如 cmiv2.dll 文件，在 system32 和 syswow64 目录就使用了不同的版本，需要注意的是，这两个目录中的 cmiv2.dll，与 KB2533552 无关。
3、使用文本编辑器打开包容器清单 _manifest_.cix 其中详细记录了程序集的版本及其他信息；
4、任何其他补丁（包括便捷补丁包以及月度汇总）都不会修改、替换 amd64_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.17592_none_672ce6c3de2cb17f 目录中的程序集，但是，有可能会修改、替换该目录之外的同源文件。
      这里说的有可能，呃，是因为我还没检测。。。。。


忙着去喝大酒，回头找时间再看看

freehead88

KB4490628是升级到RDP8.1的前置组件之一，拿掉它，你看看能不能升级rdp8.1,,假如不能，这个组件就是必须的

gwaijyut

freehead88 发表于 2025-7-17 20:58
KB4490628是升级到RDP8.1的前置组件之一，拿掉它，你看看能不能升级rdp8.1,,假如不能，这个组件就是必须的

这个没什么影响，使用比KB4490628更高版本的SSU，任何推送补丁都可以正常升级。

wu733

gwaijyut 发表于 2025-7-17 21:08
这个没什么影响，使用比KB4490628更高版本的SSU，任何推送补丁都可以正常升级。

先避开KB2533552不说，关于这个KB4490628，很多大佬早有定论，认为其并不完全包含于后续的SSU（有交集，但不是包含关系），属于承前启后的存在。

gwaijyut

wu733 发表于 2025-7-17 21:26
先避开KB2533552不说，关于这个KB4490628，很多大佬早有定论，认为其并不完全包含于后续的SSU（有交集， ...

承前没问题，不使用 ESU 的时候，它必须有

wu733

KB3125574官载取代以外的补丁已经更新到30个，其中有3个已被KB4534310月度汇总全部文件更新

gwaijyut

wu733 发表于 2025-7-17 23:09
KB3125574官载取代以外的补丁已经更新到30个，其中有3个未被KB3125574文件更新

此话怎讲？66 个官载至今也没剩几个了，你这里说的 3 个未包含，有没有包含在 KB574 的初版之中？

wu733

gwaijyut 发表于 2025-7-17 23:20
此话怎讲？66 个官载至今也没剩几个了，你这里说的 3 个未包含，有没有包含在 KB574 的初版之中？

我改一下，表达的意思不是很准确

gwaijyut

wu733 发表于 2025-7-6 00:07
6.1.760x（包括6.1.7600、6.1.7601）、7.1.7601、7.2.7601版本的增量文件夹下，还需要分别提取6.1.7601、 ...

"经验证，6.1.7600和6.1.7601版的增量可以全部使用6.1.7601版的最新稳定版进行替换，因为我发现非KB3125574系统中微软官方就是这么干的"

你说的没错，这是特例。在“源”一致的情况下，可以这么干，微软是会这么干。

那么现在问题来了，如何判断“源”一致？在系统文件夹(例如 Windows)内，存在多个版本的 Test.dll 文件，如何区别他们？有没有一种可能，它们在各自的文件夹(路径)下，扮演不同的角色，分担不同的任务。虽然同名，却功能相异。
遇到这种情况，分类讨论是不是更接近替代的本质：同源是取代或半取代；异源则毫无关系。

wu733

gwaijyut 发表于 2025-7-18 00:18
"经验证，6.1.7600和6.1.7601版的增量可以全部使用6.1.7601版的最新稳定版进行替换，因为我发现非KB31255 ...

不是很好描述，感觉很费劲。
简单的说就是，先在虚拟机系统（KB3125574方案，我在文章中所提到的环境）的winsxs文件夹下搜索目标补丁winsxs下的同类增量（去掉版本号及后缀，比如amd64_microsoft-windows-d..frameworks-usermode_31bf3856ad364e35_6.1.7601.22004_none_fbcbe08624f8cec3），若是搜索到的增量有最新日期更新，则再看其版本号，若是仅有一个23403则表示仅被KB3125574更新了，若是存在两个比如24000、23403，则表示月度汇总或其它更新取代了KB3125574更新。然后，winsxs下查找到的23403版增量下的每个文件是否在Windows下存在？继续搜索，若搜到，比如System32下存在此文件且版本为23403版，则表示当前系统正在使用23403版，如此即可将winsxs下的同类增量的所有文件全部用23403版进行更换。

gwaijyut

找到我们看法的差异了。同名文件的"同源"或"异源"。你关注一下。
不同KBs之间（异源），各自包含的程序集的文件名，会有交集。名称的交集与取代无关。各司其职。

wu733

gwaijyut 发表于 2025-7-18 00:18
"经验证，6.1.7600和6.1.7601版的增量可以全部使用6.1.7601版的最新稳定版进行替换，因为我发现非KB31255 ...

再简单的描述一种特殊情况，若是winsxs下的同类增量，比如KB2620704，如图1、图2、图3。此同类增量下的每个文件在当前虚拟机系统（KB3125574）Windows下找不到（搜索），也即只有winsxs下的增量。
那么，如何判断当前系统使用哪个文件版本呢？
此时，只需在实体机（非KB3125574）系统中查找如图2中的增量，找到三个同类增量，如图4。然后将此三个同类增量拷贝到临时文件夹中以备分析查看，如图5。
分别展开如图5的三个同类增量，可以发现这三个同类增量下的文件版本，被系统全部替换成了同一版本17699
故可以据此判断KB2620704的winsxs下的同类增量，虽然在当前虚拟机系统中的Windows下找不到，但是由于实体机（非KB3125574）中微软官方是将此三个同类增量全部替换了同一版本17699，故依葫芦画瓢（用微软的手法），将如图2中的增量下所有文件全部替换成23403版即可。

wu733

验证环境完整描述：
截止到2020年01月14日月度汇总KB4534310为止，采用整体打补丁的方法，而不是仅局限于以下41个补丁。实体机安装非KB3125574方案的系统，虚拟机则安装  “以非KB3125574补丁方案做为基础，并采取KB3125574在前，月度汇总KB4534310在后，实际上是KB3125574方案”  的系统。如此，即可方便进行文件版本的查询、比较及分析。

gwaijyut

wu733 发表于 2025-7-18 10:23
再简单的描述一种特殊情况，若是winsxs下的同类增量，比如KB2620704，如图1、图2、图3。此同类增量下的每 ...

"可以据此判断KB2620704的winsxs下的同类增量，虽然在当前虚拟机系统中的Windows下找不到，但是由于实体机（非KB3125574）中微软官方是将此三个同类增量全部替换了同一版本17699，故依葫芦画瓢（用微软的手法），将如图2中的增量下所有文件全部替换成23403版"

建议你不要这么干。

作为判断文件升级/替换的方法之一，这么验证没什么问题。
一旦做文件替换，涉及的内容实在是太过庞杂，非人力可为。

沿用你举的例子，amd64_microsoft-windows-wab-core_31bf3856ad364e35_6.1.7600.16385 目录下，KB3125574 升级(替换)了 3 个 DLL：
wab32.dll、wab32res.dll、wabimp.dll
这三个文件均被升级到 23403
能不能将这三个新版本的文件，拿到“非574”环境中，替换原始旧版呢？我认为是不能替换的。理由如下：

1、同名文件不同版本的文件校验值不同，这些校验值在注册表、系统目录等位置有复杂的对应关系，这是重点；
2、很多 DLL 文件除了在系统目录被调用，还在其他程序目录被调用。例如本例中的 3 个 DLL ：
     wabimp.dll 在 “C:\Program Files (x86)\Windows Mail” 被邮件程序调用；
     wab32res.dll 在 “C:\Program Files\Common Files\System” 被通讯录调用；
     wab32.dll 在 %CommonProgramFiles%\System\ 及  %CommonProgramFiles(x86)%\System 下被通讯录调用
     这三个文件在不同的程序目录中均被同步升级。尽管不可能每个 DLL 都存在这个情况，涉及到的数量也是不可想象的。

“旧壶装新酒”的做法，在涉及的文件不多，且操作不复杂的情况下，问题不大。比如替换系统图标为太阳谷、系统主题美化、字体替换等。补丁程序的安装/修改，人为操作的方案是不太妥当的。

wu733

gwaijyut 发表于 2025-7-18 12:13
"可以据此判断KB2620704的winsxs下的同类增量，虽然在当前虚拟机系统中的Windows下找不到，但是由于实体 ...

“建议你不要这么干”
好吧，多谢您的提醒。但是我已经这么干了，而且替换后系统运行非常正常。当然由于人力不足，也可能存在瑕疵或遗漏的地方。我也希望各位补丁大神能够在我所做的基础上进一步完善它。

gwaijyut

探索一切可能，本身就值得鼓励。建议楼主放出封装版本，给各路大神协助测试，这样的测试最好能在实体机做。
“合体版”中的 system32\drivers 目录，这个有待验证。最好不要涉及这个目录。KB3125574 的很多毛病就出在驱动上。

wu733

gwaijyut 发表于 2025-7-18 12:55
探索一切可能，本身就值得鼓励。建议楼主放出封装版本，给各路大神协助测试，这样的测试最好能在实体机做。 ...

“KB3125574 的很多毛病就出在驱动上”
此话怎讲，还请大佬细细道来

wu733

验证环境提供：
由于人力不足，可能存在瑕疵或遗漏的地方。希望各路大神能够在我所做的基础上进一步完善它。
实体机安装的非KB3125574补丁方案的系统下载链接：
Win7 SP1 x64 批量授权专业版”无精简“集成2020年01月14日补丁  提取码：dZbb
补丁方案可参照强迫症方案：非KB3125574+IE11补丁方案（2020.01.14 非ESU） 提取码：3S0B
虚拟机安装的KB3125574的系统，则可以在上面非KB3125574补丁方案系统上，先卸载月度汇总KB4534310，然后再依次安装KB3125574便利汇总、月度汇总KB4534310。

wu733

gwaijyut 发表于 2025-7-18 00:18
"经验证，6.1.7600和6.1.7601版的增量可以全部使用6.1.7601版的最新稳定版进行替换，因为我发现非KB31255 ...

其实还有一种特殊情况，我记得是拓展补丁（16-30）中靠后的一个，我确实做错了，我等会再检查一下

wu733

wu733 发表于 2025-7-18 12:37
“建议你不要这么干”
好吧，多谢您的提醒。但是我已经这么干了，而且替换后系统运行非常正常。当然由于 ...

非常感谢，我终于发现问题所在了，看来所有补丁替换的问题我得从头检查了，有些情况我画蛇添足了或者说被我忽视了，虽然有问题的只是少数

wu733

wu733 发表于 2025-7-18 12:37
“建议你不要这么干”
好吧，多谢您的提醒。但是我已经这么干了，而且替换后系统运行非常正常。当然由于 ...

都怪KB3125574便捷包的不足，本来是不需要的，你偏偏还要添加

Vansiper

多谢分享，非常实用的帖子。

gwaijyut

合并得了，研究点别的。

gwaijyut

KB3125574 唉！我始终记得曾经是推送的，至少推送过一段时间。现在回头一查，这补丁从来不推送，需要自行下载。那不如跟WU配合使用。过几天我找环境实测看看

gwaijyut

"Win7 SP1 x64 批量授权专业版”无精简“集成2020年01月14日补丁"

请楼主复查：
该系统缺少一个补丁：KB3138378 该补丁在 2020 年 1 月之前，仅被 KB3125574取代，没有被 KB4534310 取代，你的“合体版”中也未包含；
有一个补丁不需要：KB2891144 该补丁仅用于 Windows 2008 R2 SP1