本帖最后由 gwaijyut 于 2025-7-18 01:15 编辑 找到我们看法的差异了。同名文件的"同源"或"异源"。你关注一下。 不同KBs之间(异源),各自包含的程序集的文件名,会有交集。名称的交集与取代无关。各司其职。 |
gwaijyut 发表于 2025-7-18 00:18 不是很好描述,感觉很费劲。 简单的说就是,先在虚拟机系统(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 00:38 编辑 wu733 发表于 2025-7-6 00:07 "经验证,6.1.7600和6.1.7601版的增量可以全部使用6.1.7601版的最新稳定版进行替换,因为我发现非KB3125574系统中微软官方就是这么干的" 你说的没错,这是特例。在“源”一致的情况下,可以这么干,微软是会这么干。 那么现在问题来了,如何判断“源”一致?在系统文件夹(例如 Windows)内,存在多个版本的 Test.dll 文件,如何区别他们?有没有一种可能,它们在各自的文件夹(路径)下,扮演不同的角色,分担不同的任务。虽然同名,却功能相异。 遇到这种情况,分类讨论是不是更接近替代的本质:同源是取代或半取代;异源则毫无关系。 |
gwaijyut 发表于 2025-7-17 23:20 我改一下,表达的意思不是很准确 |
wu733 发表于 2025-7-17 23:09 此话怎讲?66 个官载至今也没剩几个了,你这里说的 3 个未包含,有没有包含在 KB574 的初版之中? |
本帖最后由 wu733 于 2025-7-17 23:58 编辑 KB3125574官载取代以外的补丁已经更新到30个,其中有3个已被KB4534310月度汇总全部文件更新 |
wu733 发表于 2025-7-17 21:26 承前没问题,不使用 ESU 的时候,它必须有 |
gwaijyut 发表于 2025-7-17 21:08 先避开KB2533552不说,关于这个KB4490628,很多大佬早有定论,认为其并不完全包含于后续的SSU(有交集,但不是包含关系),属于承前启后的存在。 |
KB4490628是升级到RDP8.1的前置组件之一,拿掉它,你看看能不能升级rdp8.1,,假如不能,这个组件就是必须的 |
wu733 发表于 2025-7-17 17:30 关于 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 目录中的程序集,但是,有可能会修改、替换该目录之外的同源文件。 这里说的有可能,呃,是因为我还没检测。。。。。 忙着去喝大酒,回头找时间再看看 |
gwaijyut 发表于 2025-7-17 16:25 关于后续补丁对这个KB2533552服务堆栈补丁的文件更新,我想没有这么简单(固化)。至于KB2533552是不是冗余(abbodi1406认为是),以及KB4490628是不是冗余,其实只要大胆去实验我相信肯定会得到答案的。 |
本帖最后由 gwaijyut 于 2025-7-17 17:23 编辑 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 于 2025-7-17 14:12 编辑 新增KB3125574官载取代以外的补丁,这个视情况和时间进行后续更新 |
什么时候能出个WIN7成版 |
本帖最后由 wu733 于 2025-7-17 14:53 编辑 gwaijyut 发表于 2025-7-17 10:00 "也就是在使用 WU 完成所有非冗余的推送补丁的安装后,继续安装 KB3125574 ,整个系统的文件升级将更加完整。" 确实如此,KB3125574对系统的部分文件更新(23403)其实就是对程序质量或程序参数的改进(非安全性更新)。但是KB3125574并不仅仅只是对官载取代的这66个补丁进行了完全的文件更新,还对其它的补丁或多或少进行了部分的文件更新。比如,KB958830(域控管理RSAT工具)、KB2533552(2011年05月09日服务堆栈更新)。 其中,KB958830是WU不推送的,而KB2533552这个服务堆栈补丁经我研究发现:KB3125574、后续服务堆栈更新以及月度汇总对其的文件更新是非常混乱的(主要体现在系统当前正在使用的文件版本往往并不是最新的(23403或24545),而且文件版本也不统一,System32下是16385版,SysWOW64下却是17514,对此我感到非常疑惑) |
重复发帖修正 |
本帖最后由 gwaijyut 于 2025-7-17 10:07 编辑 更正:这里为#112楼的不严谨言论致歉。 KB3125574 对系统有新增程序集,目前检索到的有:kbdinen.dll 。暂未找到与之相关的补丁/更新(574除外)。根据找到的资料判断,这个文件与 “英语(印度)键盘布局” 有关。对中文用户而言,该文件基本上可有可无。 楼主根据官载的66个被替换补丁,提取出“仅被 KB3125574 更新”的文件,system32文件夹(不含子文件夹)内,共计89个。 而如果抛开官载的“66个”被替换补丁这个前提,实际的“仅被 KB3125574 更新”的文件,仅system32文件夹(不含子文件夹)内,就有 376 个之多,详情如下:
早些年 KB3125574 之所以被诟病,大多与硬件的兼容性/驱动有关,这部份电脑以组装机为主,至今还在使用的占比并不是很多。 |
q7551453 发表于 2025-7-13 14:02 叹为观止! 虽说你我目前同为上等兵,阁下升到少校指日可待啊!我这抓破脑袋刷点分,不如先生吟诵一番来得快,请受在下一拜! |
本帖最后由 gwaijyut 于 2025-7-13 00:46 编辑 wu733 发表于 2025-7-12 16:18 "2、使用它+月度汇总。缺点是:多了很多冗余。比如IE11的先决补丁(KB2533623、KB2670838、KB2729094、KB2731771、KB2786081、KB2834140),多打了KB2533623、KB2731771。" 呃。。。不能这么理解。 不要执着于补丁编号,一个代号而已。这个编号包含的程序集是重点。 本质上,补丁文件(无论是否包含安全更新)只有两种。最常见的,是升/降原有程序集;罕见的,是新增程序集(比如里程碑版本(SP1),又比如 KB4012212 ---- 有新增程序集:对原始系统添加新的、原本没有的文件)。 KB3125574 被微软定义为便捷包,意味着它只是一堆补丁的集合,不是里程碑版本,也不包含新增程序集。换一种说法:安装 KB3125574,不会新增原始系统(RTM + SP1)中不存在的文件,只会针对原有文件做升/降级。 你说的 KB3125574 “多打了KB2533623、KB2731771”,不存在的。它可能升级了 KB2533623、KB2731771 两个补丁包含的程序集,也仅此而已,与KB编号无关。总不能因为它升级了 KB2533623、KB2731771 的程序集,就认定它多打了 KB2533623、KB2731771 这两个补丁吧,这种情况,用"替代"似乎更为贴切。 所有被 KB3125574 升级的文件(程序集),后期被月度汇总或其他补丁继续升级的,不在少数。这种情况,用你定义的"不完全取代",也能很好地对号入座。 对于 KB3125574 ,忘了它所包含的补丁编号吧,更为有用的,是它的程序集清单:htt-p:/-/download.microsoft.com-/download/e/b/0/eb084e02-4173-444e-9438-53972ae2f9e0/3125574.csv PS:目前我在这边级别不够,无法使用常规方式使用超链接。 |
本帖最后由 wu733 于 2025-7-12 18:30 编辑 gwaijyut 发表于 2025-7-12 11:11 使不使用KB3125574最关键的区别就是: 1、从文件层面来看,KB3125574方案比非KB3125574方案多了部分文件版本更新(23403),但是一叶蔽目不见泰山; 2、从宏观层面来看,KB3125574方案比非KB3125574方案仅仅只是多了非安全性更新,这是不容置疑的,因为安全性更新方面均由月度汇总更新到最新,所以也有部分人不使用月度汇总而只使用仅安全性更新。 总结:使用KB3125574方案或非KB3125574方案各有各的优点,对于普通个人来说,非KB3125574方案明显要优于KB3125574方案;对于政府企业来说,KB3125574方案则更加全面。但是,由于安全性更新方面才是重点,故政府企业亦可使用非KB3125574方案,从而舍弃KB3125574中的非安全性更新部分(包括冗余部分)。 |
gwaijyut 发表于 2025-7-12 11:11 多谢指点,KB3125574这个便捷包确实很诡异: 1、不使用它,只用月度汇总。缺点是:部分文件版本(低于23403)未被月度汇总更新。优点是:少了KB3125574里面的冗余; 2、使用它+月度汇总。缺点是:多了很多冗余。比如IE11的先决补丁(KB2533623、KB2670838、KB2729094、KB2731771、KB2786081、KB2834140),多打了KB2533623、KB2731771。最大的优点是:省时省力。 |
gwaijyut 发表于 2025-7-12 09:08 网页链接可以使用工具“添加链接”的方式: https://www.123865.com/s/JiVbVv-ComW3? https://www.123865.com/s/JiVbVv-0omW3? |
Powered by Discuz! X3.3
© 2001-2017 Comsenz Inc.