Win7 SP1集成补丁过程的取代、衍生和依存关系归纳汇总(持续更新中......)

wu733

新增一对取代关系：
KB3172605  2016年09月09日更新汇总       取代了KB3042058  2015年04月19日默认密码套件顺序更新。

经验证，KB3172605将KB3042058中的所有组件全部更新到了23539或23452版（从KB3125574开始，此时的KB3172605已经没有LDR分支）。奇怪的是，无论KB3172605，还是KB3042058，它们的Package Details列表中均没有明确描述这一取代关系，后面又经验证，此取代关系归类为推送取代。当然如果你不考虑KB3172605，则必须安装KB3042058

2010iirabbit

好东东，现在还有更新吗

wu733

六个跟HyperV有关补丁的取代路线（感谢隔壁gwaijyut提供这一至今困扰我的取代关系）：
KB3063109→KB3158626→KB3158627→KB4021918→KB4072650→KB4072650-x64-r2(2019,Final)
由于取代链中的很多补丁无法下载，所以无从验证。不过大家还是要感谢gwaijyut，他就像划破黑暗中的一道闪电，指引着至今还在坚守Windows7的粉丝（包括我）继续前进！！！

gwaijyut

"4、再说一个微软支持信息错误的地方，打开微软补丁网址，然后搜KB4041083（包含KB4040980，只搜KB4040980是搜不到的），你再看它的微软支持信息：此更新替换更新KB2978120和KB2978128，见图四、图五。实践证明，KB4040980（.NET3.5.1补丁）一直没有取代KB2978120。你不打KB2978120，只打KB4040980，Windows Update最后还是会不遗余力地推送KB2978120这个补丁。"

-- 确实，微软提供的这条信息并不准确。实际上，替换更新 KB2978120 和 KB2978128 的补丁是 KB4054998，而这个补丁后来也被取代了。可惜的是，新的补丁没有完全继承 KB4054998。

gwaijyut

KB4054998 包含在 KB4055532 中

gwaijyut

wu733 发表于 2025-12-7 13:04
新增一对取代关系：
KB3172605  2016年09月09日更新汇总       取代了KB3042058  2015年04月19日默认密码 ...

KB3172605 会注入遥测，一般都不会考虑的吧

wu733

gwaijyut 发表于 2025-12-14 01:21
KB3172605 会注入遥测，一般都不会考虑的吧

1、很痛心的说，微软的WU推送取代还是存在错误的，虽然我在Win7 SP1集成补丁过程的取代、衍生和依存关系归纳汇总一贴中举例：“KB2631813、KB3110329均为WU推送列表中的补丁，打了KB3110329后，重新检查WU，KB2631813已经从WU推送列表中消失，即可判断KB3110329取代了KB2631813，这种就是推送取代。”  ---  为了彰显微软WU推送的不可靠，我在贴中故意不移除这句叙述，推翻这个举例的验证在原帖回复贴192楼。见图1


2、KB3172605经我验证，它首先从文件版本上完全取代了KB3042058，其次它推送取代了KB3042058。此分析可见Win7 SP1集成补丁过程的取代、衍生和依存关系归纳汇总一贴回复贴211楼，大家可以自己比较这两个补丁中的组件。
关于KB3172605这个补丁，它的时间戳为2016年9月9日，其实它是属于2016年7月版更新汇总（仅质量更新）的后续修复版，也就是说虽然它是9月份的修复版，但是还是跳不出7月更新汇总的范畴。

关于其中的蓝牙驱动问题，好像是Intel的蓝牙驱动，这个可以通过更换蓝牙驱动版本来解决。而其中加入的遥测，其实不算事儿（KB3125574中也有遥测补丁），可以通过批处理禁用，也可以直接删除遥测相关的文件。

KB3172605和KB3042058如何选择？
如果你对遥测很敏感，那么可以选择KB3042058，不考虑KB3172605。后遗症就是WU会推送KB3172605。
如果你对遥测、蓝牙驱动问题可以自己解决，那么可以选择KB3172605，不考虑KB3042058。此种选择的好处是WU不再推送KB3172605。


刚刚编辑完就发送不了了，然后显示Discuz! Database Error

