（六）部分取代（微软官方在取代列表Package Details里面或微软支持信息页面虽然列出了此补丁已被取代，但是不打还会继续推送）
1、KB2978120  2014年09月10日.NET3.5.1补丁。最早被KB4041083（2017年09月12日.NET汇总）官载取代，见KB4041083微软支持信息页面
2、KB3118401  2015年12月13日通用C运行库，修复KB2999226。最早被KB4015549（2017年04月11日月度汇总）官载取代
3、KB3185319  2016年09月02日IE11累积安全更新程序。最早被KB3185330（2016年10月11日月度汇总）官载取代

更新一下

（五）常见无公告取代或直接被微软废弃的情况（既不是官载取代也不是推送取代）
KB0977206  2010年01月04日免除Windows Virtual PC和XP Mode的硬件需求       微软于2010年3月18日取消了Windows XP Mode对硬件虚拟化技术的强制要求，故此补丁已被微软废弃
KB2533623  2011年06月05日Windows新的API增强功能       被KB3063858及后续月度汇总取代
KB2639308  2011年11月21日支持ASLR(地址空间布局随机化)新功能       ASLR 技术本身存在一定局限性（如内存地址随机化范围有限、绕过攻击手段演变等），故KB2639308难以适应现代攻击防御需求，已被微软废弃
KB2731771  2012年08月22日提供了用于本地时间和UTC之间转换的新API       被KB2758857、KB2726535及后续月度汇总取代
KB2913751  2013年11月27日RDP 8.1更新       被KB2923545取代，见KB2923545的微软支持信息里面的“更新替换信息”
KB4012212  2017年03月28日仅安全更新，永痕之蓝补丁       被后续月度汇总取代
三个跟HyperV有关的补丁：
KB3063109  2015年10月 1、修复了虚拟机（VM）与宿主机之间的数据通信异常问题，解决部分场景下虚拟机无法正常接收网络数据包的故障。2、优化了Hyper-V虚拟机的动态内存管理，提升内存分配效率并降低性能波动。已被微软废弃，被KB3125574及后续月度汇总取代
KB3158627  2016年04月 1、解决了虚拟机快照功能的安全漏洞（CVE-2016-3213），防止恶意程序通过快照文件篡改宿主机系统。2、修复了Hyper-V虚拟交换机（vSwitch）的权限控制缺陷，避免未授权用户通过虚拟网络接口获取宿主机敏感信息。已被微软废弃，被KB3125574及后续月度汇总取代
KB4072650  2019年08月 该补丁是对Hyper-V的Spectre/Meltdown漏洞的缓解方案，具体修复：1、引入了虚拟化层级的隔离防护，防止恶意虚拟机通过侧信道攻击窃取宿主机或其他虚拟机的内存数据。2、调整了Hyper-V的调度器逻辑，降低因漏洞缓解导致的虚拟机性能损耗（注：部分老旧CPU可能仍存在兼容性问题）。已被微软废弃，被后续月度汇总取代

将原来的继承取代定义取消，改为：
2、官载取代：由微软官方在取代列表Package Details里面详细记载的取代关系。

外网有一种取代的定义：元数据取代metadata-supersedence。该取代类型由微软在服务器端更新补丁的元数据信息触发。当新补丁发布时，微软会通过元数据标记旧补丁为“被取代”，导致旧补丁从WU推送列表中移除。在此场景中，补丁B被标记为取代补丁A，因此安装B后，系统根据元数据判断B已覆盖A的功能，无需重复推送A，故A从列表中消失。所以，这种元数据取代跟我的推送取代就是一样的定义。

