安全開機疑難排解指南

套用到
Windows 10, version 1607, all editions Win 10 Ent LTSB 2016 Win 10 IoT Ent LTSB 2016 Windows 10, version 1809, all editions Win 10 Ent LTSC 2019 Win 10 IoT Ent LTSC 2019 Windows 10 ESU Windows 10 Enterprise LTSC 2021 Windows 10 IoT Enterprise LTSC 2021 Windows 11 version 23H2, all editions Windows 11 version 24H2, all editions Windows 11 version 25H2, all editions Windows 11 version 26H1, all editions Windows Server 2016 Windows Server 2019 Windows Server 2022 Windows Server, version 23H2 Windows Server 2025

注意

  • 原始發佈日期： 2026 年 3 月 19 日
  • KB 識別碼： 5085046

本文內容

概觀

本頁會引導系統管理員和支援專業人員診斷和解決 Windows 裝置上的安全開機相關問題。 主題包括安全開機憑證更新失敗、不正確的安全開機狀態、意外的 BitLocker 復原提示，以及安全開機設定變更後的開機失敗。

此指引說明如何驗證 Windows 維護和設定、檢閱相關的登錄值和事件記錄檔，以及識別何時因韌體或平台限制需要 OEM 更新。 此內容用於診斷現有裝置上的問題。 它不是用來規劃新的部署。 隨著新的疑難排解案例和指引的確定，本文件將會更新。

回到頁首

安全開機憑證服務的運作方式

Windows 上的安全開機憑證服務是作業系統與裝置 UEFI 韌體之間的協調程序。 目標是更新關鍵的信賴起點，同時保留在每個階段啟動的能力。

此程序是由 Windows 排程的工作、登錄型更新動作順序，以及內建的記錄和重試行為所驅動。 這些元件一起可確保安全開機憑證和 Windows 開機管理程式會以受控、有序的方式更新，而且只有在先決條件步驟成功之後才更新。

回到頁首

疑難排解時應從何處開始

當裝置在套用安全開機憑證更新方面似乎未取得預期進展時，請從識別問題類別開始。 大部分問題都屬於四個區域之一：Windows 維護狀態、安全開機更新機制、韌體行為或平台或 OEM 限制。

依序從下列檢查開始。 在許多情況下，這些步驟足以解釋觀察到的行為並確定後續動作，而無需進行更深入的調查。

  1. 確認 Windows 維護與平台資格

    1. 確認裝置符合接收安全開機憑證更新的基本需求：
    2. 裝置正在執行支援的 Windows 版本。
    3. 已安裝最新的必要 Windows 安全性更新。
    4. UEFI 韌體中已啟用安全開機。
    5. 如果未滿足這些條件中的任何一個，請先解決這些問題，然後再繼續進行進一步的疑難排解。

  2. 驗證安全開機更新工作狀態

    1. 確認負責套用安全開機憑證更新的 Windows 機制存在且運作：
    2. 安全開機更新排程工作存在。
    3. 工作已啟用並以本機系統方式執行。
    4. 自從安裝最新的 Windows 安全性更新後，工作至少執行過一次。
    5. 如果工作已停用、刪除或未執行，就無法套用安全開機憑證更新。 疑難排解應著重於還原工作，再調查其他原因。

  3. 檢查預期進度的登錄設定
    在登錄中檢閱裝置的安全開機服務狀態：

    1. 檢查 UEFICA2023Status、 UEFICA2023Error 和 UEFICA2023ErrorEvent。
    2. 檢查 AvailableUpdates ，並將它與預期的進度比較 (請參閱參考和內部) 。

    這些值一起表示維護是否正常進行、重試作業或在特定步驟處停止。

  4. 將登錄狀態與安全開機事件相互關聯
    檢閱系統事件記錄檔中的安全開機相關事件，並將它們與登錄狀態建立關聯。 事件資料通常會確認裝置是否正在向前推進、因為暫時性條件而重試，或是由韌體或平台問題封鎖。
    登錄和事件記錄檔通常會一起指出行為是預期的、暫時性的，還是需要更正動作的。