gwaijyut

wu733 发表于 2025-8-1 23:53
（五）常见无公告取代（既不是官载取代也不是推送取代）或直接被微软废弃的情况
新增无公告取代
KB258146 ...

图内对于 “KB3139398” 的标注是有误的，建议取消 “实际未安装” 的表述。
红框 “实际未安装” 的部分，是面向 Windows Embedded Standard 7 的升级文件，非桌面版 win7

jf200018

感谢楼主统计教学

womwom

感谢分享！学习学习！

wu733

gwaijyut 发表于 2025-12-14 10:04
图内对于 “KB3139398” 的标注是有误的，建议取消 “实际未安装” 的表述。
红框 “实际未安装” 的部 ...

因为我安装的就是桌面版Win7，故实际未安装

wu733

wu733 发表于 2025-12-14 14:02
因为我安装的就是桌面版Win7，故实际未安装

回错....

wu733

gwaijyut 发表于 2025-12-14 10:04
图内对于 “KB3139398” 的标注是有误的，建议取消 “实际未安装” 的表述。
红框 “实际未安装” 的部 ...

希望您能为大家解惑，为啥微软当年会提供Internet Explorer 11 先决条件更新这里面的六个补丁：KB2729094、KB2731771、KB2533623、KB2670838、KB2786081、KB2834140

而匪夷所思的是，其中KB2533623、KB2731771这两个补丁中的组件完全被另外的补丁KB2726535所取代（取代关系分析见199楼至205楼），当年微软为何还要加入这两个补丁？

更奇怪的是，KB2533623中的组件明明已经被KB2731771完全取代，为何还要将KB2533623列入其中？难道是注册表方面的原因吗？

注：
我在199楼至205楼提供的分析，最后得出的结论是：
两条取代路线：KB2533623→KB3063858→KB3185330（2016年10月11日月度汇总及以后的汇总）
                          月度汇总KB3185330将KB2533623中6个组件的版本均更新到了23543版
                      KB2533623→KB2731771→KB2758857→KB2726535→KB5040497（2024年07月09日月度汇总及以后的汇总）
                          月度汇总KB5040497将6个组件均更新到27216版、语言组件及其它组件更新到27212版

以上是我基于组件取代得出的结论，注册表还未具体分析，难道是我自己在本贴中说过的，“光文件取代是不可靠的，还要考虑原补丁对系统的注册表写入、数字签名等” ？
在我的印象中，KB2731771→KB2758857→KB2726535这一环中，好像某个大佬说过KB2758857这个补丁掉了链子

由此，特意附上KB2758857这个补丁的微软官方支持信息页面中  “此安全更新的已知问题”  的一些描述，见中文页面图一和英文页面图二

我希望不光gwaijyut，各位补丁大神们也可以加入这方面的探讨，透过现象看本质，继续深入研究这神奇的取代关系。

bambilu

太复杂了，跟楼主颁发一个研究生奖章

wu733

bambilu 发表于 2025-12-14 16:42
太复杂了，跟楼主颁发一个研究生奖章

生命不息，折腾不止

wu733

gwaijyut 发表于 2025-12-14 10:04
图内对于 “KB3139398” 的标注是有误的，建议取消 “实际未安装” 的表述。
红框 “实际未安装” 的部 ...

我们研究微软的补丁，是为了尽量避免冗余补丁，比如安装了KB3125574后确实可以少打很多补丁。

我们是否过于追求非冗余，从而忽略了某个环节（微软曾经犯下的低级错误）？说实话，只有微软才真正了解自己制作的补丁，我们确实都玩不过微软。

关于KB2533623这个补丁的作用及取代，探索 dotnet core 为何在 Windows7 系统需要补丁的原因一贴被我认为是曾经研究最深入的文章

疑点：KB2758857、KB2726535这两个补丁是不是都需要安装？

gwaijyut

wu733 发表于 2025-12-14 14:40
希望您能为大家解惑，为啥微软当年会提供Internet Explorer 11 先决条件更新这里面的六个补丁：KB2729094 ...

