共用方式為


韌體更新之後的 BitLocker 檢查

此測試會判斷裝置是否在韌體更新程式期間達到復原。 必須在韌體更新之前啟用 BitLocker,而且應在更新之後執行測試。

測試詳細資料

   
規格
  • Device.DevFund.Firmware.UpdateDriverPackage
平台
  • Windows 10,用戶端版本 (x86)
  • Windows 10,用戶端版本 (x64)
  • Windows Server 2016 (x64)
  • Windows 10,用戶端版本 (Arm64)
支援的版本
  • Windows 10
  • Windows 10 (版本 1511)
  • Windows 10 (版本 1607)
  • Windows 10 (版本 1703)
  • Windows 10 (版本 1709)
  • Windows 10 (版本 1803)
  • Windows 10 版本 1809
  • Windows 10 (版本 1903)
  • Windows 10的下一個更新
預期的執行時間 (以分鐘為單位) 5
類別 案例
以分鐘為單位的逾時 () 300
需要重新開機 false
需要特殊設定 false
類型 automatic

 

其他檔

此功能區域中的測試可能會有其他檔,包括必要條件、設定和疑難排解資訊,可在下列主題中找到 () :

執行測試

測試會傳回 Pass 或 Fail。

疑難排解

如需 HLK 測試失敗的一般疑難排解,請參閱 針對 Windows HLK 測試失敗進行疑難排解

如果測試失敗,表示此系統已達到 BitLocker 復原。 請在事件檢視器中收集兩個位置的 BitLocker 事件:

  • 應用程式和服務記錄 > Microsoft > Windows > BitLocker-API > 管理

  • 篩選 Windows 記錄 >以 BitLocker 啟動的事件來源系統

事件應提供復原叫用原因的詳細原因。 瞭解並修正 BitLocker 復原的根本原因之後,請在從未叫用 BitLocker 復原的系統上執行測試,以取得通過的結果。

如果系統使用安全開機進行完整性檢查 () ) ,請參閱下列步驟以取得更多診斷資訊。

  1. 韌體更新套件可能會觸發復原。

  2. 如果系統有 TPM2.0,則需要使用[7] 支援。 否則,可選擇性地支援[7]。 樹狀結構 EFI 通訊協定規格有關于[7] 支援的詳細資料。

  3. 檢查此系統是否支援[7],並透過從提升許可權的命令提示字元發出下列命令,讓 BitLocker/裝置加密使用:

    Manage-bde -protectors -get %systemdrive%
    

    如果 (使用安全開機進行完整性驗證) ,則 (顯示[USB 驗證設定檔] 顯示 [USB 7]、[11 (],系統就會正確設定。

    例如,如果 USB 驗證設定檔未顯示 BitLocker 會使用安全開機進行完整性驗證 (,則「USB 驗證設定檔」顯示「支援」0、2、4、11) ,這表示 BitLocker 無法使用[7],而且下列其中一個事件可能會記錄到 應用程式與服務記錄 > 檔 Microsoft > Windows > BitLocker-API > 管理中找到。

    • BitLocker 無法使用安全開機進行完整性,因為它已停用。

    • BitLocker 無法使用安全開機進行完整性,因為必要的 UEFI 變數 X 不存在。

    • BitLocker 無法使用安全開機進行完整性,因為無法讀取 UEFI 變數 X。 錯誤訊息:X。

    • BitLocker 無法針對完整性使用安全開機,因為變數 X 的預期 TCG 記錄專案遺失或無效。

    • BitLocker 無法使用安全開機的完整性,因為 OS Loader Authority 的預期 TCG 記錄專案遺失或無效。

    • BitLocker 無法使用安全開機完整性,因為 OS Loader Authority 的預期 TCG 記錄專案具有不正確結構。 事件必須是EV_EFI_VARIABLE_AUTHORITY事件。 事件資料必須格式化為EFI_VARIABLE_DATA結構,且 VariableName 設定為 EFI_IMAGE_SECURITY_DATABASEGUID,而 UnicodeName 設定為 'db'。

    • BitLocker 無法使用安全開機完整性,因為 OS Loader Authority 的預期 TCG 記錄專案無效。 EFI_VARIABLE_DATA的內容。VariableData 欄位應該是EFI_SIGNATURE_DATA結構,且 SignatureOwner 設定為 GUID {77fa9abd-0359-4d32-bd60-28f4e78f784b} (Microsoft) 。

    • BitLocker 無法使用安全開機完整性,因為 OS Loader Authority 的預期 TCG 記錄專案無效。 在安全開機 'db' 簽章資料庫中找不到 OS 授權單位事件中包含的EFI_SIGNATURE_DATA結構。

    • BitLocker 無法使用安全開機完整性,因為開機載入器的簽章無法驗證為鏈結至受信任 Microsoft 根憑證的 Windows 簽章。

    • BitLocker 無法針對完整性使用安全開機,因為 OS Loader Authority 的 TCG 記錄專案無效。 在開機載入器的已驗證憑證鏈結中,找不到作業系統授權單位事件EFI_SIGNATURE_DATA結構中包含的簽章。

    • BitLocker 無法使用安全開機進行完整性,因為預期的 TCG 記錄分隔符號專案遺失或無效。

    • BitLocker 無法針對完整性使用安全開機,因為 TCG Log forPC [7] 包含不正確專案。

  4. 如果 BitLocker/裝置加密使用由步驟 3 中 manage-bde 命令回報的[7] 和系統點擊復原所報告,您會在 Windows 記錄 > 系統中 看到事件識別碼為 24658 的BitLocker-Driver事件,指出安全開機設定意外變更。 若要診斷此問題,請在 應用程式和服務記錄 > Microsoft > Windows > BitLocker-API > 管理中找到兩個最新的 BitLocker-API 事件 (事件識別碼 817) 。 其中一個 817 事件的時間戳記應該早于事件 24658 的時間戳記;其他 817 事件的時間戳記應晚于。 當 BitLocker 將金鑰密封至 TPM 時,會記錄事件 817,其中會使用此識別碼 [7]。 在 [ 詳細資料] 索引標籤中,您可以找到記錄此事件之開機會話的[7] 值。 假設系統在重新開機期間遇到復原,這兩個開機會話之間的[7] 值應該不同。 這兩個 817 事件中所記錄的PCR [7] 值會指出差異。 在事件 817 中,也會記錄該開機會話的 TCG 記錄。 如果您有一個剖析 TCG 記錄檔的工具,則會顯示有關「類型」擴充功能的詳細資訊。 如果您沒有這類工具,您可以執行下列動作:

    1. TBSLogGenerator.exe 從 Windows HLK 控制器複製到測試電腦。 它位於%systemdrive%\Program Files (x86) \Windows Kits\8.1\Hardware Certification Kit\Tests\< architecture\NTTEST\BASETEST\ngscb,其中 <architecture> 是測試電腦的架構> 。 這可以是 amd64、x86 或 Arm。

      TBSLogGenerator.exe 會在執行 TBSLogGenerator.exe 時,以人類可讀取的格式傾印啟動會話的TBSLogGenerator.exe之TBSLogGenerator.exe的 TCG 記錄。

    2. 重複觸發 BitLocker 復原的步驟。 針對跨 BitLocker 復原的兩個開機會話,請使用 TBSLogGenerator.exe 傾印TBSLogGenerator.exe和 TCG 記錄。

    3. 分析兩組的PCR 值和 TCG 記錄,以找出差異。