回到頁首

安全開機更新排程工作

安全開機憑證服務是透過名為 Secure-Boot-Update 的 Windows 排程工作來實作。 工作會在以下路徑註冊：

注意

\Microsoft\Windows\PI\Secure-Boot-Update

工作會以本機系統方式執行。 根據預設，它會在系統啟動時執行，之後每 12 小時執行一次。 每次執行時，它都會檢查安全開機更新動作是否擱置中，並嘗試依序套用它們。

如果此工作已停用或遺失，就無法套用安全開機憑證更新。 安全開機更新工作必須保持啟用狀態，安全開機服務才能正常運作。

回到頁首

為什麼要使用排程任務

安全開機憑證更新需要 Windows 和 UEFI 韌體之間的協調，包括寫入儲存安全開機金鑰和憑證的 UEFI 變數。 排程工作可讓 Windows 在系統處於可以修改韌體變數的狀態時嘗試這些更新。

週期性 12 小時排程可讓您在先前嘗試失敗，或裝置保持開啟電源而未重新啟動時，重新嘗試更新。 這種設計有助於確保向前進展，而無需人工干預。

回到頁首

AvailableUpdates 登錄位元遮罩

Secure-Boot-Update 工作是由 AvailableUpdates 登錄值所驅動。 此值是 32 位元位元遮罩，位於：

注意

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot

值中的每個位元代表特定的安全開機更新動作。 當 AvailableUpdates 設定為非零值時，更新程序隨即開始，這可以由 Windows 自動或由系統管理員明確地設定。 例如，值如 0x5944 表示多個更新動作擱置中。

當 Secure-Boot-Update 工作執行時，它會將設定的位元解譯為擱置中工作，並按照定義的順序處理它們。

回到頁首

循序更新、記錄和重試行為

以固定順序套用安全開機憑證更新。 每個更新動作的設計都旨在安全地重試並獨立完成。 在目前動作成功，且從 AvailableUpdates 中清除其對應位元之前，Secure-Boot-Update 工作不會進入下一個步驟。

每個作業都會使用標準 UEFI 介面來更新安全開機變數，例如 DB 和 KEK，或安裝更新的 Windows 開機管理程式。 Windows 會在系統事件記錄檔中記錄每個步驟的結果。 成功事件確認前進進度，而失敗事件則指出動作無法完成的原因。

如果更新步驟失敗，工作會停止處理、記錄錯誤，並保留相關聯的位元集。 下次執行工作時，將重試作業。 此重試行為可讓裝置自動從暫時狀況復原，例如缺少韌體支援或延遲 OEM 更新。

系統管理員可以將登錄狀態與事件記錄項目相互關聯，以追蹤進度。 UEFICA2023Status、UEFICA2023Error 和 UEFICA2023ErrorEvent 等登錄值，以及 AvailableUpdates 位元遮罩，會指出哪個步驟為使用中、已完成或已封鎖。

此組合會顯示裝置是正常執行、重試作業還是已停止。

回到頁首

與 OEM 韌體整合

安全開機憑證更新取決於裝置 UEFI 韌體中的正確行為和支援。 當 Windows 協調更新程序時，韌體負責強制執行安全開機原則並維護安全開機資料庫。

OEM 提供兩個啟用安全開機憑證服務的重要元素：

  • 平台金鑰簽署金鑰交換金鑰 (KEK) ，可授權安裝新的安全開機憑證。
  • 在更新期間正確保留、附加及驗證安全開機資料庫的韌體實作。

如果韌體不完全支援這些行為，安全開機更新可能會停止、無限重試，或導致開機失敗。 在這些情況下，Windows 無法在不變更韌體的情況下完成更新。