谢邀，不敢当！
其实你在 #226 楼引用的贴文已经为大家解惑了：1、依赖；2、非“唯一”。

        所谓“依赖”，简单点说，就是功能模块之间的依存关系。比如，ITraceRelogger 接口是 IE11 -> F12 工具中的 UI 响应工具，这个接口由 KB2882822 提供。那么，KB2882822 能不能作为 IE11 的安装前置之一呢？答案是“可以”。（它提供了一个旧 IE 版本中没有的“功能”，IE11 “依赖” 这个功能）
        这就引出上述的论点2：“非唯一”。微软知识库中，有很多老旧的文章，他们故意不更新。例如你提到的“Internet Explorer 11 先决条件更新”就是有意保留。在旧知识库中，微软告诉你，KB2729094、KB2731771、KB2533623、KB2670838、KB2786081、KB2834140 是安装 IE11 的必要先决条件。时过境迁，现在可以放心大胆地在“先决条件”的前面加一句：“在当时的历史条件下”。

        对于明确的，已被取代的补丁，把新的替换上去就可以了，功能都是继承的。一般不会出现替代之后，原有功能缺失的情况。当然也不绝对，如果存在缺失的功能，说明页面会有明确告知。

        有兴趣的话，你可以试试这个组合：KB2670838、KB2786081、KB2834140、KB3179573、KB2882822、KB2871997。在数量上，同样是 6 个补丁，这个组合同样可以作为安装 IE11 的前置条件。发现没有，两个组合之间，表面上有 3 个补丁是相同的，这才是真正“必须的”前置。至于其他几个，你如果能找到别的补丁，或许也可以替换掉。为什么这样，再去读一读你引用的那篇博文，相信你能找到答案。

        结合你引用的博文，我多说几句大概率你不爱听的。“一网打尽”的版本替换项目，我觉得差不多就可以了，不要走火入魔了啊哥们。文件(功能)之间，有很强的依赖性，随便某个环节掉链子都会出问题。

gwaijyut

“疑点：KB2758857、KB2726535这两个补丁是不是都需要安装？”

KB2758857 目测不需要，，KB2726535 按需（被 KB3125574 替代）

wu733

gwaijyut 发表于 2025-12-14 22:54
“疑点：KB2758857、KB2726535这两个补丁是不是都需要安装？”

KB2758857 目测不需要，，KB2726535 按需 ...

看来是我过虑了，KB2758857确实是被KB2726535取代了。
你说的是KB3125574，我则喜欢非KB3125574

KB3125574其实就比原版Win7 SP1+散装补丁新增了质量方面的改进（非安全更新），不打KB3125574或者不提取KB3125574中的仅仅被KB3125574更新（未被后续月度汇总更新），重新审视就会发现也就那样。人们往往更注重安全方面的更新。

题外话：
KB3125574补丁方案，必须将月度汇总放在便利汇总之前，否者就应用不了PCIClearStaleCache.exe。这是此方案唯一遗憾的地方。
如果便利汇总KB3125574中的KB2550978（早期的网络问题修补程序）管用的话，那么微软于2018年就没必要发布那么多版本的修补程序（KB4099950旧版.msu 、KB4099950新版.msu、PciClearStaleCache.exe）了

wu733

gwaijyut 发表于 2025-12-14 01:02
KB4054998 包含在 KB4055532 中

是的KB4041083这个.NET汇总被KB4055532官载取代了，而KB4055532中的KB4054998属于.NET3.5.1补丁
多谢告知，我又学到了我所不知道的新知识

jinghuanqd

谢谢分享

a272121742

感谢分享！

wu733

gwaijyut 发表于 2025-12-14 22:37
谢邀，不敢当！
其实你在 #226 楼引用的贴文已经为大家解惑了：1、依赖；2、非“唯一”。

“对于明确的，已被取代的补丁，把新的替换上去就可以了，功能都是继承的。一般不会出现替代之后，原有功能缺失的情况。当然也不绝对，如果存在缺失的功能，说明页面会有明确告知。”
是啊，微软当年那些大神其实也不是神仙，他们在现实生活中也是人，就像你在214楼提出的 “实际上，替换更新 KB2978120 和 KB2978128 的补丁是 KB4054998，而这个补丁后来也被取代了。可惜的是，新的补丁没有完全继承 KB4054998。”。 很明显，后续新的.NET汇总在这方面掉了链子。这方面的例子比比皆是，比如那个KB3185319。

