Windows 10 更新为何问题频发?

Windows 10 的系统更新仿佛就像是微软的 “熊孩子”,几乎每次月度累积更新和功能更新都会出现这样或者那样的问题,导致部分用户无法正常使用。那么为何微软总是管理不好这些更新呢?外媒 Windows Latest 近日撰文详细介绍了背后的原因。

频发的更新 BUG

Windows Update 的更新始于 Windows 10 October 2018 更新,该更新在上线之后误删了使用者的文档、图片和其他文件信息。因此在短短上线 4 天之后就被下架。

在经历了 October 2018 的重大尴尬之后,微软在 May 2019(Version 1903)功能更新上采取了更谨慎的态度,以避免重复灾难性的部署。虽然 2019 年 5 月的更新本身并不算一团糟,但 Microsoft 发行了累积更新以修复一些长期存在的小错误,但每月更新引入了一个新错误,导致 CPU 使用率高。

随后在发布修复 Cortana 的累积更新中,导致 “开始” 菜单和 “任务栏” 无法正常使用。而且还导致部分设备无法进行网络连接,而且还导致了音频问题。这些问题直到去年年底,才被微软妥善解决。

正是因为诸多问题,导致去年下半年的功能更新 November 2019(Version 1909)直接变成了超大号的累积更新,没有引入新的功能,而是重点修复各种 BUG。不过该功能更新依然导致文件管理器崩溃。

那么为什么 Windows 10 的更新一团糟呢?

去年 9 月,曾为微软效力长达十五年的杰瑞•伯格发布视频,评论详细解释微软操作系统团队以前构建版本时的测试流程。

据前员工称,微软已经改变了其 Windows Update 测试程序,这可能是造成混乱的原因之一。正如前 Microsoft 高级软件工程师所说,Microsoft 曾拥有一支整个团队,致力于在测试 Windows 更新。不同于驱动和接口部门,该团队成员每天的工作就是讨论各种故障。

杰瑞伯格还提到了原来的微软测试团队还专门为诸如英特尔、AMD、英伟达等成立专门的实验室测试 CPU/GPU。这些专门的实验室用来测试新的构建版本或者功能模块与重要硬件例如处理器和显卡是否存在兼容或者性能问题。

负责这些实验室的测试团队也会与制造商进行对接,所以测试团队若发现什么问题可以很快确定并制定解决方案。待开发团队修复问题后会再交给测试团队进行测试,测试团队通过测试后则修复方案的代码会被合并到主线程中。

微软工程师团队使用自动化测试和真实设备上来测试 Windows 更新,而不是通过虚拟机方式。在 2014 年的时候,微软解雇了 Windows 测试团队,该公司大部分时间都停止了对实际配置的测试更新。

除了虚拟机之外,Microsoft 现在还依赖 Windows Insiders,这是一组由发烧友和粉丝组成的测试人员。许多用户已经注册了 Insider 程序以测试新功能,尽管 Insider 成员报告了一些问题,但由于反馈数量太大很多问题都被忽略了。

在视频评论中杰瑞伯格还对 Windows 10 的测试项目进行讨论,简单来说测试项目并不能帮助微软解决太多问题。主要原因是多数测试版用户遇到问题不会主动向微软反馈,当然即便向微软反馈最终的结果可能也是没有人搭理。

出现这种情况的主要原因在于转储日志,系统运行时会不断地记录各种情况并生成极其庞大的转储日志以供分析。然而实际情况是只有当系统崩溃时转储日志才会将其细节记录,其他方面的 “小问题” 系统并不会记录转储日志。

完整的转储日志体积相当大 ,  可能在几十 GB、几百 GB 也可能在 TB 级别 , 显然多数用户也没有这么大的空间存储。也就是即便用户主动向微软反馈并提供转储日志,实际提供的也只是部分片段而不是整个操作系统完整运行日志。

原创文章,转载需获得本站授权。欢迎加入软餐读者群:软餐食堂   软餐食堂

发表评论

电子邮件地址不会被公开。 必填项已用*标注