必须交叉验证tpm.msc（规范版本明确为2.0且状态“已准备就绪”）、设备管理器（存在无感叹号的“受信任的平台模块 2.0”）、windows安全中心（“安全处理器详细信息”中版本为2.0）、powershell中get-tpm（tpmpresent与tpmready均为true且specificationversion=“2.0”）、msinfo32（“tpm可用”为是、“tpm基于规范的版本”为2.0、“安全启动状态”为开启）五项，缺一不可。
要确认 Windows 11 电脑中 TPM 芯片当前实际运行的规范版本是 1.2 还是 2.0，不能只看某一个界面显示“已启用”就下结论——很多设备在 BIOS 中打开了开关，但操作系统加载的是旧驱动；有的安全处理器条目存在却带黄色感叹号；还有的 tpm.msc 窗口顶部状态栏写着“已就绪”，可底部“TPM 制造商信息”里的规范版本仍是 1.2。必须交叉验证五个独立路径，缺一不可。
用 tpm.msc 直接读取芯片真实规范版本
这一步最权威，它绕过 UI 层直接调用内核驱动，能暴露 TPM 是否被 Windows 真实接管、版本是否被固件或驱动降级伪装。
同时按下 Win + R 打开运行框 → 输入 tpm.msc 后回车。
若弹出“找不到兼容的 TPM”窗口，说明主板固件中 TPM 功能未启用，或芯片物理缺失——此时后续所有软件层检查都无意义，直接进 BIOS 设置。
窗口正常打开后，先看右侧【状态】字段：必须显示“TPM 已准备就绪，您可以使用”。再滚动到底部“TPM 制造商信息”区域，重点核对【规范版本】字段值——【这里才是最终依据，UI 上方的状态栏偶尔会缓存旧数据】。只有明确显示“2.0”才算数，出现“2.0(1.2兼容模式)”“1.2”“空白”或“未知”均无效。
通过设备管理器确认硬件枚举结果
该方法直查操作系统是否把 TPM 当作真实设备加载，可识别 Intel PTT 或 AMD fTPM 这类固件级实现，排除驱动未加载导致的误判。
右键开始按钮 → 选择“设备管理器”。
点击顶部菜单“查看” → 勾选“显示隐藏的设备”。
向下展开“安全设备”分类 → 查找条目名称是否为【受信任的平台模块 2.0】——注意：必须带“2.0”后缀，仅写“受信任的平台模块”的是 TPM 1.2 或未初始化状态。
双击该条目 → 切换到“常规”选项卡 → 确认“设备状态”显示“此设备运转正常”。如果出现黄色感叹号，右键选择“更新驱动程序” → “自动搜索驱动程序”，强制刷新枚举。
Windows 安全中心快速定位问题源头
这个界面不光显示状态，还能一键跳转到 UEFI 设置，避免反复重启失败错过按键时机。
打开“设置”→ 隐私和安全性 → Windows 安全中心 → 设备安全性。
在右侧找“安全处理器”区域：如果整个区域空白，或只写“安全处理器不可用”，【说明 TPM 在固件中被彻底禁用，操作系统根本没收到任何硬件响应】。
若显示“安全处理器详细信息”链接，点击进入 → 核对“规范版本”是否为 2.0。此处显示 2.0 仍不够，必须同步满足 tpm.msc 和设备管理器的验证结果才算真正开启。
PowerShell 获取底层结构化输出
PowerShell 的 Get-Tpm 命令返回原始 WMI 数据，不受图形界面缓存干扰，适合排除假阳性。
以管理员身份打开 PowerShell（右键开始按钮 → Windows Terminal（管理员））。
输入命令：Get-Tpm，回车执行。
重点检查三项返回值：TpmPresent 必须为 True（芯片物理存在），TpmReady 必须为 True（固件已启用且驱动加载成功），SpecificationVersion 必须严格等于 “2.0”。任意一项不满足，即未达标。
msinfo32 中确认 TPM 服务与安全启动状态
系统信息工具能呈现 TPM 服务是否运行、安全启动是否开启，这两项是 TPM 2.0 正常工作的隐性前提条件。
按下 Win + R → 输入 msinfo32 → 回车。
在右侧信息列表中查找以下两项：
“TPM 可用”字段值必须为“是”；
“TPM 基于规范的版本”字段值必须为“2.0”；
“安全启动状态”字段值必须为“开启”。若为“关闭”或“不支持”，即使其他四项全绿，TPM 2.0 实际也无法被 Windows 11 安全功能调用。