重新细分取代关系：
取代关系：
1、卸载取代：已知旧补丁A是新补丁B的子集，且打了旧补丁A，紧接着再打新补丁B，重启后旧补丁A从卸载更新列表（uninstall updates list）中消失。即可判断新补丁B卸载取代了旧补丁A。旧补丁A被完全卸载了，荡然无存‌、了无痕迹。此时可以选择跳过旧补丁A，只打新补丁B。
比如：KB5017361（2022年9月度汇总）是KB5044356（2024年10月度汇总）的子集，打了KB5017361，紧接着再打KB5044356，重启后作为旧补丁的KB5017361将从卸载更新列表中消失，这种就是卸载取代。可以选择跳过KB5017361，只打KB5044356。
注：卸载取代一般常见于月度汇总之间。服务堆栈之间并不存在卸载取代，打了A堆栈，再打B堆栈，两者并存，所以不符合卸载取代的判断条件，比如已知旧堆栈KB3020369（2015年05月12日服务堆栈）是新堆栈KB4490628（2019年03月服务堆栈）的子集，则可以跳过旧堆栈KB3020369，只打新堆栈KB4490628。
2、继承取代：已知旧补丁A与新补丁B相交，且打了旧补丁A，紧接着再打新补丁B，重启后旧补丁A从卸载更新列表中消失，旧补丁A不同于新补丁B的修复或影响被新补丁B继承了下去。即可判断新补丁B继承取代了旧补丁A。旧补丁A虽然从卸载更新列表中消失，但是它与新补丁B藕断丝连，打断骨头连着筋。
比如：KB3197868月度汇总与KB2631813是取代关系，前者取代后者，KB4534310月度汇总不取代KB2631813，且KB3197868月度汇总与KB4534310月度汇总相交。此时打了KB3197868，紧接着再打KB4534310，重启后作为旧补丁的KB3197868将从卸载更新列表中消失，新补丁KB4534310继承了旧补丁KB3197868对KB2631813的取代关系。这种就是继承取代。
注：继承取代一般常见于旧的月度汇总（2018年以前）与新的月度汇总（从2018年1月开始）之间。服务堆栈之间也不存在继承取代，已知旧堆栈A与新堆栈B相交，打了A堆栈，再打B堆栈，两者是并存关系。比如：旧堆栈KB4490628（2019年03月服务堆栈）与新堆栈KB5039339(2024年06月服务堆栈）相交。
3、推送取代：已知旧补丁A、新补丁B均为WU推送列表（WU push list）中的补丁，且仅仅打了新补丁B后，重新检查WU，旧补丁A从WU推送列表中消失。即可判断新补丁B推送取代了旧补丁A。很多时候，我们很难判断旧补丁A是否被新补丁B取代，直接交由Windows Update更新机制去判断是最简单的方法。倒序安装也是由此而来。
比如：KB2631813、KB3110329均为WU推送列表中的补丁，打了KB3110329后，重新检查WU，KB2631813已经从WU推送列表中消失，即可判断KB3110329取代了KB2631813，这种就是推送取代。
注：旧的定义是，打了A补丁，导致B补丁消失，称为A补丁取代了B补丁。就是指上面的推送取代，一般常见于补丁与补丁之间或月度汇总与补丁之间（除了月度汇总之间和服务堆栈更新之间的卸载取代和继承取代）。本帖大部分都是推送取代。推送取代命名还是有点不妥，但是暂时想不出更好的，再就是还有一种清理取代，也暂不进行定义，常见的也就这三种了。

@lanrsgwaijyut,@gwaijyut, 能否通过wu733交换个联系方式，我最近大半年也一直在研究这个，很想有共同兴趣者能沟通一下。无白痴问题，不无故骚扰。

声明：

由于BypassESU-vX采用的代理路线跟最新的ESU方案不一致，所以2023年1月10日以后，且Bypass后的WU的推送是假的，这时就不要开WU了，只能采用UpdatePack7R2去处理。也由于我未能及时发现其中的奥秘，导致了错误的推导，请大家原谅！！！

厉害了，谢谢分享

来顶个贴
以后在这边混了

顶顶顶，真正的技术贴

一、取代及衍生关系：
四）一些功能性补丁的取代及衍生情况
新增：
KB3110329（2015年12月09日多个远程漏洞）       取代了KB2631813（2011年11月3日远程漏洞）

wu733 发表于 2025-2-4 11:54
新增第三大点：
三、非ESU补丁方案与ESU补丁方案的怪异之处：
1、KB2631813（2011年11月3日远程漏洞）

KB2676562已经被取代了，无论是否ESU。建议再看看。
这边没法用短消息，那边处处受限，这环境真是没法愉快的玩耍啦！
KB2813347、KB3123479这两个我还没测试

感谢分享

lanrsgwaijyut 发表于 2025-2-11 13:05
是的，24.10.08版本不包含ESU补丁，更新线路已回归到非ESU方案的原始服务器。
BypassESU-v12/u使用esu.d ...

感谢你的告知，我还真没注意到这些

wu733 发表于 2025-2-11 12:58
“自20.5.20版起，Simplix使用了abbodi1406的ESU 补丁，23.3.15版(含)之后，移除了这个补丁”
意思是我 ...

是的，24.10.08版本不包含ESU补丁，更新线路回归到非ESU方案节点。
BypassESU-v12/u使用esu.dll(以及wuaueng.dll等其他库文件)将系统标记为ESU授权版本/或嵌入式ESU授权版本，绕开ESU检测，用以达成可联机更新的目的，
BypassESU-v13f也是一样的，与12/u的区别在于，批处理中加入了旁路的可选项，联机更新时，13f将系统标记为2008R2（或Windows Embedded Standard 7）.

lanrsgwaijyut 发表于 2025-2-11 12:53
隔壁那边已经没法正常交流了，这边重新写一遍吧
如果使用UpdatePack7R2做测试，建议使用23.1.11或23.2.4 ...

“自20.5.20版起，Simplix使用了abbodi1406的ESU 补丁，23.3.15版(含)之后，移除了这个补丁”
意思是我使用UpdatePack7R2-24.10.10版本就是未使用abbodi1406的BypassESU-v12，我的理解对不对？

wu733 发表于 2025-2-11 12:24
我改用UpdatePack7R2-24.10.10.exe（不采用BypassESU-v12）爆破非KB3125574方案镜像（2024.10.08），结果 ...

隔壁那边已经没法正常交流了，这边重新写一遍吧
如果使用UpdatePack7R2做测试，建议使用23.1.11或23.2.4版本。
原因是，自20.5.20版起，Simplix使用了abbodi1406的ESU补丁，23.3.15版(含)之后，移除了这个补丁。因为2023年1月，微软停止了对Win7的所有支持。
不使用ESU补丁的UpdatePack7R2版本，所集成的客户端WU默认使用“非ESU”更新节点(微软的“非ESU”WSUS)

lanrsgwaijyut 发表于 2025-2-11 11:14
KB2533552是一个必要的补丁，不可或缺。
如果不使用，在安装月度汇总之后，可能会因为无法验证winload.exe ...

我改用UpdatePack7R2-24.10.10.exe（不采用BypassESU-v12）爆破非KB3125574方案镜像（2024.10.08），结果推送也是9个补丁

不错。越方便越好。

KB2533552是一个必要的补丁，不可或缺。
如果不使用，在安装月度汇总之后，可能会因为无法验证winload.exe签名而无法开机。但又因为这个堆栈补丁不能倒序安装，微软在推送的时候干脆以SP1的编号（KB976932_9M+）命名，以绕开他自己的限制

感悟：

其实吧，补丁或月度汇总之间的取代、衍生关系从狭义上来说是正确的，但是从广义上来说，又不是正确的。比如说，非ESU补丁方案中，KB3110329取代了KB2631813，从狭义上（非ESU补丁方案）来说是对的，但是从广义上（ESU补丁方案）来说却是错的。也就是说，表面上打了A补丁，导致B补丁消失，A补丁取代了B补丁，这个A补丁只是诱因，决定权却在更新机制手上。换个角度解释就是：由于非ESU方案的月度汇总时间早，其它要打的补丁比ESU的要多，而ESU的月度汇总时间晚，其它要打的补丁比非ESU的要少。故判断，ESU方案的月度汇总在逐步取代旧补丁的过程似乎是掉了链子，所以更新机制到最后实在看不下去了，不得不强行进行干涉的结果。

新增第三大点：
三、非ESU补丁方案与ESU补丁方案的怪异之处：
1、KB2631813（2011年11月3日远程漏洞）
非ESU补丁方案中：KB2631813是冗余，KB3110329（2015年12月09日多个远程漏洞）取代了它
ESU补丁方案中：KB2631813不是冗余，KB3110329未取代它

2、KB2676562、KB2813347、KB3123479这三个补丁
非ESU补丁方案中：上面三个补丁是冗余
ESU补丁方案中：上面三个补丁不是冗余

感谢楼主分享

二、依存关系：
（一）升级Win7的RDP协议版本到8.1，解决win7连接不了win10远程桌面：
补充：KB2984972+KB2574819→又衍生了KB2984976，也即开始若不打KB2984972就不会推送KB2984976）

更正：KB2984972+KB2574819+KB2592687→又衍生了KB2984976，开始若不打KB2984972就不会推送KB2984976）

hiro2025 发表于 2024-12-11 17:09
我是通过dism最先集成KB2533552补丁的，最后安装测试时发现不存在这个补丁，是被替换了还是没安装上，最后 ...

那就是你集成KB2533552补丁未成功，离线集成需要换个方法，网盘里面有集成的方法

我是通过dism最先集成KB2533552补丁的，最后安装测试时发现不存在这个补丁，是被替换了还是没安装上，最后系统更新是还提示KB976932。

wu733 发表于 2024-12-7 19:58
不用集成补丁，直接用大佬们制作的PE系统代替微软自带的PE不香么？

有是考虑的是恢复环境，如果不给winre.wim集成补丁的话，会对恢复环境有影响吧

感谢分享

谢谢分享