מדריך לפתרון בעיות באתחול מאובטח

במאמר זה

• סקירה כללית
• כיצד פועל שירות אישור אתחול מאובטח
• היכן להתחיל בפתרון בעיות
• משימה מתוזמנת של אתחול מאובטח-עדכון
• מדוע נעשה שימוש במשימה מתוזמנת
• מסיכת סיביות של הרישום AvailableUpdates
• שילוב עם קושחת OEM
• תרחישי כשל ופתרונות נפוצים
• הפניות ופנימיות
• סיביות AvailableUpdates המשמשות למתן שירות אישורים
• התקדמות צפויה (AvailableUpdates)
• הליכי תיקון
• הפעלת אתחול מאובטח בקושחה
• אתחול מאובטח: משימה מתוזמנת מושבתת או נמחקה

סקירה כללית

דף זה מנחה מנהלי מערכת ומומחי תמיכה באבחון ופתרון של בעיות הקשורות לאתחול מאובטח במכשירי 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. מתאם מצב רישום עם אירועי אתחול מאובטח
   סקור אירועים הקשורים לאתחול מאובטח ביומן האירועים של המערכת ותאם אותם למצב הרישום. נתוני אירוע בדרך כלל מאשרים אם המכשיר מתקדם קדימה, מנסה שוב עקב מצב חולף, או נחסם על-ידי בעיית קושחה או פלטפורמה.
   ביחד, הרישום ויומני האירועים מציינים בדרך כלל אם אופן הפעולה צפוי, זמני או דורש פעולה מתקנת.

חזור לראש הדף

משימה מתוזמנת של אתחול מאובטח-עדכון

שירות אישורי אתחול מאובטח מיושם באמצעות משימה מתוזמנת של Windows שנקראת Secure-Boot-Update. המשימה רשומה בנתיב הבא:

המשימה פועלת כמערכת מקומית. כברירת מחדל, היא פועלת בעת אתחול המערכת וכל 12 שעות לאחר מכן. בכל פעם שהוא מופעל, הוא בודק אם פעולות עדכון אתחול מאובטח ממתינות ומנסה להחיל אותן ברצף.

אם משימה זו אינה זמינה או חסרה, לא ניתן להחיל עדכונים של אישור אתחול מאובטח. המשימה אתחול-אתחול-עדכון מאובטח חייבת להישאר מופעלת כדי ששירות אתחול מאובטח יפעל.

חזור לראש הדף

מדוע נעשה שימוש במשימה מתוזמנת

עדכוני אישור אתחול מאובטח דורשים תיאום בין Windows לקושחת UEFI, כולל כתיבת משתני UEFI המאחסנים מפתחות ואישורים של אתחול מאובטח. משימה מתוזמנת מאפשרת ל- Windows לנסות עדכונים אלה כאשר המערכת נמצאת במצב שבו ניתן לשנות משתני קושחה.

לוח הזמנים החוזר של 12 שעות מספק הזדמנויות נוספות לנסות שוב עדכונים אם ניסיון קודם נכשל או אם המכשיר נותר מופעל ללא הפעלה מחדש. תכנון זה מסייע להבטיח התקדמות קדימה מבלי לדרוש התערבות ידנית.

חזור לראש הדף

מסיכת סיביות של הרישום AvailableUpdates

המשימה אתחול מאובטח-עדכון מונעת על-ידי ערך הרישום AvailableUpdates . ערך זה הוא מסיכת סיביות של 32 סיביות שנמצאת בשדה הבא:

כל סיבית בערך מייצגת פעולת עדכון ספציפית של אתחול מאובטח. תהליך העדכון מתחיל כאשר AvailableUpdates מוגדר כערך שאינו אפס, באופן אוטומטי על-ידי Windows או באופן מפורש על-ידי מנהל מערכת. לדוגמה, ערך כגון 0x5944 מציין שפעולות עדכון מרובות ממתינות.

כאשר המשימה אתחול-אתחול-עדכון מאובטח מופעלת, היא מפרשת את הסיביות המוגדרות כעבודה ממתינה ומעבדת אותן בסדר מוגדר.

חזור לראש הדף

אופן הפעולה של עדכונים רציפים, רישום ומשפט חוזר

