פתרון בעיות
חל על
תאריך פרסום מקורי: (יום שלישי 19 מרץ 2026)
מזהה KB: 5085046
במאמר זה
מבט כולל
דף זה מנחה מנהלי מערכת ומומחי תמיכה באבחון ופתרון של בעיות הקשורות לאתחול מאובטח במכשירי Windows. הנושאים כוללים כשלים בעדכון אישור אתחול מאובטח, מצבים שגויים של אתחול מאובטח, בקשות שחזור בלתי צפויות של BitLocker וכשלים באתחול לאחר שינויים בתצורה של אתחול מאובטח.
ההדרכה מסבירה כיצד לאמת את השירות והתצורה של Windows, לסקור את ערכי הרישום ואת יומני האירועים הרלוונטיים ולזהות מתי מגבלות הקושחה או הפלטפורמה דורשות עדכון OEM. תוכן זה מיועד לאבחון בעיות במכשירים קיימים. הוא אינו מיועד לתכנון פריסות חדשות. מסמך זה יעודכן עם זיהוי תרחישים והדרכה חדשים לפתרון בעיות.
כיצד פועל שירות אישור אתחול מאובטח
שירות אישור אתחול מאובטח ב- Windows הוא תהליך מתואם בין מערכת ההפעלה לבין קושחת UEFI של מכשיר. המטרה היא לעדכן עוגנים קריטיים של אמון תוך שמירה על היכולת לבצע אתחול בכל שלב.
התהליך מבוסס על משימה מתוזמנת של Windows, רצף מבוסס רישום של פעולות עדכון, ורישום מוכלל ופעולות ניסיון חוזר. יחד, רכיבים אלה מבטיחים לאישורי אתחול מאובטח ולמנהל האתחול של Windows מתעדכנים באופן מבוקר ומאובטח, ורק לאחר שפעולות המהוות דרישה מוקדמת מצליחות.
היכן להתחיל בעת פתרון בעיות
כאשר נראה שמכשיר אינו מבצע התקדמות צפויה בעת החלת עדכוני אישור אתחול מאובטח, התחל על-ידי זיהוי קטגוריית הבעיה. רוב הבעיות נכללות באחד מארבעה תחומים: מצב השירות של Windows, מנגנון עדכון האתחול המאובטח, אופן הפעולה של הקושחה או מגבלת פלטפורמה או OEM.
התחל עם ההבדקות שלהלן, לפי הסדר. במקרים רבים, שלבים אלה מספיקים כדי להסביר את אופן הפעולה שנצפה ולברר את הפעולות הבאות ללא חקירה עמוקה יותר.
-
אשר את זכאותך לשירות ולפלטפורמה של Windows
-
ודא שהמכשיר עומד בדרישות הבסיסיות לקבלת עדכוני אישור אתחול מאובטח:
-
במכשיר פועלת גירסה נתמכת של Windows.
-
עדכוני האבטחה הנדרשים האחרונים של Windows מותקנים.
-
אתחול מאובטח זמין בקושחת UEFI.
-
אם אחד מהתנאים הללו לא מתקיימים, פנה אליהם לפני שתמשיך בפתרון בעיות נוסף.
-
-
אימות מצב המשימה Secure-Boot-Update
-
ודא שמנגנון Windows האחראי להחלת עדכוני אישור אתחול מאובטח קיים ות פועל:
-
המשימה המתוזמנת 'עדכון אתחול מאובטח' קיימת.
-
המשימה זמינה ותפעל כמערכת מקומית.
-
המשימה הופעלה לפחות פעם אחת מאז התקנת עדכון האבטחה האחרון של Windows.
-
אם המשימה אינה זמינה, נמחקה או אינה פועלת, לא ניתן להחיל עדכוני אישור אתחול מאובטח. פתרון בעיות אמור להתמקד בשחזור המשימה לפני שתחקור גורמים אחרים.
-
-
בדוק את הגדרות הרישום עבור ההתקדמות הצפויה
סקור את מצב השירות של האתחול המאובטח של המכשיר ברישום:
-
בדוק את UEFICA2023Status, UEFICA2023Error ו- UEFICA2023ErrorEvent.
-
בדוק את AvailableUpdates והשווה אותו להתקדמות הצפויה (ראה הפניה ופנימיות).
יחד, ערכים אלה מציינים אם השירות מתקדם כרגיל, מנסה שוב לבצע פעולה או נעכב בשלב ספציפי.
-
-
תאם מצב רישום עם אירועי אתחול מאובטח
סקור אירועים הקשורים לאתחול מאובטח ביומן האירועים של המערכת ותאם אותם עם מצב הרישום. נתוני אירוע בדרך כלל מאשרים אם המכשיר מתקדם קדימה, מנסה שוב עקב מצב זמני או חסום על-ידי בעיית קושחה או פלטפורמה.
יחד, הרישום ורישום האירועים מציינים בדרך כלל אם אופן הפעולה צפוי, זמני או דורש פעולה מתקן.
משימה מתוזמנת של עדכון אתחול מאובטח
שירות אישור אתחול מאובטח מיושם באמצעות משימה מתוזמנת של Windows בשם Secure-Boot-Update. הפעילות רשומה בנתיב הבא:
\Microsoft\Windows\PI\Secure-Boot-Update
המשימה פועלת כמערכת מקומית. כברירת מחדל, הוא פועל בהפעלת המערכת ו מדי 12 שעות לאחר מכן. בכל פעם שהוא מופעל, הוא בודק אם פעולות עדכון של אתחול מאובטח ממתינות וניסיון להחיל אותן ברצף.
אם משימה זו אינה זמינה או חסרה, לא ניתן להחיל עדכוני אישור אתחול מאובטח. המשימה Secure-Boot-Update חייבת להישאר זמינה כדי שטיפול באתחול מאובטח יתאפשר.
מדוע נעשה שימוש בפעילות מתוזמנת
עדכוני אישור אתחול מאובטח דורשים תיאום בין הקושחה של 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 רגילים כדי לעדכן משתני אתחול מאובטח כגון DB ו- KEK, או כדי להתקין את מנהל האתחול המעודכן של Windows. Windows מתעד את התוצאה של כל שלב ביומן האירועים של המערכת. אירועי הצלחה מאשרים התקדמות קדימה, בעוד שאירועי כשל מציינים מדוע לא היתה אפשרות להשלים פעולה.
אם שלב עדכון נכשל, המשימה מפסיקה לעבד, מבצעת רישום של השגיאה ומשאירה את ערכת הסיביות המשויכת. מתבצע ניסיון נוסף לבצע את הפעולה בפעם הבאה שהמשימה מופעלת. אופן פעולה זה של משפטים מחדש מאפשר למכשירים להתאושש באופן אוטומטי מתנאים זמניים, כגון תמיכה בקושחה חסרה או עדכוני OEM מושהים.
מנהלי מערכת יכולים לעקוב אחר ההתקדמות על-ידי התאמה של מצב הרישום עם ערכי יומן אירועים. ערכי רישום כגון UEFICA2023Status, UEFICA2023Error ו- UEFICA2023ErrorEvent, יחד עם מסיכת הסיביות AvailableUpdates , מציינים איזה שלב פעיל, הושלם או חסום.
שילוב זה מראה אם המכשיר מתקדם כרגיל, מנסה שוב לבצע פעולה או נעכב אותה.
שילוב עם קושחת OEM
עדכוני אישור אתחול מאובטח תלויים באופן הפעולה הנכון והתמיכה בקושחת UEFI של מכשיר. למרות ש- Windows מנהל את תהליך העדכון, הקושחה אחראית לאכוף מדיניות אתחול מאובטח ולתחזק את מסדי הנתונים של האתחול המאובטח.
יצרני ציוד מקורי (OEM) מספקים שני רכיבים קריטיים המאפשרים מתן שירות לאישור אתחול מאובטח:
-
מפתחות Key Exchange (KEKs) חתומים באמצעות מפתח פלטפורמה המאשרים התקנה של אישורי אתחול מאובטח חדשים.
-
יישומי קושחה ששומרים, מצרף ומאומתים כראוי מסדי נתונים של אתחול מאובטח במהלך עדכונים.
אם הקושחה אינה תומכת באופן מלא אופני פעולה אלה, עדכוני אתחול מאובטח יכולים לעכב, לנסות שנית לזמן בלתי מוגבל או לגרום לכשלים באתחול. במקרים אלה, ל- Windows אין אפשרות להשלים את העדכון ללא שינויים בקושחה.
Microsoft פועלת עם יצרני ציוד מקורי (OEM) כדי לזהות בעיות קושחה להפוך עדכונים מתוקנים לזמינים. כאשר פתרון בעיות מציין מגבלת קושחה או פגם, ייתכן שמנהלי מערכת יצטרכו להתקין את עדכון הקושחה האחרון של UEFI שסופק על-ידי יצרן המכשיר לפני שניתן יהיה להשלים את עדכוני אישור האתחול המאובטח בהצלחה.
תרחישי כשל נפוצים ופתרונות
עדכוני אתחול מאובטח מוחלים על-ידי המשימה המתוזמנת Secure-Boot-Update בהתבסס על מצב הרישום AvailableUpdates .
בתנאים רגילים, שלבים אלה מתרחשים באופן אוטומטי ומקליטים אירועי הצלחה עם השלמת כל שלב. במקרים מסוימים, אופן הפעולה של הקושחה, תצורת הפלטפורמה או דרישות מוקדמות של מתן שירות יכולים למנוע התקדמות או להוביל לאופני פעולה לא צפויים של אתחול.
הסעיפים הבאים מתארים את תרחישי הכשל הנפוצים ביותר, כיצד לזהות אותם, מדוע הם מתרחשים ואת השלבים הבאים המתאימים לשחזור הפעולה הרגילה. תרחישים מסודרים מהתרחישים הנפוצים ביותר שהתרחשו למקרים חמורים יותר המשפיעים על האתחול.
כאשר עדכוני אתחול מאובטח אינם מראים התקדמות, בדרך כלל פירוש הדבר שתהליך העדכון מעולם לא התחיל. כתוצאה מכך, ערכי הרישום הצפויים של האתחול המאובטח ורישום האירועים חסרים מאחר שמנגנון העדכון מעולם לא הופעל.
מה קרה
תהליך העדכון של האתחול המאובטח לא החל, ולכן לא הוחלו אישורי אתחול מאובטח או מנהל אתחול מעודכן על ההתקן.
כיצד לזהות אותו
-
לא קיימים ערכי רישום של מתן שירות לאתחול מאובטח, כגון UEFICA2023Status.
-
צפוי אירועי אתחול מאובטח (לדוגמה, 1043, 1044, 1045, 1799, 1801) חסרים ביומן האירועים של המערכת.
-
ההתקן ממשיך להשתמש באישורים ישנים יותר של אתחול מאובטח וברכיבי אתחול.
מדוע זה קורה
תרחיש זה מתרחש בדרך כלל כאשר אחד או יותר מהתנאים הבאים מתקיימים:
-
המשימה המתוזמנת של עדכון אתחול מאובטח אינה זמינה או חסרה.
-
אתחול מאובטח אינו זמין בקושחת UEFI.
-
המכשיר אינו עומד בדרישות המוקדמות של שירות Windows, כגון הפעלה של גירסת Windows נתמכת או התקנה של עדכונים נדרשים.
מה לעשות בשלב הבא
-
ודא שהמכשיר עומד בדרישות השירות והזכאותך לפלטפורמה של Windows.
-
ודא שאתחול מאובטח זמין בקושחה.
-
ודא שהפעילות המתוזמנת SecureBootUpdate קיימת וזמינה.
אם המשימה המתוזמנת אינה זמינה או חסרה, בצע את ההנחיות במשימה המתוזמנת 'אתחול מאובטח' כלא זמינה או נמחקה כדי לשחזר אותה. לאחר שחזור המשימה, הפעל מחדש את המכשיר או הפעל את המשימה באופן ידני כדי להפעיל שירות אתחול מאובטח.
במקרים מסוימים, עדכונים הקשורים לאתחול מאובטח עלולים לגרום למכשיר להיכנס לשחזור של BitLocker. אופן הפעולה עשוי להיות זמני או מתמיד, בהתאם לגורם המשמש לבעיה.
תרחיש 1: שחזור Onetime 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 צופה בשרשראות אמון שונות של אתחול מאובטח במהלך האתחול, הוא אינו יכול ליצור ערכה יציבה של מדידות TPM לאתחול מחדש. כתוצאה מכך, BitLocker נכנס לשחזור בכל אתחול.
כיצד לזהות אותו
-
שחזור BitLocker מופעל בכל הפעלה מחדש.
-
הזנת מפתח השחזור מאפשרת ל- Windows להתחיל, אך הבקשה חוזרת באתחול הבא.
-
PXE או אתחול רשת מוגדרים מראש הדיסק המקומי בסדר האתחול של הקושחה.
מה לעשות בשלב הבא
-
קבע את תצורת סדר האתחול של הקושחה, כך שמנהל האתחול של Windows בדיסק יהיה הראשון.
-
הפוך אתחול PXE ללא זמין אם הוא אינו נדרש.
-
אם נדרש PXE, ודא שתשתית PXE משתמשת בטעינת אתחול Windows בעלת חתימה 2023.
מה קרה
פעולה זו משקפת שינוי ברמת הקושחה במקום בעיה ב- Windows. עדכון האתחול המאובטח הושלם בהצלחה, אך לאחר הפעלה מחדש מאוחרת יותר, המכשיר כבר לא מאותחל ל- Windows.
כיצד לזהות אותו
-
המכשיר אינו מצליח להפעיל את Windows והוא עשוי להציג הודעת קושחה או BIOS המציינת הפרת אתחול מאובטח.
-
הכשל מתרחש לאחר שהגדרות האתחול המאובטח מאופסות לברירת המחדל של הקושחה.
-
הפיכת אתחול מאובטח ללא פועל עשויה לאפשר להתקן לבצע אתחול חוזר.
מדוע זה קורה
איפוס אתחול מאובטח לברירת מחדל של קושחה מנקה את מסדי הנתונים של האתחול המאובטח המאוחסנים בקושחה. במכשירים שכבר מעברו למנהל האתחול החתום על-ידי Windows UEFI CA 2023, איפוס זה מסיר את האישורים הדרושים כדי לתת אמון במנהל אתחול זה.
כתוצאה מכך, הקושחה אינה מזהה עוד את מנהל האתחול המותקן של Windows כמהימן ובלוק תהליך האתחול.
תרחיש זה אינו נגרם על-ידי עדכון האתחול המאובטח עצמו, אלא על-ידי פעולת קושחה בהמשך שמסירה את עוגני האמון המעודכנים.
מה לעשות בשלב הבא
-
השתמש בכלי השירות לשחזור אתחול מאובטח כדי לשחזר את האישור הנדרש, כדי שהמכשיר יוכל לבצע אתחול מחדש.
-
לאחר השחזור, ודא שהמכשיר כולל את הקושחה הזמינה העדכנית ביותר המותקנת על-ידי יצרן המכשיר.
-
הימנע מאיפוס אתחול מאובטח להגדרות ברירת המחדל של הקושחה, אלא אם כן קושחת ה- 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 של המערכת לגירסה החדשה ביותר הזמינה. הדבר יכול לסייע במניעת מופע חוזר של בעיית איפוס האתחול המאובטח, ככל ש יצרני ציוד מקורי רבים הפיצה תיקוני קושחה עבור בעיה ספציפית זו.
מה קרה
לאחר החלת העדכון והפעלה מחדש של אישור האתחול המאובטח, האתחול של המכשיר נכשל והוא אינו מגיע ל- Windows.
כיצד לזהות אותו
-
המכשיר נכשל מיד לאחר ההפעלה מחדש הנדרשת על-ידי עדכון האתחול המאובטח.
-
ייתכן שתוצג שגיאת קושחה או אתחול מאובטח, או שהמערכת יכולה להפסיק לפני טעינת Windows.
-
הפיכת אתחול מאובטח ללא פועל עשויה לאפשר להתקן לבצע אתחול.
מדוע זה קורה
בעיה זו עשויה להיגרם כתוצאה מפגם בהטמעת הקושחה של UEFI במכשיר.
כאשר Windows מחיל עדכוני אישור אתחול מאובטח, הקושחה צפויה לצרף אישורים חדשים למסד הנתונים הקיים של חתימה מותרת של אתחול מאובטח (DB). יישומי קושחה מסוימים מחליפו באופן שגוי את מסד הנתונים במקום לצרף אותו.
כאשר הדבר מתרחש,
-
אישורים שהיו מהימנים בעבר, כולל אישור bootloader של Microsoft 2011, יוסרו.
-
אם המערכת עדיין משתמשת במנהל אתחול החתום עם אישור 2011 בשלב זה, הקושחה אינה בוטחת בו עוד.
-
הקושחה דוחה את מנהל האתחול ו חוסמת את תהליך האתחול.
במקרים מסוימים, מסד הנתונים עלול גם להיפגם במקום להיכתב בצורה נקייה, מה שמוביל לאותה תוצאה. אופן פעולה זה נצפה בהטמעות קושחה ספציפיות והוא אינו צפוי בקושחה תואמת.
מה לעשות בשלב הבא
-
הזן את תפריטי הגדרת הקושחה ונסה לאפס הגדרות אתחול מאובטח.
-
אם המכשיר מאותחל לאחר האיפוס, עיין באתר התמיכה של יצרן ההתקן לקבלת עדכון קושחה המתקן את הטיפול ב- DB של אתחול מאובטח.
-
אם קיים עדכון קושחה זמין, התקן אותו לפני הפעלה מחדש של אתחול מאובטח והחלה מחדש של עדכוני אישור אתחול מאובטח.
אם איפוס אתחול מאובטח אינו משחזר את פונקציונליות האתחול, ייתכן שהתאוששות נוספת דורשת הדרכה ספציפית ליצרן הציוד המקורי.
מה קרה
עדכון אישור האתחול המאובטח לא הושלם והוא נותר חסום בשלב העדכון של מפתח Exchange Key (KEK).
כיצד לזהות אותו
-
ערך הרישום AvailableUpdates נשאר מוגדר עם סיבית KEK (0x0004) ולא נמחק.
-
UEFICA2023Status אינו מתקדם למצב שהושלם.
-
יומן האירועים של המערכת מתעד שוב ושוב את מזהה האירוע 1803, המציין שלא היתה אפשרות להחיל את עדכון KEK.
-
המכשיר ממשיך לנסות שוב את העדכון מבלי להתקדם.
מדוע זה קורה
עדכון ה- KEK של האתחול המאובטח דורש הרשאה ממפתח הפלטפורמה (PK) של המכשיר, הנמצא בבעלות OEM.
כדי שהעדכון יצליח, יצרן המכשיר חייב לספק ל- Microsoft ערכת KEK חתומה באמצעות PK עבור פלטפורמה ספציפית זו. KEK זה החתום על-ידי OEM כלול בעדכונים של Windows ומאפשר ל- Windows לעדכן את משתנה KEK הקושחה.
אם יצרן הציוד המקורי לא סיפק KEK החתום על-ידי PK עבור המכשיר, ל- Windows אין אפשרות להשלים את עדכון KEK. במצב זה:
-
עדכוני אתחול מאובטח נחסמים על-ידי עיצוב.
-
ל- Windows אין אפשרות לעקוף את ההרשאה החסרה.
-
המכשיר יכול להישאר ללא אפשרות להשלים את שירות אישור האתחול המאובטח לצמיתות.
מצב זה עשוי להתרחש במכשירים ישנים יותר או שאינם נתמכים, שבהם יצרן הציוד המקורי אינו מספק עוד עדכוני קושחה או עדכוני מפתח. אין נתיב שחזור ידני נתמך עבור תנאי זה.
כאשר החלת עדכוני אישור אתחול מאובטח נכשלת, Windows מתעד אירועי אבחון המסבירים מדוע ההתקדמות נחסמה. אירועים אלה נכתבים בעת עדכון מסד הנתונים של חתימת האתחול המאובטח (DB) או מפתח חילופי מקשים (KEK) לא ניתן להשלים בבטחה עקב קושחה, מצב פלטפורמה או תנאי תצורה. התרחישים בסעיף זה מפנים לאירועים אלה כדי לזהות דפוסי כשל נפוצים ולברר את התיקון המתאים. סעיף זה נועד לתמוך באבחון ובפרשנות של בעיות המתוארות קודם לכן, ולא להציג תרחישי כשל חדשים.
לקבלת רשימה מלאה של מזהה אירוע, תיאורים וערכים לדוגמה, ראה אירועי עדכון של משתני DB ואתחול מאובטח של DBX (KB5016061).
כשל בעדכון KEK (עדכוני DB מצליחים, KEK לא)
מכשיר יכול לעדכן בהצלחה אישורים במסד הנתונים של האתחול המאובטח, אך נכשל במהלך העדכון של KEK. כאשר הדבר מתרחש, לא ניתן להשלים את תהליך העדכון של האתחול המאובטח.
תסמינים
-
אירועי אישור DB מציינים התקדמות, אך שלב KEK לא הושלם.
-
AvailableUpdates נשאר מוגדר 0x4004 והסיביות 0x0004 אינה מנוקה לאחר הפעלת משימות מרובות.
-
ייתכן שאירוע 1795 או 1803 קיים.
פרשנות
-
1795 מציין בדרך כלל כשל קושחה בעת ניסיון לעדכן משתנה אתחול מאובטח.
-
1803 מציין שלא ניתן לאשר את עדכון KEK מאחר שמטען KEK נדרש החתום על-ידי OEM אינו זמין עבור הפלטפורמה.
השלבים הבאים
-
עבור 1795, בדוק אם קיימים עדכוני קושחה של OEM ואימת את התמיכה בקושחה עבור עדכונים משתנים של אתחול מאובטח.
-
עבור 1803, בדוק אם יצרן הציוד המקורי (OEM) סיפק ל- Microsoft את ה- KEK החתום על-ידי PK הנדרש עבור דגם המכשיר.
כשל בעדכון KEK במחשבים וירטואליים של אורח המתארחים ב- Hyper-V
במחשבים וירטואליים של Hyper-V, עדכוני אישור אתחול מאובטח דורשים התקנה של עדכוני Windows עבור מרץ 2026 במחשב המארח של Hyper-V ובמערכת ההפעלה האורחת.
כשלים בעדכון מדווחים מתוך האורח, אך האירוע מציין היכן נדרש תיקון:
-
אירוע 1795 (לדוגמה, "המדיה מוגנת מפני כתיבה") שדווח אורח מציין שחסר עדכון מארח Hyper-V במרץ 2026 ויש לעדכן אותו.
-
אירוע 1803 שדווח אורח מציין שחסר עדכון למחשב הווירטואלי האורח עצמו במרץ 2026 ויש לעדכן אותו.
הפניה ופני פנימיים
סעיף זה מכיל מידע עזר מתקדם המיועד לפתרון בעיות ותמיכה. הוא אינו מיועד לתכנון פריסה. היא מתרחבת במכניקה של שירות האתחול המאובטח שמסכמת קודם לכן ומספקת חומר עזר מפורט לפרשנות מצב הרישום ויומנים של אירועים.
הערה (פריסות המנוהלות על-ידי IT): כאשר התצורה מדיניות קבוצתית או Microsoft Intune, אין לבלבל בין שתי הגדרות דומות. הערך AvailableUpdatesPolicy מייצג את מצב המדיניות שתצורתו נקבעה. בינתיים, AvailableUpdates משקף את מצב העבודה המתבצע של ניקוי סיביות. שתיהן יכולות להוות את אותה תוצאה, אך הן פועלות באופן שונה מכיוון שהמדיניות חלה מחדש לאורך זמן.
AvailableUpdates bits used for certificate servicing
הסיביות שלהלן משמשות עבור פעולות מנהל האישור והאתחול המתוארות במסמך זה. העמודה סדר משקפת את הרצף שבו המשימה Secure-Boot-Update מעבדת כל סיבית.
|
הזמנה |
הגדרת סיביות |
שימוש |
|---|---|---|
|
1 |
0x0040 |
סיבית זו מורה למשימה המתוזמנת להוסיף את אישור Windows UEFI CA 2023 ל- Secure Boot DB. פעולה זו מאפשרת ל- Windows לתת אמון במנהלי אתחול החתמו על-ידי אישור זה. |
|
2 |
0x0800 |
סיבית זו מורה למשימה המתוזמנת להחיל את Microsoft Option ROM UEFI CA 2023 על מסד הנתונים. אופן פעולה מותנה: 0x4000 מוגדר, המשימה המתוזמנת תבדוק תחילה את מסד הנתונים עבור אישור UEFI CA 2011 של Microsoft Corporation . היא תחיל את אישור MICROSOFT Option ROM UEFI CA 2023רק אם האישור 2011 קיים. |
|
3 |
0x1000 |
סיבית זו מורה לפעילות המתוזמנת להחיל את Microsoft UEFI CA 2023 על מסד הנתונים. אופן פעולה מותנה: כאשר 0x4000 מוגדר, המשימה המתוזמנת תבדוק תחילה את מסד הנתונים עבור אישור Microsoft Corporation UEFI CA 2011 . הוא יחיל את אישור Microsoft UEFI CA 2023רק אם האישור 2011 קיים. |
|
צירוף (דגל אופן פעולה) |
0x4000 |
סיבית זו משנה את אופן הפעולה של סיביות 0x0800 ו- 0x1000 כך ש- Microsoft UEFI CA 2023 ו- Microsoft Option ROM UEFI CA 2023 יחולו רק אם מסד הנתונים כבר מכיל את Microsoft Corporation UEFI CA 2011. כדי להבטיח שפרופיל האבטחה של המכשיר יישאר זהה, סיבית זו מחילה אישורים חדשים אלה רק אם המכשיר נותן אמון באישור Microsoft Corporation UEFI CA 2011. לא כל מכשירי Windows נותן אמון באישור זה. |
|
4 |
0x0004 |
סיבית זו מורה למשימה המתוזמנת לחפש מפתח Exchange חתום על-ידי מפתח הפלטפורמה (PK) של המכשיר. ה- PK מנוהל על-ידי יצרן הציוד המקורי. יצרני ציוד מקורי (OEM) חתומים על Microsoft KEK באמצעות ה- PK שלהם ומעבירים אותם ל- Microsoft, שם הם כלולים בעדכונים מצטברים חודשיים. |
|
5 |
0x0100 |
סיבית זו מורה למשימה המתוזמנת להחיל את מנהל האתחול, החתום על-ידי רשות האישורים של Windows UEFI 2023, על מחיצת האתחול. פעולה זו תחליף את מנהל האתחול החתום של Microsoft Windows Production PCA 2011. |
הערות:
-
סיבית 0x4000 תישאר מוגדרת לאחר עיבוד כל שאר הסיביות.
-
כל סיבית מעובדת על-ידי המשימה המתוזמנת Secure-Boot-Update בסדר המוצג לעיל.
-
אם לא 0x0004 לעבד את סיבית ה- 0X0004 עקב KEK חתום חסר של PK, המשימה המתוזמנת עדיין תחיל את העדכון של מנהל האתחול שצוין על-ידי 0x0100.
התקדמות צפויה (AvailableUpdates)
לאחר שפעולה מסתיימת בהצלחה, Windows מנקה את הסייביות המשויכת מ - AvailableUpdates. אם פעולה נכשלת, Windows רושם אירוע וניסיונות חוזרים כאשר המשימה מופעלת שוב.
הטבלה שלהלן מציגה את ההתקדמות הצפויה של ערכי AvailableUpdates עם השלמת כל פעולת עדכון של אתחול מאובטח.
|
שלב |
סיבית מעובדת |
זמינות עדכונים |
תיאור |
אירוע הצלחה נרשם |
קודי אירוע של שגיאה אפשרית |
|---|---|---|---|---|---|
|
התחל |
0x5944 |
המצב ההתחלתי לפני תחילת מתן השירות לאישור אתחול מאובטח. |
- |
- |
|
|
1 |
0x0040 |
0x5944 → 0x5904 |
Windows UEFI CA 2023 נוסף ל- Secure Boot 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 ואתחול מאובטח לקבלת פרטים אודות הפיכת אתחול מאובטח לזמינים.
משימה מתוזמנת של אתחול מאובטח אינה זמינה או נמחקה
המשימה המתוזמנת של עדכון אתחול מאובטח נדרשת כדי ש- Windows יחיל עדכוני אישור אתחול מאובטח. אם המשימה אינה זמינה או חסרה, שירות אישור אתחול מאובטח לא יתבצע.
פרטי משימה
|
שם פעילות |
עדכון אתחול מאובטח |
|
נתיב פעילות |
\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
חפש את השדה מצב:
|
מצב |
משמעות |
|---|---|
|
מוכן |
המשימה קיימת וזמינה. |
|
לא זמין |
הפעילות קיימת אך יש להפוך אותה לזמינה. |
|
שגיאה / לא נמצא |
המשימה חסרה ויש ליצור אותה מחדש. |
כיצד להפוך את הפעילות לזמינה או ליצור אותה מחדש
אם שדה המצב עבור עדכון אתחול מאובטח אינו זמין, שגיאה או לא נמצא, השתמש בקובץ ה- Script לדוגמה כדי להפוך את המשימה לזמינה: דוגמה Enable-SecureBootUpdateTask.ps1
הערה: זהו קובץ Script לדוגמה שאינו נתמך על-ידי Microsoft. מנהלי מערכת צריכים לסקור את הסביבה שלהם ולהתאים אותה לסביבה שלהם.
לדוגמה:
.\Enable-SecureBootUpdateTask.ps1 -שקט
הפעל הדרכה
-
אם אתה רואה את האפשרות הגישה נדחתה, הפעל מחדש את PowerShell כמנהל מערכת.
-
אם קובץ ה- Script לא יפעל עקב מדיניות ביצוע, השתמש בעקיפת טווח תהליך:
Set-ExecutionPolicy תהליך -טווח - ExecutionPolicy Bypass