Microsoft 與 OEM 合作找出韌體問題，並提供更正的更新。 當疑難排解指出韌體限制或瑕疵時，系統管理員可能需要安裝裝置製造商提供的最新 UEFI 韌體更新，安全開機憑證更新才能成功完成。

回到頁首

常見失敗案例和解決方法

安全開機更新是由安全開機-更新排程工作根據 AvailableUpdates 登錄狀態套用。

在正常情況下，這些步驟會自動發生，並在每個階段完成時記錄成功事件。 在某些情況下，韌體行為、平台設定或服務必要條件可能會阻礙進度或導致非預期的開機行為。

以下各節說明最常見的故障案例、如何識別它們、發生它們的原因，以及恢復正常操作的適當後續步驟。 案例從最常遇到的情況到影響開機的嚴重案例排序。

未套用安全開機更新 (沒有進度)

當安全開機更新未顯示任何進度時，通常表示更新程序從未開始。 因此，預期的安全開機登錄值和事件記錄檔會遺失，因為從未觸發更新機制。

發生了什麼事

安全開機更新程序未啟動，因此裝置未套用安全開機憑證或更新的開機管理程式。

如何辨識

  • 不存在安全開機服務登錄值，例如 UEFICA2023Status。
  • 系統事件記錄檔中會遺失預期的安全開機事件 (例如 1043、1044、1045、1799、1801) 。
  • 裝置會繼續使用較舊的安全開機憑證和開機元件。

發生原因

當下列一或多個條件成立時，通常會發生這種情況：

  • 安全開機更新排程工作已停用或遺失。
  • UEFI 韌體中的安全開機已停用。
  • 裝置不符合 Windows 維護必要條件，例如執行支援的 Windows 版本或已安裝必要的更新。

後續處理方式

  • 確認裝置符合 Windows 維護和平台資格需求。
  • 確認韌體中已啟用安全開機。
  • 確定 SecureBootUpdate 排程工作存在且已啟用。

如果排程工作已停用或遺失，請依照 安全開機 停用或刪除排程工作 中的指引來還原。 工作還原之後，請重新啟動裝置或手動執行工作，以起始安全開機服務。

裝置在安全開機更新之後開機進入 BitLocker 復原

在某些情況下，安全開機相關更新可能會導致裝置進入 BitLocker 修復。 行為可以是暫時性的，也可以是持續性的，具體取決於根本原因。

案例 1：安全開機更新後的一次性 BitLocker 復原

發生什麼事

裝置會在安全開機更新之後的第一次開機時進入 BitLocker 復原，但在後續重新啟動時會正常開機。

發生原因

在更新之後的第一次開機期間，當 Windows 嘗試重新封裝 BitLocker 時，韌體尚未報告更新的安全開機值。 這會導致測量的開機值暫時不符，並觸發復原。 下次開機時，韌體會正確報告更新的值，BitLocker 重新封裝成功，而且問題不會再次發生。

如何辨識

  • BitLocker 復原會執行一次。
  • 輸入修復金鑰之後，後續開機不會提示復原。
  • 不存在進行中的啟動順序或 PXE 相關。

後續處理方式

  • 請輸入 BitLocker 修復金鑰來恢復 Windows。
  • 檢查韌體更新。

案例 2：由於 PXE 首次開機設定而重複的 BitLocker 復原

發生什麼事

裝置會在每次開機時進入 BitLocker 復原。

發生原因

裝置設定為 先嘗試 PXE (網路) 開機。 PXE 開機嘗試失敗，然後韌體回復到磁碟上的 Windows 開機管理程式。

這會導致 在單一開機週期期間測量兩個不同的簽署授權單位：

  • PXE 開機路徑由 Microsoft UEFI CA 2011 簽署。
  • 磁碟上的 Windows 開機管理程式由 Windows UEFI CA 2023 簽署。

因為 BitLocker 在啟動期間會觀察到不同的安全開機信任鏈結，所以無法建立一組穩定的 TPM 度量來重新密封。 因此，BitLocker 會在每次開機時進入復原。

