我们有几个Surface Pro 3设备在TPM + PIN模式下启用BitLocker的情况下部署。 该设备有一个TPM 2.0芯片，并运行Windows 8.1 Pro。
我们遇到了一个问题，即当用户input正确的PIN码时，偶尔会出现“input的PIN错误太多”错误。 然后他们必须input恢复密钥才能继续启动过程。 然后他们每次启动设备都需要input恢复密钥，直到我们使用tpm.msc手动重置TPMlocking，这显然是不方便的。
出于某种原因，TPM正在进入locking状态，但似乎并不是因为反复尝试错误的PIN。 事实上locking最终没有超时，如果你离开设备运行也暗示除了达到最大数量的不正确的authentication尝试之外的其他原因。 我了解TPM 2.0规范指出，这应该是这种情况，不像TPM 1.2规范那样给供应商留下了确切的行为。
运行Get-Tpm表明TPM肯定处于locking状态，但不提供有关原因的任何信息。
有谁知道是否有什么我可以做，试图确定locking的根本原因？
我读过的解释是，TPM无法写入任何types的日志或导致locking到拒绝访问的驱动器。 明智的。 给出一个理由也可能带来安全漏洞。
我能够find的唯一信息就是input错误密码的次数。 打开一个提升的powershell提示符并input：
得到-TPM
与正常的命令shell不同，您将拥有LockoutCount和LockoutMax的条目。 这会给你一个input多less个错误密码的计数。 我确定用户确信他们总是进入正确的销售渠道，但我发现通常是沟通不畅。
这就是说，还有很多其他的locking原因。 https://technet.microsoft.com/en-us/library/dn383583(v=ws.11).aspx具体“什么原因Bitlocker恢复？ 插入CD使设备的电池完全放电可能导致locking。 这是我试图通过用户教育，帮助台教育以及评估哪些群组/本地政策环境的混合来解决的问题。 https://technet.microsoft.com/en-us/library/jj679890(v=ws.11).aspx
最后，我设法解决了这个问题。 我会尽我所能去记住细节，但已经有一段时间了…
不幸的是，有问题的机器是Windows 8机器，所以Get-Tpm cmdlet不会返回有关locking计数器的信息。 我最终成功地将一个自定义脚本放在一起，直接从TPM读取这些计数器，当然，locking计数器已达到locking阈值。 即使我们没有错误地inputPIN，情况也是如此。
经过大量的挖掘之后，我终于偶然发现了TPM 2.0规范中的一个部分，该部分描述了几乎肯定会导致问题的机制。 在详细讨论之前，稍微介绍一下背景知识……在操作系统使用TPM之前，必须调用TPM的启动例程。 这似乎发生在显示BitLocker PIN屏幕之前。 相反，一旦操作系统完成使用TPM，它应该调用TPM的关机例程。 Windows似乎在操作系统关机顺序中这样做。
当系统关机而没有干净地closures操作系统时，问题就出现了。 在这种情况下，TPM的关机程序在芯片断电之前没有被调用。 TPM 2.0规范指出，如果TPM的启动例程在没有先前调用TPM的closures例程的情况下被调用，则应该将locking计数器递增1。 此function用于防止针对TPM的特定types的攻击。 因此，即使用户input正确的BitLocker PIN，当设备再次开机时，locking计数器也会增加1。
在我的具体情况下，有问题的设备都是Microsoft Surface Pro 3平板电脑。 我的直觉是，用户按下电源buttonclosures机器，而无需清理干净。 通常情况下，这个问题并不是一个大问题，因为停工柜台在两个小时后最终会再次减less。 但是，如果他们经常这样做，locking柜台没有时间减less。 如果机器重新上电，用于跟踪何时递减的定时器被重置，这意味着它必须在递减前持续两个小时。 一些用户只能在短时间内取出机器。
Surface Pro 3支持Microsoft称之为“Connected Standby”或“InstantGo”。 这是一个function，使得该设备在电源pipe理方面更像移动设备。 点击电源button使设备进入低功耗模式，而不是传统的待机模式或睡眠模式。 但是，我们已经将电源计划转换为“高性能”，这具有禁用连接待机模式的效果，使得设备像传统的PC一样运行。 我认为这可能是问题的一个因素。