《Win11 24H2风波：AppLocker漏洞引爆安全危机，性能投诉骤增致数据丢失风险攀升》

Win11 24H2灾难升级：AppLocker漏洞引发信任危机，性能问题失控致数据安全亮红灯

　　 5月6日消息，微软上周正式推出Windows 11 24H2的广泛版本，但不少用户反映在升级过程中遇到了多个严重Bug，导致系统运行变得不稳定，甚至存在数据丢失的风险。从目前的反馈来看，这次更新似乎并未达到预期效果，反而给用户的使用体验带来了诸多困扰。尤其是在性能下降的问题上，许多用户表示升级后设备运行速度明显变慢，这无疑让人感到失望。希望微软能够尽快针对这些问题发布修复补丁，以保障用户的正常使用和数据安全。毕竟，作为一款被广泛使用的操作系统，稳定性和可靠性始终是最基本的要求。

　　 近日有消息称，微软计划对符合条件的用户进行一次重要更新推送。此次更新主要面向运行Windows 10 23H2、22H2以及21H2版本的家庭版与专业版设备，并将自动为其升级至24H2版本。 在我看来，这一举措体现了微软在软件服务方面的持续优化能力。通过自动推送的方式，用户可以更便捷地享受到新系统的功能改进与安全增强，这不仅提升了用户体验，也进一步巩固了Windows生态系统的稳定性。不过，值得注意的是，在享受便利的同时，用户也应关注可能存在的兼容性问题，确保个人数据的安全备份，以避免因系统升级带来的潜在风险。总之，这次更新无疑是一次技术进步的表现，值得期待其实际效果。

　　 然而，用户在更新过程中的反馈显示，出现了不少问题，例如升级时的重大漏洞、大量关于性能下降的投诉，以及可能存在的数据丢失风险。

　　 其中最值得关注的是，AppLocker WDAC 脚本执行策略存在漏洞。AppLocker 是企业用来管理用户可运行应用程序和文件的控制策略，涵盖 EXE 文件、脚本、Windows Installer 文件等。

　　 微软在2023年曾致力于简化AppLocker的部署流程，这一举措原本是为了让企业用户更方便地管理应用程序的运行环境。然而，在随后的2024至2025年的实际测试中，该功能暴露出了一些不足之处。StackExchange论坛上的用户CFou率先指出了问题所在，他发现ConstrainedLanguage模式在某些情况下无法按预期工作，导致PowerShell会话默认仍然采用FullLanguage模式。这种现象无疑对依赖严格权限控制的企业环境造成了困扰。 在我看来，微软作为一家技术巨头，其产品更新的初衷无疑是好的，但任何新技术或新功能在初期都可能面临一些挑战。从这次事件来看，微软需要更加重视用户的反馈，并尽快修复这些问题。毕竟，对于依赖这些工具的企业来说，哪怕是一点点小故障也可能带来巨大的安全风险或工作效率下降。希望微软能够迅速响应，优化相关功能，确保未来版本更加稳定可靠，从而更好地服务于广大用户。同时，这也提醒我们，企业在引入新技术时应保持谨慎态度，充分评估其适用性和潜在隐患。

　　 随后，Reddit用户hornetfig以及sysadmin子论坛的多位用户在Windows 11 24H2版本中发现了相同的漏洞。这一漏洞可能让恶意脚本得以不受限制地执行，带来严重的安全隐患。在我看来，这样的漏洞不仅影响了用户的正常使用体验，更对整个系统的安全性构成了巨大挑战。操作系统作为数字世界的基础架构，其安全性至关重要。一旦被恶意利用，不仅个人用户的数据可能遭到窃取，企业级的信息资产也可能面临巨大风险。因此，软件开发商应当尽快发布修复补丁，并提醒用户及时更新系统，以避免潜在的安全威胁进一步扩大。同时，这也提醒我们，在依赖技术的同时，也需要持续关注和评估其安全性，确保科技发展不会成为隐患的温床。