עדכוני אישור אתחול מאובטח מוחלים בסדר קבוע. כל פעולת עדכון נועדה להיות בטוחה לניסיון חוזר והיא מסתיימת בנפרד. המשימה אתחול-אתחול-עדכון מאובטח אינה מתקדמת לשלב הבא עד שהפעולה הנוכחית מצליחה והסיבית המתאימה לה מנוקה מ-AvailableUpdates.

כל פעולה משתמשת בממשקי UEFI סטנדרטיים כדי לעדכן משתני אתחול מאובטח כגון DB ו-KEK, או כדי להתקין את מנהל האתחול המעודכן של Windows. Windows מתעד את התוצאה של כל שלב ביומן האירועים של המערכת. אירועי הצלחה מאשרים התקדמות קדימה, בעוד שאירועי כשל מציינים מדוע לא היתה אפשרות להשלים פעולה.

אם שלב עדכון נכשל, המשימה מפסיקה לעבד, רושמת את השגיאה ומשאירה את ערכת הסיביות המשויכת. יתבצע ניסיון חוזר לבצע את הפעולה בפעם הבאה שהמשימה מופעלת. אופן פעולה זה של הניסיון החוזר מאפשר למכשירים לבצע שחזור אוטומטי מתנאים זמניים, כגון תמיכת קושחה חסרה או עיכוב בעדכוני OEM.

מנהלי מערכת יכולים לעקוב אחר ההתקדמות על-ידי תיאום של מצב הרישום עם ערכי יומן האירועים. ערכי רישום כגון UEFICA2023Status, UEFICA2023Error ו - UEFICA2023ErrorEvent, יחד עם מסיכת הסיביות AvailableUpdates , מציינים איזה שלב פעיל, הושלם או חסום.

צירוף זה מראה אם המכשיר מתקדם כרגיל, מנסה לבצע שוב פעולה או נתקע.

חזור לראש הדף

שילוב עם קושחת OEM

עדכונים של אישורי אתחול מאובטח תלויים באופן הפעולה הנכון ובתמיכה בקושחת UEFI של המכשיר. בזמן ש- Windows מתזמרת את תהליך העדכון, הקושחה אחראית לאכיפת מדיניות אתחול מאובטח ולתחזוקה של מסדי הנתונים של אתחול מאובטח.

יצרני ציוד מקורי מספקים שני רכיבים קריטיים המאפשרים שירות אישורי אתחול מאובטח:

• מפתחות חילופי מפתחות (KEK) חתומים באמצעות מפתח פלטפורמה שמאשרים התקנה של אישורי אתחול מאובטח חדשים.
• יישומי קושחה שמשמרים, מצרפים ומאמתים כראוי מסדי נתונים של אתחול מאובטח במהלך עדכונים.

אם הקושחה אינה תומכת באופן מלא בהתנהגויות אלה, עדכוני אתחול מאובטח עלולים להתעכב, לנסות שוב לזמן בלתי מוגבל או לגרום לכשלים באתחול. במקרים אלה, ל- Windows אין אפשרות להשלים את העדכון ללא שינויים בקושחה.

Microsoft עובדת עם יצרני ציוד מקורי כדי לזהות בעיות קושחה ולהפוך עדכונים מתוקנים לזמינים. כאשר פתרון הבעיות מצביע על מגבלה או פגם בקושחה, ייתכן שמנהלי המערכת יצטרכו להתקין את עדכון הקושחה האחרון של UEFI שסופק על-ידי יצרן המכשיר לפני שהעדכונים של אישור אתחול מאובטח יוכלו להסתיים בהצלחה.

חזור לראש הדף

תרחישי כשל ופתרונות נפוצים

עדכוני אתחול מאובטח מוחלים על-ידי המשימה המתוזמנת Secure-Boot-Update בהתבסס על מצב הרישום 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: שחזור 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.

תוכנית שירות לשחזור אתחול מאובטח

כדי לשחזר את המערכת:

1. במחשב Windows שני שבו מותקן עדכון יולי 2024 ואילך של Windows, העתק את SecureBootRecovery.efi מ- C:\Windows\Boot\EFI\.
2. מקם את הקובץ בכונן USB בתבנית FAT32 תחת \EFI\BOOT\ ושנה את שמו ל- bootx64.efi.
3. אתחל את ההתקן המושפע מכונן ה-USB ואפשר לכלי השחזור לפעול. כלי השירות יוסיף את Windows UEFI CA 2023 ל-DB.

