孤本网
/ 0 阅读
0
0

微软工程师公开技术细节:Windows 11 双杀软互锁致程序卡死,企业需严格部署策略

一句话结论

Windows 11 下共存两款杀软会因系统函数拦截机制互锁导致程序卡死,企业须禁用多装杀软。

关键要点

  • 微软资深工程师雷蒙德·陈(Raymond Chen)于 10 月 8 日在微软开发者博客披露一起 Windows 11 双杀软冲突企业支持案例。
  • 以代称 Fabrikam 和 Contoso 演示:Fabrikam 调用被 Contoso 拦截的函数,Contoso 判定为可疑活动并尝试隔离 Fabrikam。
  • 互锁过程中 Fabrikam 同时拦截 Contoso 正在使用的函数,致使 Contoso 反过来调用自身试图隔离的进程,形成死锁。
  • 反恶意软件通常采用非官方支持的操作,例如挂钩或拦截系统函数,使得原始系统调用先转入安全软件再决定后续动作。
  • 此类冲突最终会导致应用程序卡死,且除对已故障系统做底层调试外,缺乏简便方法确认冲突是否源于杀软间互相干扰。

背景与事实

微软资深工程师雷蒙德·陈(Raymond Chen)在 10 月 8 日发布的微软开发者博客中,系统梳理了他在企业支持工作中遇到的一起典型事故。该案例涉及运行 Windows 11 的设备上同时部署了两款反恶意软件。为避免泄露客户隐私,博文使用 Contoso 与 Fabrikam 作为两款软件的代称,但核心逻辑完全对应实际部署环境。

在底层执行层面,Fabrikam 调用了一个已被 Contoso 挂钩或拦截的函数。由于 Contoso 将该行为解读为可疑活动,它随即启动隔离流程,试图将 Fabrikam 进程从系统中移除或限制其行为。然而,这一动作立即触发了 Fabrikam 的防御机制。Fabrikam 也拦截了 Contoso 正在使用的函数,导致 Contoso 被迫调用了自己试图隔离的目标进程。这种双向拦截形成了一个逻辑上的互锁状态。

雷蒙德·陈(Raymond Chen)将这种技术现象比喻为两家互不知情的安保公司同时在一栋大楼内巡逻。如果双方都具备强制措施权限且彼此不对话,安保人员很可能会将对方识别为入侵者并强行控制。在软件层面,反恶意软件通常依赖于非官方支持的操作,例如拦截系统函数。当程序调用原本的系统函数时,控制权先转移至安全软件,由其决定放行、阻断或隔离。一旦两个安全软件对同一类函数都实施拦截且策略互相矛盾,正常的调用链便会产生偏差。

文章进一步指出,这种偏差的直接后果是应用程序卡死。对于 IT 维护人员而言,这类故障具有极高的排查难度。除了对已经发生故障的系统进行底层调试外,通常没有简便的方式来确认冲突是否确实源于反恶意软件之间的干扰。即便最终定位了冲突源头,也往往无法要求各软件限定各自的处理范围,因为修改拦截策略可能引发新的兼容性风险。

影响分析

对于中文开发者与企业 IT 管理者而言,这是一条必须纳入部署规范的硬性红线。在企业环境中,财务、研发或运维部门若违规在同一 Windows 11 终端上叠加安装两款不同厂商的杀毒软件,极易引发上述互锁。这不仅是软件冲突,更会导致业务系统整体停滞。

对于独立开发者而言,若你的软件涉及系统底层调用或尝试注册全局钩子,需特别注意在 Windows 11 多杀软环境下的兼容性测试。虽然开发者无法控制用户是否安装多款杀软,但应明确记录软件在存在第三方拦截器时的行为边界。企业用户应强制推行“一机一杀软”原则,并在部署前通过 Group Policy 或 MDM 工具禁用多余的反恶意软件服务,从源头切断互锁可能。

适用边界

该结论主要针对同时活跃运行且具备系统级拦截能力的两款反恶意软件。若其中一款软件仅运行在受控沙箱中、或用户已手动关闭其实时监控功能、或使用的是被动型签名扫描工具(非实时拦截型),则互锁风险显著降低。此外,该技术分析基于雷蒙德·陈(Raymond Chen)在 10 月 8 日发布的博文内容,仅反映当前 Windows 11 环境下已知的一类特定冲突模式,不适用于其他 Windows 版本或不同架构下的安全软件交互场景。

孤本观察

作为编辑判断,该案例将“企业部署管理漏洞”具象化为底层代码互锁,警示 IT 运维人员:在多杀软共存的灰色地带,任何试图靠“共存测试”来规避风险的策略都因缺乏底层调试手段而不可控,唯一可靠的防线是部署前的策略强制隔离。

常见问题

微软工程师雷蒙德·陈是在哪一天发布关于Windows 11双杀软互锁问题的技术博客的?

2024年10月8日

Windows 11下两款杀软互锁导致程序卡死的底层机制是什么?

Fabrikam调用被Contoso拦截的函数,Contoso试图隔离Fabrikam,Fabrikam又拦截Contoso使用的函数,导致Contoso调用自身试图隔离的进程,形成死锁

企业应在部署阶段采取什么策略来避免Windows 11双杀软互锁?

强制推行“一机一杀软”原则,并通过Group Policy或MDM工具在部署前禁用多余的反恶意软件服务

除了对已故障系统做底层调试,还有什么简便方法能确认冲突源于杀软互锁?

没有简便方法

哪些特定场景下Windows 11双杀软互锁的风险会显著降低?

一款软件仅运行在受控沙箱中、用户手动关闭其实时监控功能,或使用的是非实时拦截型的被动签名扫描工具

来源:IT之家


评论