如何辨識

  • 每次重新啟動時都會觸發 BitLocker 復原。
  • 輸入修復金鑰可讓 Windows 啟動，但下次開機時會傳回提示。
  • PXE 或網路開機是按照韌體開機順序設定在本機磁碟之前。

後續處理方式

  • 設定韌體開機順序，讓磁碟上的 Windows 開機管理程式排在最前頭。
  • 如果不需要，請停用 PXE 開機。
  • 如果需要 PXE，請確保 PXE 基礎架構使用 2023 年簽署的 Windows 開機載入器。
重設安全開機之後裝置無法開機

發生了什麼事

這反映的是韌體層級變更，而不是 Windows 問題。 安全開機更新已成功完成，但稍後重新開機之後，裝置不再開機進入 Windows。

如何辨識

  • 裝置無法啟動 Windows，且可能會顯示韌體或 BIOS 訊息指出安全開機違規。
  • 將安全開機設定重設為韌體預設值之後，會發生失敗。
  • 停用安全開機可能會允許裝置再次開機。

發生原因

將安全開機重設為韌體預設值會清除儲存在韌體中的安全開機資料庫。 在已轉換至 Windows UEFI CA 2023 簽署開機管理程式的裝置上，此重設會移除信任該開機管理程式所需的憑證。

因此，韌體不再將已安裝的 Windows 開機管理程式辨識為信任，並封鎖開機程序。

這種情況不是由安全開機更新本身引起的，而是由移除更新的信賴起點的後續韌體動作所造成。

後續處理方式

  • 使用安全開機復原公用程式來還原所需的憑證，讓裝置可以再次開機。
  • 復原之後，請確定裝置已安裝裝置製造商提供的最新可用韌體。
  • 除非 OEM 韌體包含信任 2023 憑證的更新安全開機預設值，否則請避免將安全開機重設為韌體預設值。

安全開機復原公用程式

復原系統：

  1. 在安裝了 2024 年 7 月或更新版本 Windows 更新的第二台 Windows 電腦上，從 C：\Windows\Boot\EFI\ 複製 SecureBootRecovery.efi。
  2. 將檔案放在 FAT32 格式的 USB 磁碟機上的 \EFI\BOOT\ 底下，然後重新命名為 bootx64.efi。
  3. 從 USB 磁碟機將受影響的裝置開機，並讓修復公用程式執行。 該公用程式會將 Windows UEFI CA 2023 新增至資料庫。

還原憑證並重新啟動系統之後，Windows 應會正常啟動。

重要： 此程序只會重新套用其中一個新憑證。 復原裝置之後，請確定已重新套用最新的憑證，並考慮將系統的 BIOS/UEFI 更新至最新的可用版本。 這有助於防止安全開機重設問題再次發生，因為許多 OEM 已經針對此特定問題發行韌體修正程式。

由於韌體覆寫 DB，導致安全開機更新後裝置無法開機

發生了什麼事

套用安全開機憑證更新並重新啟動之後，裝置無法開機且無法連線至 Windows。

如何辨識

  • 裝置在安全開機更新所需的重新啟動之後立即失敗。
  • 可能會顯示韌體或安全開機錯誤，或系統可以在 Windows 載入之前停止。
  • 停用安全開機可能允許裝置開機。

發生原因

此問題可能是由裝置的 UEFI 韌體實作中的缺陷所造成。

當 Windows 套用安全開機憑證更新時，韌體預期會將新的憑證 附加 至現有的安全開機允許簽章資料庫 (DB) 。 某些韌體實作會錯誤地 覆寫 DB，而不是附加到它。

發生這種情況時，

  • 先前信任的憑證，包括 Microsoft 2011 開機載入器憑證，都會被移除。
  • 如果系統此時仍在使用以 2011 憑證簽署的開機管理程式，則韌體將不再信任它。
  • 韌體拒絕開機管理程式並封鎖開機程序。

