אתחול והקמת סביבת משתמש¶
נניח שמחשב מגיע למסך כניסה אך שירות מסוים אינו עולה. במקרה אחר הוא מציג הודעה לפני שהלוגו של Windows מופיע. שתי התקלות נקראות בשיחה רגילה בעיית boot, אבל הן נמצאות בשכבות שונות ומאפשרות כלים שונים.
האתחול הוא שרשרת של העברת אחריות. כל שלב מתחיל עם משאבים מוגבלים, מכין את התנאים לשלב הבא ומוסר לו מידע. הבנת השרשרת מאפשרת להסיק אילו רכיבים כבר פעלו ואילו עדיין לא קיימים.
מתחילים לפני שיש תהליך¶
בסביבת UEFI, הקושחה מכינה את החומרה ומפעילה רכיב boot מתאים. מנהל האתחול של Windows בוחר את מסלול ההפעלה ומעביר שליטה לטוען מערכת ההפעלה. הטוען מכין רכיבים שנדרשים כדי להתחיל להריץ את הקרנל.
במחשב PC טיפוסי עם UEFI אפשר לפגוש שמות כמו bootmgfw.efi ו־winload.efi. השמות מסייעים לחקירה, אך התפקיד חשוב יותר מהנתיב המדויק. מסלול resume ממצב שינה עמוקה אינו זהה בהכרח לאתחול קר מלא.
בשלבים האלה עדיין אין סביבת משתמש רגילה עם Explorer ו־services. לכן תקלה מוקדמת אינה ניתנת לתיקון באמצעות שינוי לוגיקה של אפליקציה שעוד לא נטענה.
הטוען אינו המנהל של כל זמן הריצה¶
הטוען מספק לקרנל מידע על זיכרון, רכיבים ותצורת הפעלה. לאחר מכן הקרנל מקים מנגנוני זמן ריצה: ניהול זיכרון, interrupts, תזמון ורכיבי executive. דרייברים נחוצים נטענים לפי שלבי האתחול וההתקנים.
המעבר אינו אומר שכל driver במערכת כבר מוכן. קיימים סוגי התחלה ותלויות שונות. התקן שהדרייבר שלו נטען מאוחר יותר לא אמור להיות מובן ככשל בטוען הראשוני רק מפני שהוא חלק מהחומרה.
בשלב מאוחר יותר נוצרת סביבת משתמש ראשונית, כולל Session Manager ותהליכי מערכת נוספים. השירותים והכניסה האינטראקטיבית מקבלים תשתית של processes, tokens ו־sessions. בפרקים הבאים נעקוב אחר חלק מהאובייקטים האלה מתוך תוכנה שלנו.
אוספים ראיות בלי לשנות boot¶
הניסוי בשיעור הזה הוא קריאה בלבד. ב־PowerShell אפשר לאסוף מידע על מערכת ההפעלה ועל תהליכי מערכת.
Get-CimInstance Win32_OperatingSystem |
Select-Object Caption, Version, BuildNumber, LastBootUpTime
Get-Process -Name smss,csrss,wininit,services,lsass,winlogon -ErrorAction SilentlyContinue |
Select-Object ProcessName, Id, SessionId, StartTime
חלק מהשדות עשויים לדרוש הרשאה שאינה זמינה למשתמש רגיל. חוסר גישה אינו מוכיח שהתהליך אינו קיים. גם סדר StartTime אינו לבדו הוכחה לשרשרת יצירה, במיוחד כשקיימים תהליכים קצרים שכבר יצאו.
לקריאת תצורת האתחול אפשר להשתמש בפקודה הבאה בחלון מתאים. אין בשיעור צורך בפקודות set, בהשבתת Secure Boot או בשינוי הגנות.
הפלט מתאר תצורה שנבחרה, ולא trace של כל מה שהתרחש. אם הפקודה נדחית בגלל הרשאות, רושמים את המגבלה וממשיכים במידע הזמין. אין לשנות מדיניות מכונה רק כדי להשלים תרגיל קריאה.
אמון באתחול אינו אותו מנגנון בכל שכבה¶
מנגנוני Secure Boot מסייעים באימות רכיבים בשרשרת מוקדמת לפי מדיניות הקושחה. מנגנוני code integrity של Windows ממשיכים לאכוף כללים בהמשך החיים. אלה רכיבים קשורים, אך אינם אותה בדיקה בכל רגע.
במערכת שבה VBS פעיל, hypervisor יכול ליצור גבולות אמון וזיכרון מעבר להפרדה הרגילה בין user mode ל־kernel mode. לכן האמירה שכל קוד ב־ring 0 יכול לקרוא כל זיכרון במחשב אינה מודל מספיק למערכת מודרנית כזו.
ה־secure kernel והחלוקה לרמות אמון וירטואליות תלויים בתכונות ובתצורה. אין צורך להשבית אותם כדי להבין את Windows. במקום זאת מתעדים אם הם פעילים, ומפרשים בהתאם את הגבלות הדיבוג והגישה לזיכרון.
חזרה משינה משנה את השאלה¶
כאשר המערכת משחזרת מצב שמור, חלק ממה שנראה כמו אתחול הוא שחזור של מצב קיים. גם Fast Startup יכול להשפיע על מה שנמדד. לכן השוואת זמני boot דורשת להגדיר אם מדובר ב־restart, shutdown והדלקה, או resume.
מדידת זמן עד הופעת שולחן העבודה אינה מודדת בהכרח את סיום כל פעילות הרקע. שירותים יכולים להמשיך להיטען, התקנים יכולים להשלים אתחול, ויישומי משתמש יכולים לייצר עומס נוסף. בפרק כלי הביצועים ננתח trace של boot לפי שלבים.
משייכים תקלה לשלב שיכול להסביר אותה¶
כשל לפני בחירת מערכת הפעלה מחייב חקירה של firmware ומנהל האתחול. כשל בזמן טעינת הקרנל או דרייבר מוקדם דורש ראיות אחרות. כשל שירות אחרי כניסה יכול להיות בעיית הרשאות, תלות או תצורה של השירות עצמו.
הדרך הנכונה היא לנסח השערה שמוגבלת לשלב, ואז לחפש ראיה שמפריכה או מחזקת אותה. אין לבחור תיקון מפני שהוא מופיע במדריך כללי לבעיות boot. בקורס נלמד לבצע ניסויי קרנל רק ביעד נפרד עם אפשרות שחזור.
לקריאה נוספת: שלבי האתחול וחקירת תקלות Windows, תצורת boot וגבולות אמון של Virtual Secure Mode.