לאחר שחזור האישור וההפעלה מחדש של המערכת, Windows אמורה להתחיל לפעול כרגיל.

חשוב: תהליך זה יחיל מחדש רק אחד מהאישורים החדשים. לאחר שחזור המכשיר, ודא שהאישורים העדכניים ביותר הוחלו מחדש, ושקול לעדכן את ה-BIOS/UEFI של המערכת לגרסה החדשה ביותר הזמינה. הדבר יכול לסייע במניעת הישנות של בעיית איפוס האתחול המאובטח, מכיוון שיצרני ציוד מקורי רבים הפיצו תיקוני קושחה עבור בעיה ספציפית זו.

אתחול המכשיר נכשל לאחר עדכון אתחול מאובטח עקב קושחה שמחליפה את מסד הנתונים

מה קרה

לאחר החלת עדכון אישור האתחול המאובטח וההפעלה מחדש, האתחול של המכשיר נכשל ואינו מגיע ל- Windows.

כיצד לזהות אותו

• ההתקן נכשל מיד לאחר ההפעלה מחדש הנדרשת על-ידי עדכון האתחול המאובטח.
• ייתכן שתוצג שגיאת קושחה או אתחול מאובטח, או שהמערכת יכולה לעצור לפני ש-Windows נטען.
• השבתת אתחול מאובטח עשויה לאפשר אתחול של המכשיר.

מדוע זה קורה

ייתכן שבעיה זו נגרמת כתוצאה מפגם ביישום קושחת UEFI של המכשיר.

כאשר Windows מחילה עדכוני אישור אתחול מאובטח, הקושחה צפויה לצרף אישורים חדשים למסד הנתונים הקיים של חתימות מותרות אתחול מאובטח (DB). יישומי קושחה מסוימים מחליפים באופן שגוי את מסד הנתונים במקום לצרף אליו.

במקרה כזה,

• אישורים מהימנים בעבר, כולל אישור טוען האתחול של Microsoft 2011, מוסרים.
• אם המערכת עדיין משתמשת במנהל אתחול שנחתם עם אישור 2011 בשלב זה, הקושחה כבר לא נותנת בו אמון.
• הקושחה דוחה את מנהל האתחול וחוסמת את תהליך האתחול.

במקרים מסוימים, מסד הנתונים עלול גם להיות פגום במקום להימחק בצורה נקייה, מה שיוביל לאותה תוצאה. אופן פעולה זה נצפה ביישומי קושחה ספציפיים והוא אינו צפוי בקושחה תואמת.

מה לעשות הלאה

• היכנס לתפריטי הגדרות הקושחה ונסה לאפס את הגדרות האתחול המאובטח.
• אם המכשיר מבצע אתחול לאחר האיפוס, בדוק באתר התמיכה של יצרן המכשיר אם קיים עדכון קושחה שמתקן את הטיפול באתחול מאובטח DB.
• אם ישנו עדכון קושחה זמין, התקן אותו לפני שתפעיל מחדש את 'אתחול מאובטח' ותחיל מחדש את עדכוני אישור האתחול המאובטח.

אם איפוס אתחול מאובטח אינו משחזר את פונקציונליות האתחול, סביר להניח ששחזור נוסף ידרוש הדרכה ספציפית ליצרן ציוד מקורי.

עדכון אתחול מאובטח נחסם עקב KEK חסר בחתימת OEM

מה קרה

עדכון אישור האתחול המאובטח לא הושלם ונשאר חסום בשלב העדכון של מפתח חילופי מפתחות (KEK).

כיצד לזהות אותו

• ערך הרישום AvailableUpdates נשאר מוגדר עם סיבית KEK (0x0004) ואינו מנוקה.
• UEFICA2023Status לא מתקדם למצב שהושלם.
• יומן האירועים של המערכת מתעד שוב ושוב את מזהה האירוע 1803, דבר המציין שלא היתה אפשרות להחיל את עדכון KEK.
• המכשיר ימשיך לנסות שוב לבצע את העדכון מבלי להתקדם.

מדוע זה קורה

עדכון ה-Secure Boot KEK דורש הרשאה ממפתח הפלטפורמה של המכשיר (PK), שנמצא בבעלות ה-OEM.

