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

wu733 · 发表于 2025-7-17 17:30:15

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

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

gwaijyut · 发表于 2025-7-17 20:42:25

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 · 发表于 2025-7-17 20:58:27

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

gwaijyut · 发表于 2025-7-17 21:08:57

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

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

wu733 · 发表于 2025-7-17 21:26:25

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

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

gwaijyut · 发表于 2025-7-17 22:59:47

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

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

wu733 · 发表于 2025-7-17 23:09:38

本帖最后由 wu733 于 2025-7-17 23:58 编辑

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

gwaijyut · 发表于 2025-7-17 23:20:57

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

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

wu733 · 发表于 2025-7-17 23:38:21

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

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

gwaijyut · 发表于 2025-7-18 00:18:41

本帖最后由 gwaijyut 于 2025-7-18 00:38 编辑

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 · 发表于 2025-7-18 00:56:07

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 · 发表于 2025-7-18 01:07:11

本帖最后由 gwaijyut 于 2025-7-18 01:15 编辑

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

wu733 · 发表于 2025-7-18 10:23:46

本帖最后由 wu733 于 2025-7-18 10:38 编辑

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 · 发表于 2025-7-18 10:52:04

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

gwaijyut · 发表于 2025-7-18 12:13:57

本帖最后由 gwaijyut 于 2025-7-18 12:42 编辑

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 · 发表于 2025-7-18 12:37:19

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

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

gwaijyut · 发表于 2025-7-18 12:55:17

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

wu733 · 发表于 2025-7-18 13:06:18

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

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

wu733 · 发表于 2025-7-18 13:23:23

本帖最后由 wu733 于 2025-7-18 13:29 编辑

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

wu733 · 发表于 2025-7-18 18:34:49

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

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

wu733 · 发表于 2025-7-18 22:41:16

本帖最后由 wu733 于 2025-7-18 22:44 编辑

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

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

wu733 · 发表于 2025-7-18 22:48:11

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

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

Vansiper · 发表于 2025-7-18 23:28:39

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

gwaijyut · 发表于 2025-7-19 02:49:34

合并得了，研究点别的。

gwaijyut · 发表于 2025-7-19 02:54:12

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

gwaijyut · 发表于 2025-7-19 18:29:10

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

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

wu733 · 发表于 2025-7-19 21:26:20

gwaijyut 发表于 2025-7-19 18:29
"Win7 SP1 x64 批量授权专业版”无精简“集成2020年01月14日补丁"

请楼主复查：

这是日记本更新，是非必需补丁，我在文章里面已经详细说明了

wu733 · 发表于 2025-7-19 21:28:38

gwaijyut 发表于 2025-7-19 02:49
合并得了，研究点别的。

通过研究这个，我收获非常大，我准备完整的研究完所有补丁，最后的完整版也就相当于一个缩小版的KB3125574便捷包。这个完整版我不打算贡献出来了

wu733 · 发表于 2025-7-19 22:27:47

gwaijyut 发表于 2025-7-19 02:49
合并得了，研究点别的。

我已经完全掌握了规律，真的越来越有意思了

wu733 · 发表于 2025-7-20 08:04:47

gwaijyut 发表于 2025-7-19 18:29
"Win7 SP1 x64 批量授权专业版”无精简“集成2020年01月14日补丁"

请楼主复查：

KB2891144是非安全性热修补丁10-5，我提供的实体机系统其实是打全了所有十个非安全性热修补丁的。等我忙完这个，再追踪一下注册表即可解决到底是否需要全打

		自动登录	找回密码
密码			注册

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

点评

点评

点评

点评

点评

点评

点评

点评

浏览过的版块