疑難排解
Applies To
原始出版日期: 2026年3月19日
KB ID:5085046
本文內容
概觀
本頁引導管理員與支援專業人員診斷並解決 Windows 裝置上安全開機相關問題。 主題包括安全開機憑證更新失敗、錯誤的安全開機狀態、意外的 BitLocker 復原提示,以及安全開機設定變更後的開機失敗。
指引說明如何驗證 Windows 服務與設定、檢視相關登錄檔值與事件日誌,並辨識何時韌體或平台限制需要 OEM 更新。 本內容旨在診斷現有裝置的問題。 它不是用來規劃新部署的。 隨著新的故障排除情境與指引的出現,本文件將持續更新。
安全啟動憑證服務的運作方式
Windows 上的安全開機憑證維護是作業系統與裝置 UEFI 韌體之間協調的過程。 目標是在每個階段都能啟動的同時,更新關鍵的信任錨點。
此程序由 Windows 排程任務、基於登錄檔的更新動作序列,以及內建的日誌與重試行為驅動。 這些元件共同確保安全開機憑證與 Windows 開機管理員能以受控、有序的方式更新,且僅在前置步驟成功後才會更新。
故障排除時該從哪裡開始
當裝置在套用安全開機憑證更新時似乎沒有預期進度,請先確認問題的類別。 大多數問題歸類於四個方面之一:Windows 維護狀態、安全開機更新機制、韌體行為,或平台或 OEM 限制。
請依序從下方檢查開始。 在許多情況下,這些步驟足以解釋觀察到的行為並決定下一步行動,無需深入調查。
-
確認 Windows 服務與平台資格
-
確認裝置符合接收安全開機憑證更新的基本要求:
-
該裝置運行的是支援的 Windows 版本。
-
已安裝最新的 Windows 安全更新。
-
UEFI 韌體啟用了安全開機。
-
如果這些條件中有任何一項未被滿足,請先處理,再進行進一步的故障排除。
-
-
-
確認負責套用安全開機憑證更新的 Windows 機制是否存在且正常運作:
-
安全開機更新排程任務是存在的。
-
該任務已啟用並以本地系統形式執行。
-
自從安裝最新的 Windows 安全更新後,這個任務至少執行過一次。
-
若任務被停用、刪除或未執行,則無法套用安全開機憑證更新。 故障排除應先著重於恢復任務,再調查其他原因。
-
-
請在登錄檔中檢視裝置的安全開機服務狀態:
-
檢視 UEFICA2023Status、 UEFICA2023Error和 UEFICA2023ErrorEvent。
-
檢視 可用更新 並與預期進展比較 (參見參考與內部) 。
這些數值合起來表示維修是否正常進行、重試操作,或在特定步驟停滯。
-
-
檢視系統事件日誌中的安全啟動相關事件,並將其與登錄檔狀態對應。 事件資料通常能確認裝置是否正在前進、因暫態狀況而重試,或因韌體或平台問題而阻塞。
登錄檔與事件日誌通常會顯示行為是預期的、暫時性的,還是需要矯正措施。
安全開機更新排程任務
安全開機憑證服務是透過一個名為 Secure-Boot-Update 的 Windows 排程任務實作。 任務註冊路徑如下:
\Microsoft\Windows\PI\Secure-Boot-Update
該任務以本地系統形式執行。 預設情況下,它會在系統啟動時執行,之後每 12 小時執行一次。 每次執行時,它會檢查安全開機更新動作是否待處理,並嘗試依序套用。
若此任務被停用或缺失,則無法套用安全開機憑證更新。 Secure-Boot-Update 任務必須保持啟用,Secure Boot 服務才能正常運作。
為什麼會使用排程任務
安全開機憑證更新需要 Windows 與 UEFI 韌體間的協調,包括撰寫儲存安全開機金鑰與憑證的 UEFI 變數。 排程任務允許 Windows 在系統處於可修改韌體變數的狀態時嘗試更新。
12 小時的週期表提供額外機會,若先前嘗試失敗或裝置仍開機未重新啟動,則可重新嘗試更新。 此設計有助於確保進展,無需人工介入。
AvailableUpdates 登錄檔位元遮罩
Secure-Boot-Update 任務由 AvailableUpdates 登錄檔值驅動。 此值為位於以下位置的 32 位元遮罩:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecureBoot
值中的每個位元代表特定的安全開機更新動作。 更新過程從 AvailableUpdates 被設定為非零值開始,這可能是 Windows 自動執行,或是管理員明確執行。 例如,像 0x5944 這樣的值表示多個更新動作正在待處理。
當 Secure-Boot-Update 任務執行時,會將這些位元解讀為待處理工作,並依照定義順序處理。
連續更新、記錄與重審行為
安全開機憑證更新會以固定順序套用。 每個更新動作都設計得安全可重試,且會獨立完成。 Secure-Boot-Update 任務在當前動作成功且其對應位元從 AvailableUpdates 中清除後才會進入下一步。
每個操作都使用標準 UEFI 介面來更新安全開機變數,如資料庫和 KEK,或安裝更新後的 Windows 開機管理器。 Windows 會在系統事件日誌中記錄每一步的結果。 成功事件確認前進進度,失敗事件則表示為何無法完成某個動作。
若更新步驟失敗,任務會停止處理,記錄錯誤,並保留相關位元設定。 該操作會在下一次任務執行時重試。 這種重審行為讓裝置能自動從暫時狀況中恢復,例如缺乏韌體支援或 OEM 更新延遲。
管理員可以透過將登錄狀態與事件日誌條目相關聯來追蹤進度。 登錄檔值如 UEFICA2023Status、 UEFICA2023Error 及 UEFICA2023ErrorEvent,連同 AvailableUpdates 位元遮罩,指示哪一步為有效、已完成或被阻擋。
此組合顯示裝置是否正常進行、重試操作或停滯。
與原廠韌體整合
安全開機憑證更新取決於裝置 UEFI 韌體的正確行為與支援。 當 Windows 協調更新過程時,韌體負責執行安全開機政策並維護安全開機資料庫。
OEM 提供兩個關鍵元素以實現安全開機憑證服務:
-
平台金鑰簽署的金鑰交換金鑰 (KEKs) 授權安裝新的安全開機憑證。
-
韌體實作能在更新時正確保存、附加並驗證安全開機資料庫。
如果韌體無法完全支援這些行為,安全開機更新可能會停滯、無限期重試,甚至導致開機失敗。 在這些情況下,Windows 無法在不修改韌體的情況下完成更新。
Microsoft 與 OEM 合作,識別韌體問題並提供修正更新。 當故障排除顯示韌體有限制或缺陷時,管理員可能需要安裝裝置製造商提供的最新 UEFI 韌體更新,才能成功完成安全開機憑證更新。
常見的失效情境與解決方法
安全開機更新由 Secure-Boot-Update 排程任務根據 AvailableUpdates 登錄檔狀態執行。
在正常情況下,這些步驟會自動進行,並在每個階段完成時記錄成功事件。 在某些情況下,韌體行為、平台設定或維護前置條件可能阻礙進度或導致意外開機行為。
以下章節說明最常見的故障情境、如何辨識、發生原因,以及恢復正常運作的適當後續步驟。 情境依據最常見到嚴重的開機影響情況排序。
當安全開機更新沒有進展時,通常代表更新流程從未開始。 因此,預期的安全開機登錄值與事件日誌都遺失,因為更新機制從未被觸發。
發生了什麼事
安全開機更新程序未啟動,因此裝置未套用安全開機憑證或更新的開機管理器。
如何辨識它
-
沒有安全開機服務登錄檔值,例如 UEFICA2023Status。
-
預期的安全啟動事件 (例如 1043、1044、1045、1799、1801) ,系統事件日誌中缺少。
-
裝置仍使用舊有的安全開機憑證與開機元件。
為什麼會這樣
此情境通常發生於以下一項或多項條件成立時:
-
安全開機更新排程任務被停用或缺失。
-
UEFI 韌體中已停用安全開機。
-
該裝置不符合 Windows 維護的先決條件,例如必須執行支援的 Windows 版本或安裝必要的更新。
接下來該怎麼辦
-
確認裝置符合 Windows 維護及平台資格要求。
-
確認韌體中有啟用安全開機。
-
確保 SecureBootUpdate 排程任務存在且已啟用。
如果排程任務被停用或缺失,請依照 安全開機中的指示「排程任務已停用或刪除 」來恢復。 任務恢復後,重新啟動裝置或手動執行任務以啟動安全開機服務。
在某些情況下,與安全開機相關的更新可能導致裝置進入 BitLocker 復原。 這種行為可以是短暫的,也可以是持續性的,取決於根本原因。
情境一:安全開機更新後一次性 BitLocker 復原
發生了什麼事
裝置在安全開機更新後的第一次開機時進入 BitLocker 復原,但在後續重啟時則正常開機。
為什麼會這樣
更新後第一次開機時,韌體尚未回報更新後的安全開機值,當 Windows 嘗試重新封印 BitLocker 時。 這會導致暫時性的開機值不匹配,並觸發復原。 下一次開機時,韌體正確回報更新值,BitLocker 成功重新封存,問題也不會再發生。
如何辨識它
-
BitLocker 恢復只發生一次。
-
輸入恢復金鑰後,後續開機都不會提示恢復。
-
目前沒有持續的啟動訂單或PXE介入。
接下來該怎麼辦
-
輸入 BitLocker 恢復金鑰即可繼續 Windows。
-
檢查韌體更新。
情境二:由於 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 開機管理員視為受信任,並阻擋開機程序。
這種情況並非由安全開機更新本身造成,而是後續韌體動作移除更新的信任錨點所致。
接下來該怎麼辦
-
使用安全開機復原工具還原所需的憑證,讓裝置能重新開機。
-
恢復後,請確保裝置安裝了製造商提供的最新韌體。
-
除非原廠韌體包含更新且信任 2023 年憑證的安全開機預設,否則避免將安全開機重設為韌體預設。
安全開機復原工具
要恢復系統:
-
在第二台安裝 2024 年 7 月或更新 Windows 更新的 Windows 電腦上,從 C:\Windows\Boot\EFI\ 複製 SecureBootRecovery.efi。
-
把檔案放到 FAT32 格式的 USB 隨身碟裡,在 \EFI\BOOT\ 下,並重新命名為 bootx64.efi。
-
從 USB 隨身碟啟動受影響的裝置,讓復原工具繼續執行。 該工具會將 Windows UEFI CA 2023 加入資料庫。
憑證恢復並系統重新啟動後,Windows 應該會正常啟動。
重要: 此程序只會重新套用其中一份新證書。 裝置恢復後,請確保它重新套用最新的憑證,並考慮將系統的 BIOS/UEFI 更新到最新版本。 這有助於防止安全開機重置問題再次發生,因為許多原廠已針對此問題釋出韌體修正。
發生了什麼事
套用安全開機憑證更新並重新啟動後,裝置無法開機,無法進入 Windows。
如何辨識它
-
裝置在安全開機更新後重新啟動後立即失敗。
-
可能會顯示韌體或安全開機錯誤,或系統在 Windows 載入前就停止運作。
-
關閉安全開機可能會讓裝置開機。
為什麼會這樣
這個問題可能是裝置 UEFI 韌體實作有缺陷造成的。
當 Windows 套用安全開機憑證更新時,韌體預期會將新憑證 附加 到現有允許的安全開機簽章資料庫 (資料庫) 。 有些韌體實作錯誤地覆蓋了 資料庫,而不是 附加到資料庫上。
當這種情況發生時,
-
先前受信任的憑證,包括 Microsoft 2011 開機載入者憑證,會被移除。
-
如果系統當時仍在使用以 2011 年憑證簽署的開機管理器,韌體就不再信任它。
-
韌體會拒絕開機管理器並阻擋開機程序。
在某些情況下,資料庫也可能被損壞,而非被乾淨覆蓋,導致相同結果。 這種行為在特定韌體實作中被觀察到,且在合規韌體上並不常見。
接下來該怎麼辦
-
進入韌體設定選單,嘗試重設安全開機設定。
-
如果裝置在重置後仍能開機,請查看裝置製造商的支援網站,尋找修正安全開機資料庫處理的韌體更新。
-
如果有韌體更新,請先安裝,再重新啟用安全開機並重新套用安全開機憑證更新。
如果重置安全開機無法恢復開機功能,進一步的復原可能需要 OEM 專屬的指導。
發生了什麼事
安全啟動憑證更新尚未完成,且仍停留在 KEK) 更新階段 (金鑰交換金鑰。
如何辨識它
-
AvailableUpdates 登錄檔值仍設定為 KEK 位元 (0x0004) ,且不會被清除。
-
UEFICA2023狀態 不會進展到完成狀態。
-
系統事件日誌反覆記錄 事件 ID 1803,表示無法套用 KEK 更新。
-
裝置持續重試更新,卻沒有進展。
為什麼會這樣
更新安全開機 KEK 需要取得裝置平台 金鑰 (PK) 授權,該 PK 由 OEM 擁有。
為了讓更新成功,裝置製造商必須為該特定平台提供 Microsoft 一個 PK 簽署的 KEK 。 此 OEM 簽名的 KEK 包含在 Windows 更新中,允許 Windows 更新韌體中的 KEK 變數。
如果 OEM 沒有提供 PK 簽署的 KEK 給裝置,Windows 就無法完成 KEK 更新。 在此狀態下:
-
安全啟動的更新設計上就是被阻擋的。
-
Windows 無法繞過缺少授權的漏洞。
-
裝置可能永久無法完成安全開機憑證維護。
這種情況可能發生在舊款或已不再支援的裝置上,因為 OEM 不再提供韌體或金鑰更新。 目前沒有支援這種狀況的手動復原路徑。
當安全開機憑證更新未能套用時,Windows 會記錄診斷事件,解釋為何進度被阻擋。 這些事件是在更新安全啟動簽章資料庫 (資料庫) 或金鑰交換金鑰 (KEK時寫入,) 因韌體、平台狀態或組態條件無法安全完成。 本節情境參考這些事件,以識別常見故障模式並決定適當的補救措施。 本節旨在協助診斷與解讀先前所述問題,而非引入新的故障情境。
關於完整的事件 ID、描述及範例條目清單,請參見 安全啟動資料庫與 DBX 變數更新事件 (KB5016061)。
KEK 更新失敗 (資料庫更新成功,KEK 不會)
裝置可以在安全開機資料庫中成功更新憑證,但在 KEK 更新時失敗。 此時安全開機更新程序無法完成。
徵兆
-
DB 證書事件顯示進度,但 KEK 階段尚未完成。
-
AvailableUpdates 仍設為 0x4004,且多次執行任務後0x0004位元仍未被清除。
-
1795年或1803年事件可能存在。
詮釋
-
1795 通常表示在嘗試更新安全開機變數時韌體故障。
-
1803 指出無法授權 KEK 更新,因為該平台無法取得所需的 OEM PK 簽名 KEK 有效載荷。
後續步驟
-
對於 1795 版本,請檢查 OEM 韌體更新並驗證對安全開機變數更新的韌體支援。
-
對於 1803,請確認 OEM 是否已向 Microsoft 提供該裝置型號所需的 PK 簽名 KEK。
在 Hyper-V 上託管的訪客虛擬機上 KEK 更新失敗
在 Hyper-V 虛擬機器上,安全開機憑證更新要求 2026 年 3 月的 Windows 更新同時安裝在 Hyper-V 主機與訪客作業系統上。
更新失敗會 從客戶端內部回報,但事件會指示需要修復的地方:
-
例如,訪客中報告的事件 1795 (「媒體已寫入保護」) 表示 Hyper-V 主機缺少 2026 年 3 月的更新,必須更新。
-
訪客中報告的事件 1803 表示訪客虛擬機本身缺少 2026 年 3 月的更新,必須更新。
參考與內部結構
本節包含進階參考資訊,供故障排除與支援使用。 它不是用來做部署規劃的。 它擴展了先前總結的安全啟動服務機制,並提供詳細的參考資料以解釋登錄狀態與事件日誌。
(IT 管理部署) 請注意:透過 群組原則 或 Microsoft Intune 配置時,兩個相似的設定不應混淆。 AvailableUpdatesPolicy 值代表已設定的政策狀態。 同時, AvailableUpdates 反映的是正在進行的位元清除狀態。 兩者可能帶來相同的結果,但因為政策會隨時間重新適用,行為會有所不同。
用於憑證服務的 AvailableUpdates 位元
以下位元用於本文件中描述的憑證與開機管理員操作。 Order 欄位反映 Secure-Boot-Update 任務處理每個位元的順序。
|
訂單 |
位元設定 |
使用方式 |
|---|---|---|
|
1 |
0x0040 |
此位元指示排程任務將 Windows UEFI CA 2023 憑證加入安全開機資料庫。 這讓 Windows 能夠信任由此憑證簽署的開機管理器。 |
|
2 |
0x0800 |
此位元指示排程任務將 Microsoft Option ROM UEFI CA 2023 套用到 DB。 條件行為 :當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 OPTION ROM UEFI CA 2023。 為了確保裝置的安全設定檔不變,這個位元只有在裝置信任 Microsoft Corporation UEFI CA 2011 憑證時才會套用這些新憑證。 並非所有 Windows 裝置都信任這個憑證。 |
|
4 |
0x0004 |
此位元指示排程任務尋找由裝置平台金鑰 (PK) 簽署的金鑰交換金鑰。 PK由原廠管理。 OEM 會以 Microsoft KEK 的 PK 簽署,並交付給 Microsoft,並納入每月累積更新中。 |
|
5 |
0x0100 |
此位元指示排程任務將由 Windows UEFI CA 2023 簽署的開機管理器套用到開機分割區。 這將取代 Microsoft Windows Production PCA 2011 簽署的開機管理器。 |
注意事項:
-
0x4000位元在處理完畢後仍保持設定。
-
每個位元由安全開機更新排程任務依上述順序處理。
-
如果0x0004位元因缺少 PK 簽名的 KEK 而無法處理,排程任務仍會依位元 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 加入資料庫。 |
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 與安全開機相關說明,了解啟用安全開機的詳細資訊。
安全開機排程任務被停用或刪除
Secure-Boot-Update 排程任務是 Windows 套用安全開機憑證更新所必需的。 如果任務被停用或遺失,安全開機憑證維護將無法進行。
任務細節
|
任務名稱 |
安全啟動更新 |
|
任務路徑 |
\Microsoft\Windows\PI\ |
|
完整路徑 |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
運行列表 |
系統 (地方系統) |
|
觸發程序 |
啟動時及每12小時一次 |
|
必須的州 |
已啟用 |
如何檢查任務狀態
從一個提升的 PowerShell 提示字元執行: schtasks.exe /查詢 /TN “\Microsoft\Windows\PI\Secure-Boot-Update” /FO LIST /V
請注意狀態欄位:
|
狀態 |
意義 |
|---|---|
|
準備好了 |
任務存在且已啟用。 |
|
停用 |
任務存在,但必須啟用。 |
|
錯誤 / 未找到 |
任務缺失,必須重新建立。 |
如何啟用或重現任務
如果 Secure-Boot-Update 的狀態欄位為 Disabled、Error(錯誤)或未找到(Not Found),請使用範例腳本啟用該任務: 範例 Enable-SecureBootUpdateTask.ps1
注意:這只是範例腳本,Microsoft 不支援。 管理員應檢視並調整以適應環境。
範例:
.\Enable-SecureBootUpdateTask.ps1 -安靜
運行指引
-
如果你看到存取被拒絕,請以管理員身份重新執行 PowerShell。
-
若腳本因執行政策無法執行,請使用程序範圍繞過:
Set-ExecutionPolicy -範圍程序 -執行政策繞過