　　 微软技术专家Roody Ooms经过详细分析后指出，PowerShell 7.3版本中引入的WldpCanExecuteFile API存在一定的不稳定性，相比之下，此前版本所采用的WldpGetLockdownPolicy API表现更加可靠。这一发现引发了对新版功能设计合理性的广泛讨论。 从目前的情况来看，此次问题的曝光提醒我们，在软件开发过程中，尤其是在涉及核心功能更新时，平衡创新与稳定性至关重要。虽然新技术的应用能够带来更高效或更便捷的操作体验，但若未能充分测试和完善，就可能给用户带来不必要的困扰。因此，未来在推出类似的重大改动前，是否可以考虑增加更多的预览环节，以便开发者和用户共同参与评估潜在风险？ 此外，这也反映了开源社区对于产品质量的高度关注。作为一款深受开发者喜爱的工具，PowerShell理应以更高的标准要求自身。希望微软能够在后续更新中及时修复漏洞，并通过更完善的文档和支持体系，帮助用户更好地适应新变化。毕竟，只有当软件既具备前瞻性又足够安全可靠时，才能真正赢得用户的信赖和支持。

　　 微软方面已经注意到该问题，并在PowerShell 7.6-preview.4版本中实施了修复方案，对“回退至AppLocker”功能的引擎进行了优化。

　　 用户 IridiumIO（同时也是 CompactGUI 开发者）指出，Windows Defender 的实时保护（Realtime Protection）严重拖慢速度，关闭后解压速度可提升 35%。

　　 相比之下，文件资源管理器虽然引入了对RAR和7Z格式的支持，但其解压速度仍然远不及7Zip或PowerShell的Expand-Archive命令。不少用户对此表示不满，认为微软只是简单地将新功能添加到旧有的系统架构中，缺乏深度优化，导致其实用性大打折扣。这种“缝缝补补”的做法显然无法满足用户的实际需求。在我看来，微软作为行业巨头，本应在文件管理和压缩解压领域提供更高效、更流畅的体验。然而，目前的表现更像是在应付差事，未能真正解决用户的痛点。希望未来版本能够针对这些问题进行彻底改进，而不是仅仅停留在表面的更新。

　　 IridiumIO最近注意到一个有趣的细节：当用户在“Downloads”文件夹中解压文件时，速度比在C盘根目录下慢了大约10%。他分析认为，这可能与文件资源管理器在解压过程中逐层验证文件路径有关，而如果文件的嵌套层级更深，这种速度差异可能会更加明显。 这一发现引发了我对系统操作逻辑的一些思考。从技术角度来看，文件路径的复杂性确实会对解压效率产生影响。尤其是在现代文件管理系统中，为了确保数据安全性和兼容性，资源管理器需要额外处理路径检查等步骤，这无疑会增加解压过程中的负担。然而，这也提醒我们，日常使用的文件夹位置选择其实也会影响实际操作体验。例如，将常用文件存放在层级较浅的位置，或许能带来更高效的使用效果。 此外，这种现象也反映了软件设计中权衡效率与安全性的挑战。对于开发者而言，在追求性能优化的同时，还需要兼顾系统的稳定性与安全性。或许在未来版本中，微软可以针对这类场景进行针对性优化，以减少不必要的路径检查时间，从而提升用户体验。 总体而言，IridiumIO的观察不仅揭示了一个有趣的细节，也为用户提供了实用的建议——合理规划文件存储路径，或许能让我们的工作和生活变得更加高效。

　　 此前报道，微软近日移除了BYPASSNRO脚本，同时对账户设置了强制性要求，这或许与Windows 11最新功能更新中BitLocker加密默认设置的调整有关。此次更新后，用户的BitLocker恢复密钥会被自动备份到账户中。不过，BitLocker加密功能也引发了数据丢失风险的担忧。

　　 Reddit用户TechSecure提出观点，认为BitLocker在默认开启后，一旦用户丢失对账户的访问权限，其数据可能无法恢复。这一情况让不少普通用户措手不及，微软的“默认安全”策略因此受到质疑，被指未能充分考虑用户的实际使用需求。