在某些情況下，資料庫也可能會損毀，而不是完全覆寫，導致相同的結果。 此行為已在特定韌體實作上觀察到，且在符合規範的韌體上不會發生。

後續處理方式

  • 輸入韌體設定選單，並嘗試重設安全開機設定。
  • 如果重設後裝置可開機，請檢查裝置製造商的支援網站，以取得可修正安全開機 DB 處理的韌體更新。
  • 如果有可用的韌體更新，請先安裝它，然後再重新啟用安全開機並重新套用安全開機憑證更新。

如果重設安全開機無法還原開機功能，進一步復原可能需要 OEM 特定的指導方針。

安全開機更新因遺失 OEM 簽署的 KEK 而遭到封鎖

發生了什麼事

安全開機憑證更新尚未完成，且在金鑰交換金鑰 (KEK) 更新階段仍處於封鎖狀態。

如何辨識

  • AvailableUpdates 登錄值會保持使用 KEK 位元 (0x0004) 設定，且不會清除。
  • UEFICA2023Status 不會進展為已完成狀態。
  • 系統事件記錄檔會重複記錄事件 識別碼 1803，表示無法套用 KEK 更新。
  • 裝置會繼續重試更新，而不會向前推進。

發生原因

更新安全開機 KEK 需要從 OEM 擁有的 裝置平台金鑰 (PK) 授權。

若要讓更新成功，裝置製造商必須提供 Microsoft 該特定平台的 PK 簽署 KEK 。 這個 OEM 簽署的 KEK 包含在 Windows 更新中，並允許 Windows 更新韌體 KEK 變數。

如果 OEM 尚未為裝置提供 PK 簽署的 KEK，Windows 就無法完成 KEK 更新。 在此狀態下：

  • 安全開機更新是設計上封鎖的。
  • Windows 無法解決缺少的授權。
  • 裝置可能永遠無法完成安全開機憑證服務。

這可能發生在 OEM 不再提供韌體或重要更新的較舊或不受支援的裝置上。 目前沒有支援適用於這種情況的手動復原路徑。

回到頁首

安全開機憑證更新事件和失敗指標

當無法套用安全開機憑證更新時，Windows 會記錄診斷事件，以說明進度遭到封鎖的原因。 當更新安全開機簽章資料庫時，會寫入這些事件 (DB) 或金鑰交換金鑰 (KEK) 因為韌體、平台狀態或設定條件而無法安全完成。 本節中的案例會參考這些事件，以識別常見的失敗模式，並判斷適當的補救措施。 本節旨在支援對先前所述的問題的診斷和解釋，而不是引入新的失敗案例。

如需事件識別碼、描述和範例項目的完整清單，請參閱安全 開機 DB 和 DBX 變數更新事件 (KB5016061) 。

KEK 更新失敗 (DB 更新成功，KEK 不)

裝置可以成功更新安全開機資料庫中的憑證，但在 KEK 更新期間失敗。 發生這種情況時，就無法完成安全開機更新程序。

問題

  • 資料庫憑證事件指出進度，但 KEK 階段尚未完成。
  • AvailableUpdates 會持續設定為 0x4004，且在執行多次工作後不會清除0x0004位元。
  • 可能出現事件 1795 或 1803 。

釋義

  • 1795 通常表示嘗試更新安全開機變數時韌體失敗。
  • 1803 表示無法授權 KEK 更新，因為平台沒有必要的 OEM PK 簽署 KEK 承載。

後續步驟

  • 針對 1795，請檢查 OEM 韌體更新，並驗證安全開機變數更新的韌體支援。
  • 針對 1803，請確認 OEM 是否已提供 Microsoft 裝置型號所需的 PK 簽署 KEK。

在 Hyper-V 上託管的訪客 VM 上發生 KEK 更新失敗

在 Hyper-V 虛擬機器上，安全開機憑證更新需要在 Hyper-V 主機和客體作業系統上安裝 2026 年 3 月 Windows 更新。

