การแก้ไขปัญหา
นำไปใช้กับ
วันที่เผยแพร่ต้นฉบับ: วันที่ 19 มีนาคม 2569
KB ID: 5085046
ในบทความนี้
ภาพรวม
หน้านี้จะแนะนําผู้ดูแลระบบและผู้เชี่ยวชาญฝ่ายสนับสนุนในการวินิจฉัยและแก้ไขปัญหาที่เกี่ยวข้องกับการบูตแบบปลอดภัยบนอุปกรณ์ Windows หัวข้อต่างๆ รวมถึงความล้มเหลวในการอัปเดตใบรับรองการบูตแบบปลอดภัย สถานะการบูตแบบปลอดภัยไม่ถูกต้อง พร้อมท์การกู้คืน BitLocker ที่ไม่คาดคิด และความล้มเหลวในการเริ่มต้นระบบตามการเปลี่ยนแปลงการกําหนดค่าการบูตแบบปลอดภัย
คําแนะนําอธิบายวิธีการตรวจสอบการให้บริการและการกําหนดค่า Windows ตรวจสอบค่ารีจิสทรีที่เกี่ยวข้องและบันทึกเหตุการณ์ และระบุว่าเมื่อใดที่ข้อจํากัดของเฟิร์มแวร์หรือแพลตฟอร์มจําเป็นต้องมีการอัปเดต OEM เนื้อหานี้มีไว้สําหรับการวินิจฉัยปัญหาบนอุปกรณ์ที่มีอยู่ ไม่ได้มีไว้สําหรับการวางแผนการปรับใช้ใหม่ เอกสารนี้จะได้รับการอัปเดตเมื่อมีการระบุสถานการณ์การแก้ไขปัญหาใหม่และคําแนะนํา
การให้บริการใบรับรองการบูตแบบปลอดภัยทํางานอย่างไร
การให้บริการใบรับรองการบูตแบบปลอดภัยบน Windows เป็นกระบวนการที่ประสานกันระหว่างระบบปฏิบัติการและเฟิร์มแวร์ UEFI ของอุปกรณ์ เป้าหมายคือการอัปเดตจุดยึดความน่าเชื่อถือที่สําคัญในขณะที่รักษาความสามารถในการบูตในแต่ละขั้นตอน
กระบวนการถูกขับเคลื่อนโดยงานที่กําหนดเวลาไว้ของ Windows ลําดับการอัปเดตตามรีจิสทรี และลักษณะการทํางานในการบันทึกและลองอีกครั้ง คอมโพเนนต์เหล่านี้จะช่วยให้แน่ใจว่าใบรับรองการบูตแบบปลอดภัยและตัวจัดการการเริ่มต้นระบบของ Windows ได้รับการอัปเดตในลักษณะที่มีการควบคุม เรียงลําดับ และหลังจากขั้นตอนข้อกําหนดเบื้องต้นสําเร็จเท่านั้น
จะเริ่มต้นที่ใดเมื่อแก้ไขปัญหา
เมื่ออุปกรณ์ไม่ปรากฏว่ากําลังดําเนินการตามที่คาดไว้โดยใช้การอัปเดตใบรับรองการบูตแบบปลอดภัย ให้เริ่มต้นด้วยการระบุประเภทของปัญหา ปัญหาส่วนใหญ่จะอยู่ในส่วนหนึ่งในสี่ส่วน ได้แก่ สถานะการให้บริการของ Windows กลไกการอัปเดตการบูตแบบปลอดภัย ลักษณะการทํางานของเฟิร์มแวร์ หรือข้อจํากัดของแพลตฟอร์มหรือ OEM
เริ่มต้นด้วยการตรวจสอบด้านล่างตามลําดับ ในหลายกรณี ขั้นตอนเหล่านี้เพียงพอที่จะอธิบายลักษณะการทํางานที่สังเกตได้ และกําหนดการดําเนินการถัดไปโดยไม่ต้องตรวจสอบอย่างละเอียด
-
ยืนยันการได้รับบริการของ Windows และสิทธิ์ของแพลตฟอร์ม
-
ตรวจสอบว่าอุปกรณ์มีคุณสมบัติตรงตามข้อกําหนดพื้นฐานในการรับการอัปเดตใบรับรองการบูตแบบปลอดภัย:
-
อุปกรณ์กําลังใช้งาน Windows เวอร์ชันที่ได้รับการสนับสนุน
-
มีการติดตั้งการอัปเดตความปลอดภัยของ Windows ที่จําเป็นล่าสุด
-
การบูตแบบปลอดภัยถูกเปิดใช้งานในเฟิร์มแวร์ UEFI
-
หากไม่ตรงตามเงื่อนไขเหล่านี้ ให้แก้ไขก่อนดําเนินการต่อด้วยการแก้ไขปัญหาเพิ่มเติม
-
-
ตรวจสอบสถานะงาน Secure-Boot-Update
-
ยืนยันว่ากลไกของ Windows ที่รับผิดชอบในการใช้การอัปเดตใบรับรองการบูตแบบปลอดภัยมีอยู่และทํางาน:
-
มีงานตามกําหนดการ Secure-Boot-Update
-
งานถูกเปิดใช้งานและรันเป็นระบบภายในเครื่อง
-
งานนี้ทํางานอย่างน้อยหนึ่งครั้งตั้งแต่มีการติดตั้งการอัปเดตความปลอดภัยของ Windows ล่าสุด
-
ถ้างานถูกปิดใช้งาน ลบ หรือไม่ทํางาน อยู่ คุณจะไม่สามารถนําการอัปเดตใบรับรองการบูตแบบปลอดภัยไปใช้ได้ การแก้ไขปัญหาควรมุ่งเน้นไปที่การคืนค่างานก่อนที่จะตรวจสอบสาเหตุอื่นๆ
-
-
ตรวจสอบการตั้งค่ารีจิสทรีสําหรับความคืบหน้าที่คาดไว้
ตรวจสอบสถานะการให้บริการ Secure Boot ของอุปกรณ์ในรีจิสทรี:
-
ตรวจสอบ UEFICA2023Status, UEFICA2023Error และ UEFICA2023ErrorEvent
-
ตรวจสอบ AvailableUpdates และเปรียบเทียบกับความคืบหน้าที่คาดไว้ (ดู การอ้างอิงและภายใน)
เมื่ออยู่ด้วยกัน ค่าเหล่านี้จะระบุว่าการให้บริการกําลังดําเนินอยู่ตามปกติ ลองดําเนินการใหม่ หรือหยุดดําเนินการในขั้นตอนใดขั้นตอนหนึ่งหรือไม่
-
-
เชื่อมโยงสถานะรีจิสทรีกับเหตุการณ์การบูตแบบปลอดภัย
ตรวจสอบเหตุการณ์ที่เกี่ยวข้องกับการบูตแบบปลอดภัยในบันทึกเหตุการณ์ของระบบและเชื่อมโยงกับสถานะรีจิสทรี โดยทั่วไปข้อมูลเหตุการณ์จะยืนยันว่าอุปกรณ์กําลังดําเนินการไปข้างหน้า ลองใหม่เนื่องจากเงื่อนไขชั่วคราว หรือถูกบล็อกโดยปัญหาเฟิร์มแวร์หรือแพลตฟอร์ม
โดยปกติแล้วรีจิสตรีและบันทึกเหตุการณ์จะระบุว่าการทํางานเป็นไปอย่างที่คาดไว้ ชั่วคราว หรือต้องดําเนินการแก้ไข
งานตามกําหนดการของ Secure-Boot-Update
การให้บริการใบรับรองการบูตแบบปลอดภัยจะดําเนินการผ่านงานตามกําหนดการของ Windows ที่ชื่อ Secure-Boot-Update งานถูกลงทะเบียนที่เส้นทางต่อไปนี้:
\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 ทํางาน จะแปลบิตชุดเป็นงานที่ค้างอยู่และประมวลผลตามลําดับที่กําหนดไว้
การอัปเดตการบันทึก และลักษณะการทํางานใหม่ตามลําดับ
การอัปเดตใบรับรองการบูตแบบปลอดภัยจะถูกนําไปใช้ในลําดับที่แน่นอน การดําเนินการอัปเดตแต่ละรายการได้รับการออกแบบให้ปลอดภัยในการลองใหม่และดําเนินการให้เสร็จสมบูรณ์ได้อย่างอิสระ งานการอัปเดตการบูตแบบปลอดภัยจะไม่ไปยังขั้นตอนถัดไปจนกว่าการดําเนินการปัจจุบันจะสําเร็จ และบิตที่สอดคล้องกันจะถูกล้างออกจาก AvailableUpdates
การดําเนินการแต่ละอย่างจะใช้ส่วนติดต่อ UEFI มาตรฐานเพื่ออัปเดตตัวแปร Secure Boot เช่น DB และ KEK หรือติดตั้งตัวจัดการการบูตของ Windows ที่อัปเดตแล้ว Windows จะบันทึกผลลัพธ์ของทุกขั้นตอนในบันทึกเหตุการณ์ของระบบ เหตุการณ์ที่สําเร็จจะยืนยันความคืบหน้าไปข้างหน้า ขณะที่เหตุการณ์ความล้มเหลวระบุสาเหตุที่ไม่สามารถดําเนินการให้เสร็จสมบูรณ์ได้
ถ้าขั้นตอนการอัปเดตล้มเหลว งานหยุดการประมวลผล จะบันทึกข้อผิดพลาด และปล่อยชุดบิตที่เกี่ยวข้องไว้ การดําเนินการจะถูกลองใหม่ในครั้งถัดไปที่เรียกใช้งาน ลักษณะการทํางานใหม่นี้ช่วยให้อุปกรณ์สามารถกู้คืนโดยอัตโนมัติจากเงื่อนไขชั่วคราว เช่น การสนับสนุนเฟิร์มแวร์ที่ขาดหายไปหรือการอัปเดต OEM ล่าช้า
ผู้ดูแลระบบสามารถติดตามความคืบหน้าโดยการเชื่อมโยงสถานะรีจิสทรีกับรายการบันทึกเหตุการณ์ ค่ารีจิสทรี เช่น UEFICA2023Status, UEFICA2023Error และ UEFICA2023ErrorEvent พร้อมกับบิตมา สก์ AvailableUpdates ระบุขั้นตอนที่ใช้งานอยู่ เสร็จสมบูรณ์ หรือถูกบล็อก
การผสมนี้แสดงให้เห็นว่าอุปกรณ์กําลังคืบหน้าตามปกติ กําลังดําเนินการใหม่ หรือหยุดทํางานหรือไม่
การรวมกับเฟิร์มแวร์ OEM
การอัปเดตใบรับรองการบูตแบบปลอดภัยจะขึ้นอยู่กับลักษณะการทํางานที่ถูกต้องและการสนับสนุนในเฟิร์มแวร์ UEFI ของอุปกรณ์ ในขณะที่ Windows ประมวลผลกระบวนการอัปเดต เฟิร์มแวร์จะรับผิดชอบในการบังคับใช้นโยบายการบูตแบบปลอดภัย และการรักษาฐานข้อมูล Secure Boot
OEM มีองค์ประกอบสําคัญสองอย่างที่เปิดใช้งานการให้บริการใบรับรองการบูตแบบปลอดภัย ได้แก่
-
คีย์แพลตฟอร์มคีย์ที่มีลายเซ็นคีย์ Exchange (KEK) ที่อนุญาตการติดตั้งใบรับรองการบูตแบบปลอดภัยใหม่
-
การใช้งานเฟิร์มแวร์ที่จัดเก็บ ผนวก และตรวจสอบความถูกต้องของฐานข้อมูล Secure Boot อย่างถูกต้องระหว่างการอัปเดต
หากเฟิร์มแวร์ไม่สนับสนุนลักษณะการทํางานเหล่านี้อย่างสมบูรณ์ การอัปเดตการบูตแบบปลอดภัยอาจหยุดทํางาน ลองใหม่โดยไม่มีกําหนด หรือส่งผลให้การเริ่มต้นระบบล้มเหลว ในกรณีเหล่านี้ Windows ไม่สามารถทําการอัปเดตให้เสร็จสมบูรณ์ได้โดยไม่มีการเปลี่ยนแปลงเฟิร์มแวร์
Microsoft ทํางานร่วมกับ OEM เพื่อระบุปัญหาเฟิร์มแวร์และทําให้การอัปเดตที่แก้ไขพร้อมใช้งาน เมื่อการแก้ไขปัญหาระบุถึงข้อจํากัดหรือข้อบกพร่องของเฟิร์มแวร์ ผู้ดูแลระบบอาจจําเป็นต้องติดตั้งการอัปเดตเฟิร์มแวร์ UEFI ล่าสุดที่ผู้ผลิตอุปกรณ์ให้ไว้ก่อนที่การอัปเดตใบรับรองการบูตแบบปลอดภัยจะเสร็จสมบูรณ์
สถานการณ์และวิธีแก้ปัญหาความล้มเหลวทั่วไป
การอัปเดตการบูตแบบปลอดภัยจะถูกนําไปใช้โดยงานที่จัดกําหนดการไว้ใน Secure-Boot-Update ตามสถานะรีจิสทรี AvailableUpdates
ภายใต้เงื่อนไขปกติ ขั้นตอนเหล่านี้จะเกิดขึ้นโดยอัตโนมัติ และบันทึกเหตุการณ์ที่สําเร็จเมื่อแต่ละขั้นตอนเสร็จสมบูรณ์ ในบางกรณี ลักษณะการทํางานของเฟิร์มแวร์ การกําหนดค่าแพลตฟอร์ม หรือข้อกําหนดเบื้องต้นในการให้บริการสามารถป้องกันความคืบหน้าหรือนําไปสู่ลักษณะการทํางานที่ไม่คาดคิดในการเริ่มต้นระบบ
ส่วนด้านล่างนี้อธิบายสถานการณ์ความล้มเหลวทั่วไปวิธีการจดจําสาเหตุที่เกิดขึ้น และขั้นตอนถัดไปที่เหมาะสมเพื่อคืนค่าการดําเนินการปกติ สถานการณ์ได้รับการสั่งซื้อจากกรณีที่มักพบบ่อยที่สุดสําหรับกรณีที่มีผลกระทบกับการบูตที่รุนแรงมากขึ้น
เมื่อการอัปเดตการบูตแบบปลอดภัยไม่แสดงความคืบหน้า โดยทั่วไปจะหมายความว่ากระบวนการอัปเดตไม่เคยเริ่มทํางาน ดังนั้น ค่ารีจิสทรีการบูตแบบปลอดภัยที่คาดไว้และบันทึกเหตุการณ์จึงหายไปเนื่องจากระบบการอัปเดตไม่เคยถูกทริกเกอร์
เกิดอะไรขึ้น
กระบวนการอัปเดตการบูตแบบปลอดภัยไม่เริ่มทํางาน ดังนั้นจะไม่มีการนําใบรับรองการบูตแบบปลอดภัยหรือตัวจัดการการบูตแบบอัปเดตไปใช้กับอุปกรณ์
วิธีการรับรู้
-
ไม่มีค่ารีจิสทรีของบริการ Secure Boot เช่น UEFICA2023Status
-
เหตุการณ์การบูตแบบปลอดภัยที่คาดไว้ (ตัวอย่างเช่น 1043, 1044, 1045, 1799, 1801) หายไปจากบันทึกเหตุการณ์ของระบบ
-
อุปกรณ์ยังคงใช้ใบรับรองการบูตแบบปลอดภัยรุ่นเก่าและคอมโพเนนต์การบูตต่อไป
ทําไมจึงเกิดขึ้น
โดยปกติแล้ว เหตุการณ์นี้จะเกิดขึ้นเมื่อเงื่อนไขอย่างน้อยหนึ่งข้อต่อไปนี้เป็นจริง:
-
งานตามกําหนดการ Secure-Boot-Update ถูกปิดใช้งานหรือขาดหายไป
-
การบูตแบบปลอดภัยถูกปิดใช้งานในเฟิร์มแวร์ UEFI
-
อุปกรณ์ไม่ตรงตามข้อกําหนดเบื้องต้นในการให้บริการของ Windows เช่น การเรียกใช้ Windows เวอร์ชันที่สนับสนุน หรือมีการติดตั้งการอัปเดตที่จําเป็น
สิ่งที่ต้องทําถัดไป
-
ตรวจสอบว่าอุปกรณ์มีคุณสมบัติตรงตามข้อกําหนดด้านสิทธิ์ของบริการและแพลตฟอร์ม Windows
-
ยืนยันว่าการบูตแบบปลอดภัยเปิดใช้งานในเฟิร์มแวร์แล้ว
-
ตรวจสอบให้แน่ใจว่ามีงานที่กําหนดเวลา ไว้ SecureBootUpdate และเปิดใช้งานอยู่
หากงานที่กําหนดเวลาไว้ถูกปิดใช้งานหรือขาดหายไป ทําตามคําแนะนําใน งานที่กําหนดเวลาไว้ของการบูตแบบปลอดภัยถูกปิดใช้งานหรือลบ ออกเพื่อคืนค่า หลังจากคืนค่างานแล้ว ให้เริ่มการทํางานของอุปกรณ์ใหม่หรือเรียกใช้งานด้วยตนเองเพื่อเริ่มต้นบริการการบูตแบบปลอดภัย
ในบางกรณี การอัปเดตที่เกี่ยวข้องกับการบูตแบบปลอดภัยอาจทําให้อุปกรณ์เข้าสู่การกู้คืน BitLocker พฤติกรรมอาจเป็นชั่วคราวหรือถาวรขึ้นอยู่กับสาเหตุพื้นฐาน
สถานการณ์ที่ 1: การกู้คืน BitLocker ครั้งเดียวหลังจากการอัปเดตการบูตแบบปลอดภัย
สิ่งที่เกิดขึ้น
อุปกรณ์เข้าสู่การกู้คืน BitLocker ในการเริ่มต้นระบบครั้งแรกหลังจากการอัปเดตการบูตแบบปลอดภัย แต่โดยปกติแล้วเริ่มต้นระบบใหม่ในภายหลัง
ทําไมจึงเกิดขึ้น
ในระหว่างการเริ่มต้นระบบครั้งแรกหลังจากการอัปเดต เฟิร์มแวร์ยังไม่รายงานค่าการบูตแบบปลอดภัยที่อัปเดตเมื่อ Windows พยายามแก้ไข BitLocker อีกครั้ง ซึ่งทําให้ค่าการบูตที่วัดได้ไม่ตรงกันชั่วคราวและทริกเกอร์การกู้คืน ในการเริ่มต้นระบบครั้งถัดไป เฟิร์มแวร์จะรายงานค่าที่อัปเดตอย่างถูกต้อง จะมีการขาย BitLocker ใหม่อีกครั้งได้สําเร็จ และปัญหาไม่เกิดขึ้นซ้ํา
วิธีการรับรู้
-
การกู้คืน BitLocker จะเกิดขึ้นหนึ่งครั้ง
-
หลังจากป้อนคีย์การกู้คืน การบูตที่ตามมาจะไม่แสดงพร้อมท์ในการกู้คืน
-
ไม่มีลําดับการบูตอย่างต่อเนื่องหรือการเข้าร่วม PXE
สิ่งที่ต้องทําถัดไป
-
ป้อนคีย์การกู้คืน BitLocker เพื่อดําเนินการ Windows ต่อ
-
ตรวจหาการอัปเดตเฟิร์มแวร์
สถานการณ์ที่ 2: การกู้คืน BitLocker ซ้ําๆ เนื่องจากการกําหนดค่าการเริ่มต้นระบบครั้งแรกของ PXE
สิ่งที่เกิดขึ้น
อุปกรณ์เข้าสู่การกู้คืน BitLocker ในการบูตทุกครั้ง
ทําไมจึงเกิดขึ้น
อุปกรณ์ได้รับการกําหนดค่าให้พยายามเริ่มต้นระบบ PXE (เครือข่าย) ก่อน ความพยายามในการบูต PXE ล้มเหลว และเฟิร์มแวร์จะย้อนกลับไปยังตัวจัดการการบูต Windows บนดิสก์
ซึ่งส่งผลให้ มีการวัดผู้มีอํานาจลงนามที่แตกต่างกันสองรายในระหว่างรอบการบูตเครื่องเดียว:
-
เส้นทางการเริ่มต้นระบบ PXE ได้รับการเซ็นชื่อโดย Microsoft UEFI CA 2011
-
ตัวจัดการการเริ่มต้นระบบ Windows บนดิสก์ได้รับการเซ็นชื่อโดย Windows UEFI CA 2023
เนื่องจาก BitLocker สังเกตโซ่ความน่าเชื่อถือของ Secure Boot ที่แตกต่างกันระหว่างการเริ่มต้นระบบ จึงไม่สามารถสร้างชุดการวัด TPM ที่เสถียรเพื่อนํากลับมาตรวจสอบอีกครั้งได้ ดังนั้น BitLocker จะเข้าสู่การกู้คืนในการบูตทุกครั้ง
วิธีการรับรู้
-
การกู้คืน BitLocker จะถูกทริกเกอร์เมื่อเริ่มระบบใหม่ทุกครั้ง
-
การป้อนคีย์การกู้คืนช่วยให้ Windows เริ่มต้นระบบได้ แต่พร้อมท์จะส่งคืนในการเริ่มต้นระบบครั้งถัดไป
-
PXE หรือการบูตเครือข่ายได้รับการกําหนดค่าล่วงหน้าของดิสก์ภายในเครื่องในลําดับการบูตเฟิร์มแวร์
สิ่งที่ต้องทําถัดไป
-
กําหนดค่าลําดับการบูตเฟิร์มแวร์ เพื่อให้ตัวจัดการการเริ่มต้นระบบ Windows บนดิสก์เป็นอันดับแรก
-
ปิดใช้งานการบูตแบบ PXE หากไม่จําเป็น
-
หากจําเป็นต้องใช้ PXE ตรวจสอบให้แน่ใจว่าโครงสร้างพื้นฐาน PXE ใช้ตัวโหลดการบูตของ Windows ที่ได้รับการรับรอง 2023
เกิดอะไรขึ้น
ซึ่งสะท้อนถึงการเปลี่ยนแปลงระดับเฟิร์มแวร์แทนที่จะเป็นปัญหาของ Windows การอัปเดตการบูตแบบปลอดภัยเสร็จสมบูรณ์ แต่หลังจากเริ่มระบบใหม่ในภายหลัง อุปกรณ์ไม่เริ่มต้นระบบใน Windows อีกต่อไป
วิธีการรับรู้
-
อุปกรณ์ไม่สามารถเริ่ม Windows และอาจแสดงข้อความเฟิร์มแวร์หรือ BIOS ที่ระบุการละเมิดการบูตแบบปลอดภัย
-
ความล้มเหลวเกิดขึ้นหลังจากการตั้งค่าการบูตแบบปลอดภัยถูกรีเซ็ตเป็นค่าเริ่มต้นของเฟิร์มแวร์
-
การปิดใช้งานการบูตแบบปลอดภัยอาจทําให้อุปกรณ์เริ่มต้นระบบอีกครั้ง
ทําไมจึงเกิดขึ้น
การรีเซ็ตการบูตแบบปลอดภัยเป็นค่าเริ่มต้นของเฟิร์มแวร์จะล้างฐานข้อมูล Secure Boot ที่เก็บไว้ในเฟิร์มแวร์ บนอุปกรณ์ที่เปลี่ยนเป็นตัวจัดการการเริ่มต้นระบบที่ลงชื่อด้วย Windows UEFI CA 2023 อยู่แล้ว การรีเซ็ตนี้จะลบใบรับรองที่จําเป็นในการเชื่อถือตัวจัดการการเริ่มต้นระบบนั้น
ด้วยเหตุนี้ เฟิร์มแวร์จึงไม่รู้จักตัวจัดการการเริ่มต้นระบบของ Windows ที่ติดตั้งไว้เป็นเชื่อถือได้และบล็อกกระบวนการเริ่มต้นระบบอีกต่อไป
สถานการณ์นี้ไม่ได้เกิดจากการอัปเดต Secure Boot แต่เกิดจากการดําเนินการเฟิร์มแวร์ที่ตามมาที่ลบจุดยึดความน่าเชื่อถือที่อัปเดตแล้ว
สิ่งที่ต้องทําถัดไป
-
ใช้โปรแกรมอรรถประโยชน์การกู้คืนการบูตแบบปลอดภัยเพื่อคืนค่าใบรับรองที่จําเป็น เพื่อให้อุปกรณ์สามารถเริ่มต้นระบบได้อีกครั้ง
-
หลังจากการกู้คืน ตรวจสอบให้แน่ใจว่าอุปกรณ์มีเฟิร์มแวร์ล่าสุดที่พร้อมใช้งานติดตั้งจากผู้ผลิตอุปกรณ์
-
หลีกเลี่ยงการรีเซ็ตการบูตแบบปลอดภัยเป็นค่าเริ่มต้นของเฟิร์มแวร์ เว้นแต่ว่าเฟิร์มแวร์ OEM จะมีค่าเริ่มต้นการบูตแบบปลอดภัยที่ได้รับการอัปเดตที่เชื่อถือใบรับรอง 2023
โปรแกรมอรรถประโยชน์การกู้คืนการบูตแบบปลอดภัย
เมื่อต้องการกู้คืนระบบ:
-
บนพีซี Windows เครื่องที่สองที่ติดตั้งการอัปเดต Windows เดือนกรกฎาคม 2024 หรือใหม่กว่า ให้คัดลอก SecureBootRecovery.efi จาก C:\Windows\Boot\EFI\
-
วางไฟล์ในไดรฟ์ USB ที่ฟอร์แมต FAT32 ภายใต้ \EFI\BOOT\ และเปลี่ยนชื่อเป็น bootx64.efi
-
บูตอุปกรณ์ที่ได้รับผลกระทบจากไดรฟ์ USB และอนุญาตให้โปรแกรมอรรถประโยชน์การกู้คืนทํางาน โปรแกรมอรรถประโยชน์จะเพิ่ม Windows UEFI CA 2023 ลงใน DB
หลังจากคืนค่าใบรับรองและเริ่มระบบใหม่ Windows ควรเริ่มต้นตามปกติ
สำคัญ: กระบวนการนี้จะนําใบรับรองใหม่มาใช้ใหม่เพียงรายการเดียวเท่านั้น เมื่ออุปกรณ์ได้รับการกู้คืน ตรวจสอบให้แน่ใจว่ามีการนําใบรับรองล่าสุดมาใช้ใหม่ และพิจารณาอัปเดต BIOS/UEFI ของระบบเป็นเวอร์ชันใหม่ล่าสุดที่พร้อมใช้งาน ซึ่งสามารถช่วยป้องกันการเกิดซ้ําของปัญหาการรีเซ็ตการบูตแบบปลอดภัย เนื่องจาก OEM จํานวนมากได้เผยแพร่การแก้ไขเฟิร์มแวร์สําหรับปัญหานี้
เกิดอะไรขึ้น
หลังจากใช้การอัปเดตใบรับรองการบูตแบบปลอดภัยและเริ่มระบบใหม่แล้ว อุปกรณ์ไม่สามารถเริ่มต้นระบบได้และไม่ถึง Windows
วิธีการรับรู้
-
อุปกรณ์ล้มเหลวทันทีหลังจากการเริ่มระบบใหม่ที่จําเป็นโดยการอัปเดตการบูตแบบปลอดภัย
-
อาจแสดงข้อผิดพลาดของเฟิร์มแวร์หรือการบูตแบบปลอดภัย หรือระบบอาจหยุดทํางานก่อนที่ Windows จะโหลด
-
การปิดใช้งานการบูตแบบปลอดภัยอาจทําให้อุปกรณ์เริ่มต้นระบบได้
ทําไมจึงเกิดขึ้น
ปัญหานี้อาจมีสาเหตุจากข้อบกพร่องในการใช้งานเฟิร์มแวร์ UEFI ของอุปกรณ์
เมื่อ Windows ใช้การอัปเดตใบรับรองการบูตแบบปลอดภัย เฟิร์มแวร์คาดว่าจะ ผนวก ใบรับรองใหม่เข้ากับฐานข้อมูลลายเซ็นที่อนุญาตการบูตแบบปลอดภัย (DB) ที่มีอยู่ การใช้งานเฟิร์มแวร์บางรายการ จะเขียนทับ DB อย่างไม่ถูกต้องแทนที่จะผนวกเข้ากับ DB
เมื่อเกิดกรณีนี้ขึ้น
-
ใบรับรองที่เชื่อถือได้ก่อนหน้านี้ รวมถึงใบรับรอง Bootloader ของ Microsoft 2011 จะถูกเอาออก
-
หากระบบยังคงใช้ตัวจัดการการบูตที่ลงนามด้วยใบรับรอง 2011 ณ จุดนั้น เฟิร์มแวร์จะไม่เชื่อถืออีกต่อไป
-
เฟิร์มแวร์ปฏิเสธตัวจัดการการเริ่มต้นระบบและบล็อกกระบวนการเริ่มต้นระบบ
ในบางกรณี DB อาจเสียหายแทนที่จะเขียนทับอย่างสมบูรณ์ ซึ่งนําไปสู่ผลลัพธ์เดียวกัน ลักษณะการทํางานนี้พบได้ในการใช้งานเฟิร์มแวร์เฉพาะ และไม่ได้คาดไว้บนเฟิร์มแวร์ที่เข้ากันได้
สิ่งที่ต้องทําถัดไป
-
ป้อนเมนูการตั้งค่าเฟิร์มแวร์และพยายามรีเซ็ตการตั้งค่าการบูตแบบปลอดภัย
-
หากอุปกรณ์เริ่มต้นระบบหลังจากการรีเซ็ต ให้ตรวจสอบไซต์สนับสนุนของผู้ผลิตอุปกรณ์สําหรับการอัปเดตเฟิร์มแวร์ที่แก้ไขการจัดการ Secure Boot DB
-
หากมีการอัปเดตเฟิร์มแวร์ให้ติดตั้งก่อนเปิดใช้งานการบูตแบบปลอดภัยอีกครั้งและนําการอัปเดตใบรับรองการบูตแบบปลอดภัยไปใช้ใหม่
หากการรีเซ็ตการบูตแบบปลอดภัยไม่คืนค่าฟังก์ชันการบูต การกู้คืนเพิ่มเติมอาจต้องใช้คําแนะนําเฉพาะสําหรับ OEM
เกิดอะไรขึ้น
การอัปเดตใบรับรองการบูตแบบปลอดภัยไม่เสร็จสมบูรณ์และยังคงถูกบล็อกในขั้นตอนการอัปเดตคีย์คีย์ Exchange (KEK)
วิธีการรับรู้
-
ค่ารีจิสทรี AvailableUpdates ยังคงตั้งค่าด้วยบิต KEK (0x0004) และไม่ถูกล้าง
-
UEFICA2023Status ไม่คืบหน้าสู่สถานะเสร็จสมบูรณ์
-
บันทึกเหตุการณ์ของระบบจะบันทึก รหัสเหตุการณ์ 1803 ซ้ําๆ ซึ่งระบุว่าไม่สามารถนําการอัปเดต KEK ไปใช้ได้
-
อุปกรณ์ยังคงพยายามทําการอัปเดตอีกครั้งโดยไม่ดําเนินการต่อไป
ทําไมจึงเกิดขึ้น
การอัปเดต Secure Boot KEK ต้องได้รับอนุญาตจาก Platform Key (PK) ของอุปกรณ์ซึ่งเป็นของ OEM
เพื่อให้การอัปเดตประสบความสําเร็จ ผู้ผลิตอุปกรณ์จะต้องให้ KEK ที่ลงนามกับ Microsoft สําหรับแพลตฟอร์มดังกล่าว KEK ที่ลงนามโดย OEM นี้รวมอยู่ในการอัปเดต Windows และช่วยให้ Windows อัปเดตตัวแปร KEK ของเฟิร์มแวร์ได้
หาก OEM ไม่ได้ให้ KEK ที่ลงนามด้วย PK สําหรับอุปกรณ์ดังกล่าว Windows จะไม่สามารถดําเนินการอัปเดต KEK ให้เสร็จสมบูรณ์ได้ ในสถานะนี้:
-
การอัปเดตการบูตแบบปลอดภัยถูกบล็อกตามการออกแบบ
-
Windows ไม่สามารถแก้ไขปัญหาเกี่ยวกับการรับรองความถูกต้องที่หายไปได้
-
อุปกรณ์ยังคงไม่สามารถให้บริการใบรับรองการบูตแบบปลอดภัยให้เสร็จสมบูรณ์ได้
ปัญหานี้อาจเกิดขึ้นได้บนอุปกรณ์รุ่นเก่าหรืออุปกรณ์ที่ไม่อยู่ในการสนับสนุนที่ OEM ไม่ได้ให้การอัปเดตเฟิร์มแวร์หรือคีย์อีกต่อไป ไม่มีเส้นทางการกู้คืนด้วยตนเองที่ได้รับการสนับสนุนสําหรับเงื่อนไขนี้
เมื่อการนําการอัปเดตใบรับรองการบูตแบบปลอดภัยไปใช้ไม่ได้ Windows จะบันทึกเหตุการณ์การวินิจฉัยที่อธิบายว่าเหตุใดความคืบหน้าจึงถูกบล็อก เหตุการณ์เหล่านี้จะถูกเขียนขึ้นเมื่ออัปเดตฐานข้อมูลลายเซ็นการบูตแบบปลอดภัย (DB) หรือ Key Exchange Key (KEK) ไม่สามารถดําเนินการให้เสร็จสมบูรณ์ได้อย่างปลอดภัยเนื่องจากเฟิร์มแวร์ สถานะแพลตฟอร์ม หรือเงื่อนไขการกําหนดค่า สถานการณ์สมมติในส่วนนี้อ้างอิงเหตุการณ์เหล่านี้เพื่อระบุรูปแบบความล้มเหลวทั่วไป และกําหนดการแก้ไขที่เหมาะสม ส่วนนี้มีวัตถุประสงค์เพื่อสนับสนุนการวินิจฉัยและการตีความของปัญหาที่อธิบายไว้ก่อนหน้านี้
สําหรับรายการทั้งหมดของรหัสเหตุการณ์ คําอธิบาย และรายการตัวอย่าง โปรดดู เหตุการณ์การอัปเดตตัวแปร Secure Boot DB และ DBX (KB5016061)
การอัปเดต KEK ล้มเหลว (การอัปเดต DB สําเร็จ KEK ไม่ทํา)
อุปกรณ์สามารถอัปเดตใบรับรองใน DB การบูตแบบปลอดภัยได้สําเร็จ แต่ล้มเหลวระหว่างการอัปเดต KEK เมื่อเกิดกรณีนี้ กระบวนการปรับปรุงการบูตแบบปลอดภัยไม่สามารถเสร็จสมบูรณ์ได้
อาการ
-
เหตุการณ์ใบรับรอง DB ระบุความคืบหน้า แต่ขั้นตอน KEK ไม่เสร็จสมบูรณ์
-
AvailableUpdates ยังคงถูกตั้งค่าเป็น 0x4004 และบิต 0x0004 จะไม่ถูกล้างหลังจากหลายงานทํางาน
-
เหตุการณ์ 1795 หรือ 1803 อาจมีอยู่
ล่าม
-
1795 โดยทั่วไปจะระบุความล้มเหลวของเฟิร์มแวร์ขณะพยายามอัปเดตตัวแปร Secure Boot
-
1803 ระบุว่าการอัปเดต KEK ไม่ได้รับอนุญาตเนื่องจากส่วนข้อมูล KEK ที่ลงนามโดย OEM PK ไม่พร้อมใช้งานสําหรับแพลตฟอร์ม
ขั้นตอนต่อไป
-
สําหรับ 1795 ตรวจสอบการอัปเดตเฟิร์มแวร์ OEM และตรวจสอบความถูกต้องของการสนับสนุนเฟิร์มแวร์สําหรับการอัปเดตตัวแปร Secure Boot
-
สําหรับ 1803 ให้ยืนยันว่า OEM ได้ให้ MICROSOFT กับ KEK ที่ลงนามด้วย PK ที่จําเป็นสําหรับรุ่นอุปกรณ์หรือไม่
การอัปเดต KEK ล้มเหลวบนเครื่องเสมือน Guest ที่โฮสต์บน Hyper-V
บนเครื่องเสมือน Hyper-V การอัปเดตใบรับรองการบูตแบบปลอดภัยจําเป็นต้องติดตั้งการอัปเดต Windows ประจําเดือนมีนาคม 2026 ทั้งในโฮสต์ Hyper-V และระบบปฏิบัติการ Guest
มีการรายงานความล้มเหลว ในการอัปเดตจากภายในผู้เยี่ยมชม แต่เหตุการณ์จะระบุว่าต้องใช้การแก้ไขที่ใด:
-
เหตุการณ์ 1795 (ตัวอย่างเช่น "สื่อมีการป้องกันการเขียน") ที่รายงานใน ผู้เยี่ยมชม ระบุว่า โฮสต์ Hyper-V ไม่มีการอัปเดตประจําเดือนมีนาคม 2026 และต้องได้รับการอัปเดต
-
เหตุการณ์ 1803 ที่รายงานใน ผู้เยี่ยมชม ระบุว่า เครื่องเสมือนแบบผู้เยี่ยมชม ไม่มีการอัปเดตประจําเดือนมีนาคม 2026 และต้องอัปเดต
การอ้างอิงและภายใน
ส่วนนี้ประกอบด้วยข้อมูลอ้างอิงขั้นสูงที่ใช้สําหรับการแก้ไขปัญหาและการสนับสนุน ไม่ได้มีไว้สําหรับการวางแผนการปรับใช้ ซึ่งขยายในกลศาสตร์การให้บริการ Secure Boot ที่สรุปไว้ก่อนหน้านี้ และมีเอกสารอ้างอิงโดยละเอียดสําหรับการแปลสถานะรีจิสทรีและบันทึกเหตุการณ์
หมายเหตุ (การปรับใช้ที่จัดการโดย IT): เมื่อกําหนดค่าผ่านนโยบายกลุ่มหรือ Microsoft Intune ไม่ควรสับสนการตั้งค่าสองอย่างที่คล้ายกัน ค่า AvailableUpdatesPolicy แสดงถึงสถานะนโยบายที่กําหนดค่า ขณะเดียวกัน AvailableUpdates จะแสดงสถานะงานที่กําลังดําเนินการอยู่และกําลังล้างข้อมูลเล็กน้อย ทั้งสองอย่างสามารถผลักดันผลลัพธ์เดียวกัน แต่ทํางานแตกต่างกันเนื่องจากนโยบายนําไปใช้อีกครั้งเมื่อเวลาผ่านไป
บิต AvailableUpdates ที่ใช้สําหรับการให้บริการใบรับรอง
บิตด้านล่างนี้จะใช้สําหรับการดําเนินการของใบรับรองและตัวจัดการการเริ่มต้นระบบตามที่อธิบายไว้ในเอกสารนี้ คอลัมน์ คําสั่งซื้อ แสดงลําดับที่งาน Secure-Boot-Update ประมวลผลแต่ละบิต
|
คำสั่งซื้อ |
การตั้งค่าบิต |
การใช้งาน |
|---|---|---|
|
1 |
0x0040 |
บิตนี้บอกงานที่กําหนดเวลาไว้เพื่อเพิ่มใบรับรอง Windows UEFI CA 2023 ลงใน DB การบูตแบบปลอดภัย ซึ่งจะทําให้ Windows เชื่อถือผู้จัดการการเริ่มต้นระบบที่เซ็นชื่อโดยใบรับรองนี้ |
|
2 |
0x0800 |
บิตนี้บอกงานที่กําหนดเวลาเพื่อใช้ Microsoft Option ROM UEFI CA 2023 กับ DB ลักษณะการทํางาน ตามเงื่อนไข: เมื่อตั้งค่าสถานะ 0x4000 งานที่จัดกําหนดการไว้จะตรวจสอบฐานข้อมูลสําหรับใบรับรอง Microsoft Corporation UEFI CA 2011 ก่อน ซึ่งจะใช้ใบรับรอง Microsoft Option ROM UEFI CA 2023เฉพาะเมื่อ มีใบรับรอง 2011 |
|
3 |
0x1000 |
บิตนี้บอกงานที่จัดกําหนดการเพื่อใช้ Microsoft UEFI CA 2023 กับ DB ลักษณะการทํางานตามเงื่อนไข: เมื่อตั้งค่าสถานะ 0x4000 งานที่จัดกําหนดการไว้จะตรวจสอบฐานข้อมูลสําหรับใบรับรอง Microsoft Corporation UEFI CA 2011 ก่อน ซึ่งจะใช้ใบรับรอง Microsoft UEFI CA 2023เฉพาะเมื่อ มีใบรับรอง 2011 อยู่เท่านั้น |
|
ตัวปรับเปลี่ยน (ค่าสถานะลักษณะการทํางาน) |
0x4000 |
บิตนี้จะปรับเปลี่ยนลักษณะการทํางานของบิต 0x0800 และ 0x1000 เพื่อให้ Microsoft UEFI CA 2023 และ Microsoft Option ROM UEFI CA 2023 ใช้ก็ต่อเมื่อ DB มี Microsoft Corporation UEFI CA 2011 อยู่แล้วเท่านั้น เพื่อช่วยให้แน่ใจว่าโปรไฟล์ความปลอดภัยของอุปกรณ์ยังคงเหมือนเดิม บิตนี้จะใช้ใบรับรองใหม่เหล่านี้หากอุปกรณ์เชื่อถือใบรับรอง Microsoft Corporation UEFI CA 2011 เท่านั้น มีอุปกรณ์ Windows ที่เชื่อถือใบรับรองนี้ไม่ครบทุกเครื่อง |
|
4 |
0x0004 |
บิตนี้จะบอกให้งานที่กําหนดเวลาไว้ค้นหาคีย์ Exchange ที่เซ็นชื่อโดยคีย์แพลตฟอร์ม (PK) ของอุปกรณ์ PK ได้รับการจัดการโดย OEM OEM เซ็นชื่อใน Microsoft KEK ด้วย PK ของตน และส่งไปยัง Microsoft ซึ่งมีอยู่ในการอัปเดตแบบสะสมรายเดือน |
|
5 |
0x0100 |
บิตนี้บอกงานที่จัดกําหนดการเพื่อใช้ตัวจัดการการเริ่มต้นระบบ ซึ่งเซ็นชื่อโดย Windows UEFI CA 2023 ลงในพาร์ติชันสําหรับเริ่มต้นระบบ การดําเนินการนี้จะแทนที่ตัวจัดการการบูตที่ลงชื่อแล้วของ Microsoft Windows Production PCA 2011 |
หมายเหตุ:
-
บิต 0x4000 จะยังคงได้รับการตั้งค่าหลังจากประมวลผลบิตอื่นๆ ทั้งหมด
-
แต่ละบิตจะถูกประมวลผลโดยงานที่จัดกําหนดการการอัปเดตการบูตแบบปลอดภัยตามลําดับที่แสดงด้านบน
-
หากบิต 0x0004 ไม่สามารถประมวลผลได้เนื่องจากไม่มี PK เซ็นชื่อ KEK งานที่กําหนดเวลาไว้จะยังคงใช้การปรับปรุงตัวจัดการการเริ่มต้นระบบที่ระบุโดยบิต 0x0100
ความคืบหน้าที่คาดไว้ (AvailableUpdates)
เมื่อการดําเนินการเสร็จสมบูรณ์ Windows จะล้างบิตที่เกี่ยวข้องจาก AvailableUpdates หากการดําเนินการล้มเหลว Windows จะบันทึกเหตุการณ์และลองใหม่เมื่องานทํางานอีกครั้ง
ตารางด้านล่างแสดงความคืบหน้าที่คาดไว้ของค่า AvailableUpdates เมื่อแต่ละการดําเนินการอัปเดตการบูตแบบปลอดภัยเสร็จสมบูรณ์
|
ขั้นตอน |
ประมวลผลบิตแล้ว |
Updates ที่พร้อมใช้งาน |
คำอธิบาย |
บันทึกเหตุการณ์สําเร็จแล้ว |
รหัสเหตุการณ์ข้อผิดพลาดที่เป็นไปได้ |
|---|---|---|---|---|---|
|
เริ่มต้น |
0x5944 |
สถานะเริ่มต้นก่อนการให้บริการใบรับรองการบูตแบบปลอดภัยจะเริ่มต้นขึ้น |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 ถูกเพิ่มลงใน DB การบูตแบบปลอดภัย |
1036 |
1032, 1795, 1796, 1802 |
|
2 |
0x0800 |
0x5904 → 0x5104 |
เพิ่ม Microsoft Option ROM UEFI CA 2023 ไปยัง DB หากอุปกรณ์นั้นเชื่อถือ Microsoft UEFI CA 2011 ก่อนหน้านี้ |
1044 |
1032, 1795, 1796, 1802 |
|
3 |
0x1000 |
0x5104 → 0x4104 |
Microsoft UEFI CA 2023 จะถูกเพิ่มลงใน DB ถ้าอุปกรณ์นั้นเชื่อถือ Microsoft UEFI CA 2011 ก่อนหน้านี้ |
1045 |
1032, 1795, 1796, 1802 |
|
4 |
0x0004 |
0x4104 → 0x4100 |
Microsoft KEK 2K CA 2023 ใหม่ที่เซ็นชื่อโดยคีย์แพลตฟอร์ม OEM จะถูกนําไปใช้ |
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 ระบุว่า KEK ที่ลงนามด้วย OEM PK หายไป
ขั้นตอนการแก้ไข
ในหัวข้อนี้แสดงขั้นตอนต่างๆ เพื่อแก้ไขปัญหาการบูตแบบปลอดภัยเฉพาะด้าน แต่ละขั้นตอนจะกําหนดขอบเขตตามเงื่อนไขที่กําหนดไว้อย่างดีและมีวัตถุประสงค์เพื่อปฏิบัติตามหลังจากการวินิจฉัยครั้งแรกยืนยันว่าปัญหามีผลบังคับใช้เท่านั้น ใช้ขั้นตอนเหล่านี้เพื่อคืนค่าลักษณะการทํางานของการบูตแบบปลอดภัยที่คาดไว้ และอนุญาตให้การอัปเดตใบรับรองดําเนินการต่อได้อย่างปลอดภัย อย่าใช้ขั้นตอนเหล่านี้อย่างกว้างขวางหรือถือว่าเป็นอันสมควร
การเปิดใช้งานการบูตแบบปลอดภัยในเฟิร์มแวร์
หากการบูตแบบปลอดภัยถูกปิดใช้งานในเฟิร์มแวร์ของอุปกรณ์ โปรดดูที่ Windows 11 และ Secure Boot สําหรับรายละเอียดเกี่ยวกับการเปิดใช้งาน Secure Boot
งานที่กําหนดเวลาการบูตแบบปลอดภัยถูกปิดใช้งานหรือลบออก
จําเป็นต้องมีงานที่จัดกําหนดการไว้ใน Secure-Boot-Update สําหรับ Windows เพื่อใช้การอัปเดตใบรับรองการบูตแบบปลอดภัย ถ้างานถูกปิดใช้งานหรือหายไป การให้บริการใบรับรองการบูตแบบปลอดภัยจะไม่ดําเนินการ
รายละเอียดงาน
|
ชื่องาน |
Secure-Boot-Update |
|
เส้นทางงาน |
\Microsoft\Windows\PI\ |
|
เส้นทางแบบเต็ม |
\Microsoft\Windows\PI\Secure-Boot-Update |
|
ทํางานเป็น |
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 -Quiet
เรียกใช้คําแนะนํา
-
ถ้าคุณเห็นการเข้าถึงถูกปฏิเสธ ให้เรียก PowerShell อีกครั้งในฐานะผู้ดูแลระบบ
-
ถ้าสคริปต์จะไม่ทํางานเนื่องจากนโยบายการดําเนินการ ให้ใช้การบายพาสขอบเขตกระบวนการ:
Set-ExecutionPolicy -ขอบเขตกระบวนการ -ExecutionPolicy Bypass