כדי שהעדכון יצליח, יצרן המכשיר חייב לספק ל- Microsoft KEK חתום PK עבור פלטפורמה ספציפית זו. KEK זה החתום על-ידי יצרן ציוד מקורי כלול בעדכוני Windows ומאפשר ל- Windows לעדכן את משתנה KEK של הקושחה.

אם יצרן הציוד המקורי לא סיפק KEK בחתימת PK עבור המכשיר, Windows לא יוכל להשלים את עדכון KEK. במצב זה:

• עדכוני אתחול מאובטח חסומים במכוון.
• ל- Windows אין אפשרות לעקוף את ההרשאה החסרה.
• המכשיר עלול להישאר בלתי מסוגל להשלים לצמיתות את השירות של אישור אתחול מאובטח.

הדבר עשוי להתרחש במכשירים ישנים יותר או שאינם נתמכים שבהם יצרן הציוד המקורי (OEM) אינו מספק עוד עדכוני קושחה או עדכוני מפתח. אין נתיב שחזור ידני נתמך עבור מצב זה.

חזור לראש הדף

אירועי עדכון ומחווני כשל של אישור אתחול מאובטח

כאשר החלת עדכוני אישור אתחול מאובטח נכשלת, Windows מתעד אירועי אבחון שמסבירים מדוע ההתקדמות נחסמה. אירועים אלה נכתבים כאשר לא ניתן להשלים בבטחה את מסד הנתונים של חתימת אתחול מאובטח (DB) או מפתח Exchange (KEK) עקב קושחה, מצב פלטפורמה או תנאי תצורה. התרחישים בסעיף זה מתייחסים לאירועים אלה כדי לזהות דפוסי כשל נפוצים ולקבוע את התיקון המתאים. סעיף זה נועד לתמוך באבחון ובפרשנות של בעיות שתוארו קודם לכן, ולא להציג תרחישי כשל חדשים.

לקבלת רשימה מלאה של מזהי אירועים, תיאורים וערכים לדוגמה, ראה Secure Boot DB and DBX variable update events (KB5016061).

כשל בעדכון KEK (עדכוני DB הצליחו, KEK לא)

התקן יכול לעדכן בהצלחה אישורים ב- Secure Boot DB אך להיכשל במהלך עדכון KEK. במקרה כזה, לא ניתן להשלים את תהליך העדכון של אתחול מאובטח.

מאפייני הבעיה

• אירועי אישור DB מצביעים על התקדמות, אך שלב KEK לא הושלם.
• AvailableUpdates נשאר מוגדר ל- 0x4004 והסיבית 0x0004 אינה מנוקה לאחר הפעלות של כמה משימות.
• אירוע 1795 או 1803 עשוי להתקיים.

פרשנות

• 1795 מציין בדרך כלל כשל בקושחה בעת ניסיון לעדכן משתנה אתחול מאובטח.
• 1803 מציין שאין אפשרות לאשר את עדכון KEK מכיוון שמטען KEK החתום על-ידי PK של יצרן ציוד מקורי אינו זמין עבור הפלטפורמה.

השלבים הבאים

• עבור 1795, בדוק אם קיימים עדכוני קושחה של יצרני OEM ואמת את התמיכה בקושחה עבור עדכונים משתנים של אתחול מאובטח.
• עבור 1803, ודא שיצרן הציוד המקורי סיפק ל- Microsoft את אישור KEK החתום ב- PK הנדרש עבור דגם המכשיר.

כשל עדכון KEK במחשבים וירטואליים אורחים המתארחים ב- Hyper-V

במחשבים וירטואליים של Hyper-V, עדכוני אישור אתחול מאובטח דורשים התקנה של עדכוני Windows של מרץ 2026 הן במארח Hyper-V והן במערכת ההפעלה האורחת.

כשלי עדכון מדווחים מתוך האורח, אך האירוע מציין היכן נדרש תיקון:

• אירוע 1795 (לדוגמה, "המדיה מוגנת מפני כתיבה") שדווח באורח מציין שלמארח Hyper-V חסר העדכון של מרץ 2026 ויש לעדכן אותו.
• אירוע 1803 שדווח באורח מציין שלמחשב הווירטואלי האורח עצמו חסר העדכון של מרץ 2026 ויש לעדכן אותו.

חזור לראש הדף

הפניות ופנימיות