更新失敗是 從來賓內部報告的，但事件會指出需要補救的位置：

  • 例如，客體中報告的事件 1795 (「媒體受到寫入保護」) 表示 Hyper-V 主機缺少 2026 年 3 月更新，必須更新。
  • 來賓中報告的事件 1803 表示客體虛擬機器本身遺失 2026 年 3 月更新，必須更新。

回到頁首

參照和內部結構

本節包含進階參考資訊，可用於疑難排解和支援。 它不適用於部署規劃。 它擴充先前摘要所述的安全開機服務機制，並提供詳細的參考資料來解釋登錄狀態和事件記錄檔。

注意 (IT 管理的部署) ： 透過 群組原則 或 Microsoft Intune 進行設定時，不應混淆兩個相似的設定。 AvailableUpdatesPolicy 值代表設定的原則狀態。 同時， AvailableUpdates 反映進行中、位元清除的工作狀態。 兩者都可以帶來相同的結果，但它們的行為不同，因為政策會隨著時間的推移而重新適用。

回到頁首

AvailableUpdates 用於憑證服務的位元

下列位元用於本文件所述的憑證和開機管理程式動作。 [ 順序 ] 欄會反映 Secure-Boot-Update 工作處理每個位元的順序。

順序 位元設定 用法
1 0x0040 此位會告知排程工作將 Windows UEFI CA 2023 憑證新增至安全開機資料庫。 這可讓 Windows 信任由此憑證簽署的開機管理程式。
2 0x0800 此位會告知排程工作將 Microsoft 選項 ROM UEFI CA 2023 套用至資料庫。
條件行為：設定 0x4000 旗標時，排程的工作會先檢查資料庫中是否有 Microsoft Corporation UEFI CA 2011 憑證。 僅當 2011 憑證存在時，它才會套用 Microsoft Option ROM UEFI CA 2023 憑證。
3 0x1000 此位會告知排程工作將 Microsoft UEFI CA 2023 套用至資料庫。
條件行為：設定 0x4000 旗標時，排程的工作會先檢查資料庫中是否有 Microsoft Corporation UEFI CA 2011 憑證。 僅當 2011 憑證存在時，它才會套用 Microsoft UEFI CA 2023 憑證。
修飾詞 (行為標幟) 0x4000 此位元會修改 0x0800 位元和 0x1000 位元的行為，讓只有在資料庫已包含 Microsoft Corporation UEFI CA 2011 時，才會套用 Microsoft UEFI CA 2023 和Microsoft選項 ROM UEFI CA 2023。

為了協助確保裝置的安全性設定檔保持不變，只有在裝置信任 Microsoft Corporation UEFI CA 2011 憑證時，此位才會套用這些新憑證。 並非所有 Windows 裝置都信任此憑證。
4 0x0004 此位會告知排程的工作尋找由裝置的平台金鑰 (PK) 所簽署的金鑰交換金鑰。 PK 由 OEM 管理。 OEM 使用其 PK 簽署 Microsoft KEK，並將其傳遞給 Microsoft，將其包含在每月累積更新中。
5 0x0100 此位會告知排程工作將由 Windows UEFI CA 2023 簽署的開機管理程式套用至開機磁碟分割。 這將取代 Microsoft Windows Production PCA 2011 簽署的開機管理程式。

附註：

  • 處理所有其他位元之後，0x4000位元將保持設定。
  • 每個位元都會依照上述順序由安全開機更新排程工作處理。
  • 如果由於缺少 PK 簽名的 KEK 而無法處理0x0004位元，排程的工作仍將套用位元 0x0100 指示的開機管理程式更新。

回到頁首

預期進度 (可用更新)

當作業成功完成時，Windows 會從 AvailableUpdates 中清除相關聯的位元。 如果作業失敗，Windows 會記錄事件，並在工作再次執行時重試。

