smb direct 签名使用SHA256或者CMAC会出现蓝屏

stone pl 0 信誉分
2026-09-28T06:32:36.99+00:00

我使用windows server 2025版本作为smb client,更新到KB5129235,配置RDMA网络,在挂载smb共享时,smb server返回311版本,签名算法若返回SHA256或者CMAC之后,在拷贝文件时发生蓝屏,而签名算法若返回GMAC则不会发生蓝屏。

我使用winDbg初步分析了一下,报告以下堆栈,请问这是windows内核在smb direct场景下对SHA256和CMAC签名算法不支持导致的蓝屏吗?

Snipaste_2026-09-28_14-21-08

环境信息

  • OS: Windows Server 2025 Standard/Datacenter
  • Build: 26100.33451 (Latest CU KB5129235 applied)
Windows 商业版 | Windows Server | 存储高可用性 | 群集和高可用性
0 个注释 无注释

1 个答案

排序依据: 非常有帮助
  1. Daphne Huynh (WICLOUD CORPORATION) 1,575 信誉分 Microsoft 外部员工 审查方
    2026-09-28T07:57:24.3766667+00:00

    欢迎来到 Microsoft Q&A!

    感谢您提供如此详细的复现条件和 WinDbg 堆栈信息。SHA-256、AES-CMAC 和 AES-GMAC 之间的对比尤其有价值。

    根据您提供的信息,此行为不应被解读为 Windows Server 2025 缺少对 SHA-256 或 AES-CMAC SMB 签名算法的支持。

    以下是 SMB 签名算法:

    • SMB 2.x 使用 HMAC-SHA-256。
    • SMB 3.0 和 SMB 3.0.2 使用 AES-128-CMAC。
    • SMB 3.1.1 支持 AES-128-CMAC,并引入 AES-128-GMAC 作为性能更高的签名算法。

    由于这些都是受支持的算法,因此在协商 SHA-256 或 CMAC 时出现蓝屏不属于预期行为。

    从您分享的转储来看,最值得关注的现象是故障发生在:

    mrxsmb!SmbCryptoCalculateAndSetIVForRdmaBuffer

    堆栈还显示,在崩溃发生前存在 SMB Direct(RDMA)相关活动,这表明问题可能与 SMB Direct 的加密路径有关,而不是签名算法本身。

    同时,转储显示:

    • EXCEPTION_CODE: c0000420
    • EXCEPTION_STR: WRONG_SYMBOLS
    • IMAGE_NAME: ntoskrnl.wrong.symbols.exe
    • FAILURE_BUCKET_ID: WRONG_SYMBOLS

    由于该转储是在符号不匹配的情况下进行分析的,因此这些堆栈信息应被视为方向性证据,而不是最终的根因分析结果。虽然它有助于确定受影响的组件范围,但尚不足以明确判断故障源自 Windows SMB 客户端、RDMA 堆栈、第三方 SMB 实现、网卡驱动程序,还是兼容性问题。

    另一个值得验证的重点是 SMB 协商过程本身。如果协商的是 SMB 3.1.1,那么 HMAC-SHA-256 通常不会是该协议版本的首选签名算法。如果 SMB 服务器是 NAS 设备、Samba 实现、存储平台或其他非 Windows SMB 服务器,则需要确认协商过程和签名能力交换是否完全符合 SMB 3.1.1 规范。

    为了继续排查,我建议:

    1. 使用正确的 Microsoft 符号重新分析完整内存转储。
    2. 抓取覆盖 SMB 协商到问题复现全过程的网络跟踪。
    3. 临时禁用 RDMA 进行测试,以确认问题是否仅与 SMB Direct 相关。
    4. 验证客户端和服务器上的网卡驱动程序及固件版本。
    5. 如果当前服务器是第三方实现,尝试在完全更新的 Windows SMB 服务器上复现相同场景。

    根据目前掌握的信息,现有证据更倾向于表明这是 SMB Direct/RDMA 相关缺陷或兼容性问题,而不是 Windows 不支持 SHA-256 或 AES-CMAC。

    由于这是一个发生在已完全更新的 Windows Server 2025 系统上的可重复内核崩溃问题,后续调查很可能需要超出公开论坛支持范围的更深入分析能力。尤其是,要确认根本原因,可能需要详细的转储分析、符号验证、SMB 协商跟踪审查,以及通过 Microsoft Support 获得的内部调试资源。

    因此,我强烈建议您提交 Microsoft Support 支持案例。这样支持团队便能够开展更全面的调查,并在必要时联系相应的产品工程团队参与分析。

    在提交支持案例时,请提供以下信息:

    • 完整的内存转储或内核转储
    • 使用正确符号重新分析后的 WinDbg 结果
    • SMB 协商及问题复现过程的网络跟踪
    • 客户端和服务器的 SMB 配置详细信息
    • RDMA 网卡型号、驱动程序版本和固件版本
    • 启用和禁用 RDMA 时的测试结果
    • 使用 SHA-256、AES-CMAC 和 AES-GMAC 时的测试结果
    • SMB 服务器的准确产品名称和版本信息

    感谢您在隔离此问题过程中投入的大量时间和精力。您目前收集到的数据非常有帮助。考虑到此次崩溃的性质,通过正式的支持渠道开展进一步调查,将是确定底层根本原因最有效的途径。

    参考资料:

    SMB 安全性增强功能 | Microsoft Learn

    服务器消息块签名概述 - Windows Server | Microsoft Learn

    Windows 和 Windows Server 中的 SMB 功能 | Microsoft Learn

    通过 SMB 直通优化文件服务器的性能 | Microsoft Learn

    2026 年 9 月 14 日 - KB5129235 (OS 内部版本 26100.33451) 带外 | Microsoft Support

    Windows Server 2025 中已解决的问题 | Microsoft Learn

    如果您认为以上信息对您有所帮助,请点击 Accept Answer。

    感谢您使用 Microsoft Q&A。

    注意:此回复已通过翻译工具翻译。由于自动翻译的限制,内容中可能存在语法或语义上的偏差,敬请谅解。感谢您的理解与支持。

    此答案是否有帮助?

    0 个注释 无注释

你的答案

提问者可以将答案标记为“已接受”,审查方可以将答案标记为“已推荐”,这有助于用户了解答案是否解决了提问者的问题。