סעיף זה מכיל מידע עיון מתקדם המיועד לפתרון בעיות ותמיכה. הוא אינו מיועד לתכנון פריסה. הוא מרחיב את מכניקת השירות של אתחול מאובטח שסוכמה קודם לכן ומספק חומר עזר מפורט לפירוש מצב הרישום ויומני אירועים.

הערה (פריסות המנוהלות על-ידי מחלקת ה- IT): בעת קביעת התצורה באמצעות מדיניות קבוצתית או Microsoft Intune, אין לבלבל בין שתי הגדרות דומות. הערך AvailableUpdatesPolicy מייצג את מצב המדיניות שתצורתה נקבעה. בינתיים, AvailableUpdates משקף את מצב העבודה המתבצעת ומנקה סיביות. שניהם יכולים להוביל לאותה תוצאה, אבל הם מתנהגים אחרת מכיוון שהמדיניות חלה מחדש לאורך זמן.

חזור לראש הדף

סיביות AvailableUpdates המשמשות למתן שירות אישורים

הסיביות שלהלן משמשות עבור פעולות מנהל האישורים והאתחול המתוארות במסמך זה. העמודה Order משקפת את הרצף שבו המשימה Secure-Boot-Update מעבדת כל סיביה.

הזמנה	הגדרת סיביות	נוהג
1	0x0040	סיבית זו מורה למשימה המתוזמנת להוסיף את אישור Windows UEFI CA 2023 ל- Secure Boot 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 על מסד הנתונים. אופן פעולה מותנה: כאשר דגל 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. כדי להבטיח שפרופיל האבטחה של המכשיר יישאר זהה, סיבית זו מחילה אישורים חדשים אלה רק אם המכשיר נותן אמון באישור UEFI CA 2011 של Microsoft Corporation. לא כל מכשירי Windows נותנים אמון באישור זה.
4	0x0004	סיבית זו מורה למשימה המתוזמנת לחפש מפתח Exchange החתום על-ידי מפתח הפלטפורמה (PK) של המכשיר. ה- PK מנוהל על-ידי יצרן הציוד המקורי. יצרני ציוד מקורי חותמים על Microsoft KEK באמצעות ה- PK שלהם ומספקים אותו ל- Microsoft, שם הוא כלול בעדכונים המצטברים החודשיים.
5	0x0100	סיבית זו אומרת למשימה המתוזמנת להחיל את מנהל האתחול, החתום על ידי Windows UEFI CA 2023, על מחיצת האתחול. זה יחליף את מנהל האתחול החתום של Microsoft Windows Production PCA 2011 .

הערות:

• הסיבית 0x4000 תישאר מוגדרת לאחר עיבוד כל הסיביות האחרות.
• כל סיבית מעובדת על ידי המשימה המתוזמנת Secure-Boot-Update בסדר המוצג לעיל.
• אם אין אפשרות לעבד את הסיבית 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
פועל כ	מערכת (מערכת מקומית)
גורמים מפעילים	בהפעלה וכל 12 שעות
מדינה נדרשת	זמין

כיצד לבדוק מצב משימה

הפעל משורת PowerShell עם הרשאות מלאות:
schtasks.exe /query /TN "\Microsoft\Windows\PI\Secure-Boot-Update" /FO LIST /v

חפש את השדה Status :

מצב	משמעות
מוכן	המשימה קיימת וזמינה.
לא זמין	המשימה קיימת אך חייבת להיות זמינה.
שגיאה / לא נמצא	הפעילות חסרה ויש ליצור אותה מחדש.

כיצד להפוך את המשימה לזמינה או ליצור אותה מחדש

אם שדה המצב עבור עדכון אתחול מאובטח הוא 'שגיאה' או 'לא נמצא', השתמש בקובץ ה- Script לדוגמה כדי להפוך את המשימה לזמינה: Enable-SecureBootUpdateTask.ps1לדוגמה

הערה: זהו קובץ Script לדוגמה ואינו נתמך על-ידי Microsoft. מנהלי מערכת צריכים לסקור ולהתאים אותו לסביבה שלהם.

דוגמה:

הפעל הדרכה

• אם הגישה נדחתה, הפעל שוב את PowerShell בתור מנהל מערכת.
• אם קובץ ה- Script לא יפעל עקב מדיניות ביצוע, השתמש בעקיפת היקף תהליך:

חזור לראש הדף