从Windows7于2009年上市，2011年推出SP1补丁包，2016年推出便利汇总KB3125574。换成你是当年开发Windows7的那些大神，你能做到面面俱到吗？Windows7其实已经做的很完美了，从它至今还普遍用于企业或个人电脑上面就能知晓。

最后，由于众所周知的原因，才导致Win7系统慢慢淡出最新的个人电脑。

wu733

gwaijyut 发表于 2025-12-14 22:37
谢邀，不敢当！
其实你在 #226 楼引用的贴文已经为大家解惑了：1、依赖；2、非“唯一”。

“我多说几句大概率你不爱听的。“一网打尽”的版本替换项目，我觉得差不多就可以了，不要走火入魔了啊哥们。”

非常感谢，接受你的建议！
其实我是一个非常聪明的人，KB3125574中相比原版Win7 SP1及散装补丁进行更新的组件或文件，其实只需要部分用用即可。比如，CMD.exe、Robocopy.exe，记事本程序，字体更新，Windows照片查看器更新等。

wu733

补充：

KB3172605  2016年7月更新汇总  取代了KB3042058  2015年04月19日默认密码套件顺序更新

如果你采用KB3172605，剔除KB3042058。既然KB3042058的前置是KB3020369或KB4490628，那么KB3172605也继承了KB3042058这个特征。也就是说KB3172605的前置也是KB3020369或KB4490628。

gwaijyut

wu733 发表于 2025-12-15 21:59
补充：

KB3172605  2016年7月更新汇总  取代了KB3042058  2015年04月19日默认密码套件顺序更新

哈哈，又绕到 KB4490628 身上了。
KB3020369、KB4490628
把 KB3172605 的前置换成 KB5071810 也是可以的。KB3020369 这个 SSU 早就不需要了，比较特殊的是 KB4490628。随着 ESU 接近尾声，KB4490628 的承启作用也随之落幕，如果仅从补丁的安装或集成的角度来说，已不再需要 KB4490628 。可以用目前最新的 KB5071810 取而代之。SSU 没有 ESU 限制，无需有其他顾虑。
（遇到过 KB4534310 重复推送的情况，很讶异。重复测试的时候又正常了）

wu733

gwaijyut 发表于 2025-12-15 23:44
哈哈，又绕到 KB4490628 身上了。
KB3020369、KB4490628
把 KB3172605 的前置换成 KB5071810 也是可以 ...

ESU方案我后面没有过多的去研究了，照你这么肯定的语气，KB4490628被后面的服务堆栈更新取代也不是不可能

gwaijyut

wu733 发表于 2025-12-15 23:49
ESU方案我后面没有过多的去研究了，照你这么肯定的语气，KB4490628被后面的服务堆栈更新取代也不是不可能

从适用范围来说，KB4490628 仅面向常规更新，对 ESU 力有不逮，这大概是很多人觉得应该保留的原因。尽管微软极力推荐安装每一个 SSU，实在讲，太多了！两三个月就出一个新的，频繁的时候每个月都有，每一个都装，那得疯掉。关键这货没法正常卸载，一旦安装就自动固化，能少一个是一个。。。
付费扩展支持服务，对服务堆栈的升级没有限制

wu733

gwaijyut 发表于 2025-12-16 00:10
从适用范围来说，KB4490628 仅面向常规更新，对 ESU 力有不逮，这大概是很多人觉得应该保留的原因。尽管 ...

“关键这货没法正常卸载，一旦安装就自动固化，能少一个是一个”
这时就要采用邪修的办法了，比如KB4490628
1、换到PE下，先用Everything搜 “KB4490628” ，找.mum文件，有好几个

2、用记事本编辑所有搜索到的.mum，并在.mum文件中继续搜permanence="permanent"，删除这段即可，然后正常进入系统，这个堆栈补丁就会从已固化变为已安装，然后就可以正常卸载了

SeaYang

感谢分享了。