科技媒体 BornCity 昨日（12 月 15 日）发布博文，报道称微软于 2025 年 12 月 9 日发布的累积更新 KB5072033 被曝存在 BUG，导致 Windows 11（24H2/25H2）及 Windows Server 2025 系统 Defender 状态查询失效。

麻烦来了。不少系统管理员发现，在给设备打上这个补丁后，用来检查杀毒软件状态的核心指令 Get-MpComputerStatus 彻底“哑火”。这故障有点特别，它不是那种会报个错代码的常规问题，而是玩起了“静默失踪”——命令执行后既不报错，也不返回任何结果，直接导致自动化脚本抓取不到 Windows Defender 的实时运行数据。

可别小看这个命令失效，它在企业网络里引发的可是实实在在的连锁反应。

根据该博客的读者 Othmar G. 反馈，他所在公司的 IT 部门就在 12 月 15 日撞上了这个坑。

他们公司采用 Forti EMS 客户端配合零信任网络访问（ZTNA）标签来管理设备入网权限。流程原本很清晰：系统自动调用 PowerShell 脚本，检查每台电脑的 Defender 是否在岗。然而，更新之后，这个检查命令返回一片空白。

结果可想而知：安全系统误以为这些设备“裸奔”运行，没有防护，随即触发风控规则，把大量本来正常工作的办公电脑给强制隔离了，直接断网。这下，办公可就不只是“卡顿”那么简单了。

这里需要划个重点：问题并非出在 Windows Defender 服务本身。如果你打开系统自带的图形化安全中心界面，所有状态都会显示为清晰的“正常（OK）”。服务其实在后台跑得好好的。

那么，根子究竟在哪？技术分析指向了更深层的原因：很可能是这次更新，把负责向 PowerShell 提供数据的底层“提供程序（Provider）”给弄丢了或者注册失效了。这就好比家里的电表本身运转正常，但连接电表和外部读数器的线路被掐断了，导致供电公司无法获知你的用电情况，形成了一种管理层面的“信息黑洞”。

针对此问题，社区已挖掘出有效的临时解决方案。

如果你或你管理的设备不幸中招，解决办法倒不复杂。只需以管理员身份打开命令提示符（CMD），然后输入并执行下面这行命令：

"%programfiles%\Windows Defender\MpCmdRun.exe" -ResetPlatform

这条指令的作用是强制重置 Windows Defender 的平台配置，顺便把丢失的那个关键数据接口重新注册回来。

根据实际测试，执行重置操作后，通常只需要等待几秒钟，PowerShell 的状态查询功能就能恢复正常。那些被误隔离的设备，也能重新通过 ZTNA 的安全验证，恢复网络访问。话说回来，在微软发布官方修复补丁之前，这恐怕是最直接有效的应对之策了。

推荐阅读：Win11部分用户反馈安装12月累积更新KB5072033报错0x800f0991