הקדמה
אם קיבלתם הודעת שגיאה בעת תהליך ה- Boot, או שמא, בתהליך ה- Logon לתחנה או לאחר ביצוע ה- Logon חשתם בבעיה מסוימת, ב"תקיעות" (Hangs), או בבעיות נוספות המתרחשות בעת ה- Boot ו\או ה- Startup, מאמר זה יספק לכם מידע אודות תהליכים אלו וכיצד ניתן לאבחן תקלות במקרים אלו.
מרבית התקלות בתהליכים אלו (תהליך ה- Boot וה- Startup), מתרחשות עקב הגורמים הבאים בד"כ:
1. אפליקציות ו"דרייברים" של יצרן צד ג' – ייתכן ויצרן צד ג' לא התאים את ה"דרייבר" או האפליקציה שלו בצורה מלאה ל- Windows.
2. קבצי מערכת מושחתים או פגומים – עקב באגים ב"דרייברים" ובעיות חומרה ניתן לסבול מתופעה בה קבצים פגומים ולא מתפקדים כנדרש מהם.
3. וירוסים ו- Malware – קוד זדוני עלול לחבל בתהליך הסטנדרטי של הפעלת Windows.
במדריך זה המחולק למספר חלקים, נדון בדרך השלילה, דרך המיועדת לאפשר לבודד את הבעיה ע"י ניתוח ואבחון מדויק ככל שניתן של הבעיה, וכל זאת ע"מ לחסוך שימוש בפתרון ה"קל" – התקנה מחודשת של המערכת.
בכדי לאבחן את התקלות בצורה טובה יותר, יש להבין את מהלך ההפעלה של Windows, אשר יוצג אף הוא במאמר זה.
ביאור מושגים
לפני שנתחיל אציג בפניכם מס' תיאורים שמיקרוסופט משתמשת בהם לתיאור ה- Boot Volume וה- System Volume, הם התיאורים הכי מוזרים שראיתי, ואם אתם מבולבלים, אל דאגה! גם אנחנו...
System Volume – ה- Volume אשר מכילה את קבצי ה- Boot; דוגמה לקבצי Boot שניגע בהם בהמשך הם ה- MBR, סקטור ה- Boot (ה- Boot sector), NTLDR, NTDETECT.COM ו- BOOT.INI.
Boot Volume – ה- Volume אשר מכילה את קבצי המערכת (System files) דוגמת ספריית WINDOWS.
מבולבלים? גם אנחנו...
הבנת תהליך ה- Boot
ברגע בו לחצתם על כפתור ה- Power של המחשב, יופיע ככל הנראה תהליך ה- POST, לא נכנס לתהליך זה לעומק, אך נזכיר כי שלב ה- Power On Self Test (POST) הינו תהליך אשר ה- BIOS מבצע בכדי לבדוק את המרכיבים הפיזיים (לוח, זיכרון, מעבד, דיסק קשיח וכו') ואת תקינותם; במקרה של תקלה תופיע הודעה מתאימה על המסך בהתאם להגדרות יצרן ה- BIOS.
Master Boot Record וה- Boot Sector
לאחר שעברנו את שלב ה- POST בהצלחה, ה- BIOS יקצה משאבי חומרה לרכיבים ומיד לאחר מכן קיימת הפנייה מן ה- BIOS אל ה- Master Boot Record, או MBR בקצרה;
פלטפורמות החומרה הזמינות כיום בשוק, הן x86 והן x64 מתוכנתות לקרוא את הסקטור (Sector) הראשון של הדיסק שמסומן כ- Active לזיכרון (המוכר גם בשם Physical Primary Disk), ומתחילות להריץ פיסת קוד שקרויה MBR. מטרתה של פיסת הקוד הזו לקרוא את ה- Partition Table שעל הדיסק האקטיבי אשר מכילה ארבעה ערכים שמציינים את מיקום ה- Volumes שבדיסק הפיזי. אחד מהערכים שקיימים בטבלה הוא מעין מצביע על המחיצה האקטיבית (Active Partition) שבדיסק, שהיא למעשה ה- System Volume. לאחר שנמצאה ה- System Volume ה- MBR פונה אל הסקטור הראשון שב- System Volume וטוען אותו לזיכרון ומתחיל להריץ אותו, הסקטור הראשון שב- System Volume מוכר גם בשם Boot sector.
ה- Boot sector למעשה מכיל את פיסת הקוד הראשונה מאז ההפעלה שמזוהה עם מערכת ה- NT שלכם, פיסת הקוד הקטנה הזו מכילה מידע מספיק לגבי ההבנה של איזו מערכת קבצים עושה שימוש בדיסק (FAT, FAT32, NTFS) ולכן היא פיסת הקוד הראשונה המזוהה עם מערכת ה- NT שלכם. ה- Boot sector עושה שימוש במערכת קבצים פרימיטיבית שהינה לקריאה בלבד אשר מספיקה לבצע איתור וקריאה של תיקיית השורש (Root Directory) של ה- Volume, ואיתור וטעינה של קובץ ה- NT Boot Loader, אשר מוכר לכם ככל הנראה בשם NTLDR.
באם נרצה לחפש את הקובץ NTLDR על ה- System Volume שלנו, ניגש תחילה ל- Root (\), ונמצא בין מכלול הקבצים שב- Root קובץ מוסתר העונה לשם NTLDR (ראה איור).
ה- Boot Loader
ל- NT Boot Loader מס' פעולות שעליו לבצע, הראשונה היא שינוי "מצב" (mode) העבודה של המעבד (CPU) מ- 16-bit ל- 32-bit; כל המעבדים עובדים תחילה במצב 16-bit בשביל לאפשר תמיכה אחורה ותאימות מלאה למערכות ישנות דוגמת DOS. לאחר שינוי "מצב" עבודת המעבד ל- 32-Bit הפעולה הבאה של ה- NT Boot Loader היא אפשור Paging, נא לא להתבלבל! אין שום קשר ל- Paging file; הכוונה באפשור Paging היא לייצור זיכרון וירטואלי (Virtual Memory) אשר ממפה ישירות כתובות זיכרון וירטואליות לזיכרון הפיזי, כך שהמערכת תוכל לגשת לזיכרון הפיזי שקיים במערכת.
בשלב זה, ה- NT Boot Loader בודק את קיומו של הקובץ NTBOOTDD.SYS ב- Root Directory, אם הקובץ קיים, ה- NT Boot Loader יבצע טעינה שלו. קובץ ה- NTBOOTDD.SYS יהיה קיים אך ורק במצבים מסוימים דוגמת מצב בו ה- System Volume יושבת על דיסק פיזי נפרד מזה שעליו יושבת ה- Boot Volume, ועל ה- Boot Volume לשבת על דיסק SCSI. הסיבה לחיפוש הקובץ NTBOOTDD.SYS וטעינתו נובעת מכך שדיסקים הפועלים על-גבי ממשק SCSI דורשים "דרייברים" מתאימים לאינטראקציה ושליחת פקודות לחומרה מבוססת ממשק SCSI. בניגוד לחומרה הסטנדרטית אשר מתוכנתת לקרוא ישירות מה- Physical Primary Disk.
השלב הבא של ה- NT Boot Loader הוא לקרוא את הקובץ BOOT.INI מה- Root Directory, קובץ ה- BOOT.INI הוא קובץ טקסט המכיל רשימה של מערכות ההפעלה אשר מותקנות על המחשב עם הפרמטרים של המערכות ספציפית (דוגמה קלה להבנה היא האופציה /3GB, מידע נוסף אודות הפרמטרים שניתן לשלב למערכות ב- Boot.ini ניתן למצוא במאמר 833721 של מיקרוסופט), כמו כן, על-מנת להבין מה מכיל BOOT.INI מצורף צילום של הקובץ כפי שהוא נראה ב- Notepad (ראה איור).
במידה ויש יותר ממערכת אחת על המחשב, יוצג תפריט לבחירה בין המערכות עם מגבלת זמן (Timeout), כאשר אם המשתמש לא יבחר במערכת מסוימת בתום מגבלת הזמן תיטען המערכת שסומנה כברירת מחדל.
לאחר שבוצעה הבחירה איזו מערכת הפעלה תיטען, ה- NT Boot Loader בודק איזו מערכת נבחרה, במידה והמערכת שנבחרה היא מערכת 64-bit ה- NT Boot Loader יבצע שינוי "מצב" של עבודת המעבד ל- 64-bit מ- 32-bit. גם במקרים בהם מותקנת אך ורק מערכת 64-bit יתבצע שינוי מ- 32-bit ל- 64-bit, כאשר כל תהליך ההמרה קורה עקב יכולות החומרה לעבוד במצב x86-x64.
כעת, ה- NT Boot Loader "עוצר" בקצרה מעבודתו בכדי לאפשר למשתמש לעצור את תהליך ה- Boot הרגיל וללחוץ על מקש ה- F8 בכדי לבצע Boot מיוחד (אם צריך) מתפריט ה- Advanced Options (ראה איור).
הן במידה ובחרתם באפשרות Boot "מיוחד" והן במצב בו אינכם לחצתם על F8 ואפשרתם ל- NT Boot Loader להמשיך במלאכתו, ה- NT Boot Loader יבצע עתה זיהוי חומרה (BIOS Hardware Detection) באמצעות הקובץ NTDETECT.COM, אשר גם הוא קובץ חבוי ב- Root directory בדומה ל- NTLDR; הקובץ NTDETECT.COM יבצע את זיהוי החומרה, וידווח על כך ל- NT Boot Loader; כמו כן, ה- NTDETECT.COM שומרת את המידע אודות החומרה שזיהתה בזיכרון וכשה- Registry נטען היא מעתיקה את המידע ל- HKLM\Hardware\Description (ראה איור), שם ניתן למצוא מידע בסיסי אודות המעבד, ה- BIOS, הדיסק והתקנים בסיסיים נוספים.
כעת קיימת קריאה וטעינה של Hives מה- Registry תחת HKLM\SYSTEM, קטע זה בתהליך ה- Boot הכרחי מכיוון שקיימים Hives שמכוונים על תהליך הטעינה דוגמת הגדרות של מערכת ההפעלה שנשמרו ב- Registry, וקונפיגורציה של "דרייברים". לאחר הקריאה והטעינה מה- Registry מתבצע תהליך טעינת "דרייברים" אשר הכרחיים לפעולת מערכת ההפעלה לזיכרון, "דרייברים" אלו קרויים Boot start drivers והם חייבים להיטען בשלב זה ולא מאוחר יותר ע"י ה- Kernel (גרעין המערכת), הסיבה לכך היא שה- Kernel יצטרך להפעיל את השירותים שה"דרייברים" הללו מספקים בשביל להפעיל את ה"דרייברים", דבר בעייתי – הרי לא ניתן לקרוא לשירות שמסופק על-ידי "דרייבר" מבלי לטעון תחילה את ה"דרייבר" שמספק את השירות.
לאחר טעינת ה"דרייברים", NT Boot Loader טוען את ה- NTOSKRNL.EXE ואת ה- DLLs שלו (אשר ביניהם גם HAL.DLL) אל הזיכרון. וכאן בעצם ה- NT Boot Loader מסיים את עבודתו ומעביר את הפעולה אל ה- NTOSKRNL.EXE.
מערכת ההפעלה
כעת, מסך ה- Splash מופיע (ראה איור), עכשיו בכל פעם שתראה את מסך ה- Splash תוכל לדעת בוודאות כי עבודתו של ה- Boot Loader הסתיימה.
כעת, ה- Windows Kernel מכין את עצמו בשני שלבים:
השלב הראשון – השלב הראשון, הקרוי בספרות המיקרוסופטית Phase0 – ומעתה ואילך אשתמש ב- Phase0 ככינוי לשלב השני, המערכת קוראת לפונקציות מפתח בתת המערכת הראשית (Major sub-system) כמו תהליכים (Processes) ות'רדים (Threads), Memory Manager, מערכות קלט\פלט (I/O) וכדומה על-מנת לבצע בניית מידע בסיסית (Basic data structure) אשר תהיה זמינה לשימוש.
השלב השני – השלב השני, הקרוי בספרות המיקרוסופטית Phase1 – ומעתה ואילך אשתמש ב- Phase1 ככינוי לשלב השני, הוא השלב בו נקראות ה- sub-systems הפנימיות לצור אובייקטים ומתחילה בעצם ריצה של המכניזם המרכזיים (core support mechanism) ב- Kernel. כמו כן חלק מ- Phase1 הוא להפעיל את ה "דרייברים" אשר נטענו ע"י ה- NT Boot Loader (ה- Boot start drivers), במידה ו- Boot start driver לא יתפקד כראוי עלול בשלב זה להיווצר מסך כחול.
לאחר הפעלת ה- Boot start drivers מערכת הקלט\פלט (I/O system) פונה ל- Registry במטרה לאתר אילו "דרייברים" מסומנים כ- System-start, אלו "דרייברים" נוספים החיוניים לתהליך הטעינה, והם נטענים מהדיסק בשלב זה.
לידע כללי: לכל ה"דרייברים" והשירותים הקיימים במערכת קיימים מפתחות ייחודיים ב- Registry, אשר נמצאים תחת HKLM\System\CurrentControlSet\Services.
מערכת ההפעלה, וכך גם אנחנו, נזהה "דרייברים" ושירותים לפי ערך ה- Type, כאשר ב- Type יצויין הערך 1 או 2, נוכל לזהות כי מדובר ב"דרייבר", באם ה- Type יכיל ערך אחר שאינו 1 או 2 מדובר בשירות.
לדוג' באיור ניתן לראות בבירור דרייבר (ערך ה- Type הוא 1).
מלבד זאת, ל"דרייברים" ושירותים יש סדר פעולה, אך מתי ה- NT Boot Loader יודע לטעון את ה"דרייברים" הספציפיים שהם בעצם ה- Boot-start drivers, ואיך יודעים אילו "דרייברים" הם ה- System-start drivers או אילו שירותים יש להפעיל בצורה אוטומטית? התשובה לכך היא שב- Registry קיים ערך נוסף עבור כל שירות ו"דרייבר" הקרוי Start, והוא מגדיר את השירות\"דרייבר".
אלו האפשרויות הקיימות לערך ה- Start שלפיהן ניתן לדעת מה סדר הפעולה של "דרייבר"\שירות מסוימים:
בכדי לראות בצורה נוחה וקלה יותר את סדר הפעלתם של השירותים והדרייברים במערכת, ניתן להשתמש ב- LoadOrd מבית Sysinternals.
ב- LoadOrd ניתן לראות בבירור לפי ה- Start value את סדר הפעולה של ה"דרייבר"\שירות, ולקבל מידע נוסף אודותיו כמו מה שמו (Display Name) איזה סוג "דרייבר"\שירות הוא, והיכן הוא ממוקם (קבלת נתיב מלא של מיקום הקובץ בדיסק).
עוד אפשרות להציג את המידע הנ"ל בצורה נוחה הוא להשתמש ב- MSInfo32, תחת Software Environment יש לבחור ב- System Drivers, וניתן למפות לפי ה- Start Mode את ה"דרייברים" (ראה איור).
כעת, לאחר שכל ה"דרייברים" הופעלו המערכת סיימה את שלב ה- Kernel initialization וכעת, ייווצר ה- Process הראשון ב- User Mode - הקרוי Session Manager (ניתן למצוא אותו בשם SMSS.EXE תחת Task Manager, ראה איור).
Session Manager
ה- Session Manager הוא כפי שציינתי, ה- Process הראשון בסביבת User-mode, משמע, הוא האב של התהליכים שייווצרו בהמשך, ה- Session Manager משתמש במפתח Registry שנמצא ב- HKLM\SYSTEM\CurrentControlSet\Control\Session Manager בכדי לבצע את הפעולות שכפופות לו, את הפעולות שה- Session Manager מבצע ניתן לראות בקלות תחת מפתח זה, לדוג' הקצאת Paging file (ראה איור).
כמו כן, ה- Session Manager מריץ את כל התוכניות שמוגדרות בערך BootExecute (ראה איור).
ה- Autocheck הוא שירות של מערכת ההפעלה שמבצע סריקת דיסק (Check Disk), אשר ה- Session Manager מריץ כתהליך צאצא כל הפעלה, בזמן הצגת מסך ה- Splash. ניתן למצוא עדויות ל- Autocheck כאשר יש שגיאה בדיסק, כמו באיור המוצג.
כמו כן, ה- Session Manager אמון על החלפה, עדכון ושינוי שמות קבצים, ישנם מספר קבצי מערכת שלא ניתן להחליפם\לשנות את שמם בצורה המוכרת לנו, לדוג' DLL מרכזי של מערכת ההפעלה כמו KERNEL32.DLL. כך, במקרה של התקנת Hotfix או Service Pack נעשה לרוב שינוי במספר קבצי מערכת, ובכדי שהשינויים יחולו יש לבצע הפעלה מחדש, במהלך ההפעלה מחדש ה- Session Manager יחליף\יעדכן\ישנה את שמות הקבצים בהתאם ל- Hotfix/Service Pack, כך שהשינויים אכן יחולו על המערכת.
בדרך כלל כשתופיע בפנייך בקשה להפעלה מחדש לאחר התקנת תוכנה\עדכון, ייעשה שינוי דרך ה- Session Manager.
לידע כללי: אם ברצונך לראות מה Session Manager שינה במערכת לאחר שהתקנת עדכון\תוכנה, תוכל להשתמש ב- PendMoves של Sysinternals.
לאחר מכן, ה- Session Manager יפעיל את שאר ה- Registry, כלומר יטען את ה- Hives הנוספים. ויטען ויפעיל את ה"דרייבר" WIN32K.SYS, אשר מהווה את החלק הראשון מה- Windowing System, ה"דרייבר" מממש את ה- GDI, ואת ה- Windowing.
הערה: גם במערכות 64-bit ה"דרייבר" קרוי WIN32K.SYS...
החלק השני של ה- Windowing System, אשר מזוהה ברמת ה- User mode, שמופעל ע"י ה- Session Manager הוא תהליך ה- CSRSS.EXE, אשר מוכר גם כ- Microsoft Client/Server Runtime Server Subsystem, לאחר שה- CSRSS.EXE מופעל ה- Windows API זמין לשימוש בידי תהליכים אחרים.
כעת, WINLOGON.EXE מופעל.
Windowing System
כעת, ה- CSRSS.EXE מפעיל את ה- Windowing System, והמערכת עוברת לאחר המסך השחור אשר נמצא לכמה שניות אחרי מסך ה- Splash למצב בו נעשה שימוש ב- GUI.
לאחר כניסה למצב GUI, סמן העכבר מופיע ראשון.
כעת, ה"משימה" אמונה בידי תהליך ה- Logon וה- Security Server.
תהליך ה- Logon וה- Security Server
כעת Winlogon "לוקח" את המושכות לידיו, ומפעיל את תהליך ה- LSASS.EXE, ה- Local Security Authority, ה- LSASS.EXE אחראי על ביצוע אימות (Authentication) מקומית למחשב, כך שבעצם משתמש המבצע Logon למכונה בצורה מקומית דרך הכנסת שם משתמש וסיסמא, או בפנייה מרחוק ברשת למחשב עובר דרך LSASS.EXE.
לאחר הפעלת LSASS.EXE, Winlogon טוען את ה- GINA (ראשי תיבות של Graphical Identification and Authentication), ה- GINA הוא קובץ DLL (MSGINA.DLL) שאחראי על הצגת החלון הגראפי של ה- Logon (ראה איור).
לידע כללי: בנוסף ה- GINA אחראית על אותו חלון המסומן כ- Windows Security המוצג בעת לחיצה על Ctrl+Alt+Delete.
כעת, Winlogon מפעילה את SERVICES.EXE – ה- Service Control Manager (או SCM).
Service Startup
ה- SCM מקבל לידיו את הטיפול רגע לפני שאתה, המשתמש, תשתמש במערכת ההפעלה; ומפעיל את כל ה- Services שמסומנים לעלות במצב Automatic (שערכם ב- Registry הוא 2), בדרך כלל מרבית ה- Services שה- SCM יטען הם User-mode processes (SVCHOST.EXE, SPOOLSV.EXE וכו'), ולעיתים (תלוי בתצורת התוכנה שבמחשב) יטענו גם Kernel mode drivers דוגמת ה"דרייברים" הכלולים בתוכנות צריבה.
לסיכום
בחלק זה של המדריך הוצג תהליך ה- Boot על קצה המזלג אשר ניתן לחלקו למס' חלקים עיקריים:
1. שלב ה- POST
2. MBR וה- Boot Sector
3. NT Boot Loader
4. מערכת ההפעלה
5. ה- Session Manager
6. תהליך ה- Logon וה- Security Server
7. Service Startup
כאשר בכל חלק, קיים סדר פעולה מסוים אשר עובר ממבצע עיקרי אחד לשני, ובכך עוברים שלב-אחר-שלב.
בחלק הבא אדון ב- Recovery Console. מקווה שנהניתם.אשמח לשמוע הערות והארות לגבי המדריך ובכלל סתם פידבק :-).