下表顯示每個安全開機更新動作完成時 AvailableUpdates 值的預期進度。

步驟 已處理的位元 可用匯報 描述 成功事件記錄 可能的錯誤事件代碼
開始 0x5944 安全開機憑證服務開始前的初始狀態。 - -
1 0x0040 0x5944 → 0x5904 Windows UEFI CA 2023 已新增至安全開機資料庫。 1036 1032, 1795, 1796, 1802
2 0x0800 0x5904 → 0x5104 如果裝置先前信任 Microsoft UEFI CA 2011，請將 Microsoft 選項 ROM UEFI CA 2023 新增至資料庫。 1044 1032, 1795, 1796, 1802
3 0x1000 0x5104 → 0x4104 如果裝置先前信任 Microsoft UEFI CA 2011，則會將 Microsoft UEFI CA 2023 新增至 DB。 1045 1032, 1795, 1796, 1802
4 0x0004 0x4104 → 0x4100 已套用由 OEM 平台金鑰簽署的新版 Microsoft KEK 2K CA 2023。 1043 1032, 1795, 1796, 1802, 1803
5 0x0100 0x4100 → 0x4000 已安裝由 Windows UEFI CA 2023 簽署的開機管理程式。 1799 1797

附註

  • 一旦與位元相關聯的作業成功完成，該位就會從 AvailableUpdates 中清除。
  • 如果其中一個作業失敗，則會記錄事件，並在下次執行排程工作時重試該作業。
  • 0x4000位是修飾詞，不會清除。 最終的 AvailableUpdates 值為 0x4000 表示所有適用的更新動作已順利完成。
  • 事件 1032、1795、1796、1802 通常表示韌體或平台限制。
  • 事件 1803 表示遺失 OEM PK 簽署的 KEK。

回到頁首

補救程序

本節提供補救特定安全開機問題的逐步程序。 每個程序的範圍都限定為明確定義的條件，並且只有在初步診斷確認問題適用後才應遵循。 使用這些程序可還原預期的安全開機行為，並允許憑證更新安全地繼續進行。 請勿廣泛或先發制人地套用這些程序。

回到頁首

在韌體中啟用安全開機

如果在裝置韌體中停用安全開機，請參閱 Windows 11 和安全開機以取得啟用安全開機的詳細資訊。

回到頁首

安全開機排程工作已停用或刪除

Windows 需要安全 開機更新 排程工作，才能套用安全開機憑證更新。 如果工作停用或遺失，安全開機憑證服務將不會進行。

工作詳細資料

任務名稱 Secure-Boot-Update
工作路徑 \Microsoft\Windows\PI\
完整路徑 \Microsoft\Windows\PI\Secure-Boot-Update
執行為 SYSTEM (Local System)
觸發程序 啟動時和每 12 小時一次
必要狀態 已啟用

如何檢查工作狀態

從提高權限的 PowerShell 提示字元執行：
schtasks.exe /query /TN “\Microsoft\Windows\PI\Secure-Boot-Update” /fo LIST /v

尋找 [狀態 ] 欄位：

狀態 意義
就緒 工作存在且已啟用。
已停用 工作存在，但必須啟用。
錯誤/找不到 工作遺失，必須重新建立。

如何啟用或重新建立工作

如果 [Secure-Boot-Update] 的狀態欄位為 [已停用]、[錯誤] 或 [找不到]，請使用範例指令碼來啟用工作： 範例 Enable-SecureBootUpdateTask.ps1

注意：這是範例指令碼，不受 Microsoft 支援。 管理員應審查並使其適應其環境。

範例：

注意

.\Enable-SecureBootUpdateTask.ps1 -安靜

執行指引

  • 如果您看到拒絕存取，請以系統管理員身分重新執行 PowerShell。
  • 如果指令碼不會因為執行原則而執行，請使用處理程序範圍旁路：

注意

Set-ExecutionPolicy -scope Process -ExecutionPolicy Bypass

回到頁首