לדלג לתוכן

שיעור 15: דיאגנוסטיקה

חלק א': מאגר ידע למדריך

1. עיקרון הבידוד (Isolation)

1. High-Level Theory & History

הגישה המסורתית של אפל לפתרון תקלות נקראת Systematic Troubleshooting (פתרון תקלות שיטתי), אשר שמה דגש על עיקרון הבידוד (Isolation) במקום פתרון מבוסס ניסוי וטעייה. ההיסטוריה של פתרון תקלות ב-macOS עברה מאנרכיה של ניסיונות תיקון הרשאות דיסק (פרקטיקה נפוצה בימי OS X הישנים), למתודולוגיה מסודרת שבה "מרחב הבעיה" נחתך לחצי שוב ושוב. האם הבעיה קשורה למשתמש הספציפי או לכלל המערכת? האם מדובר בבעיית חומרה או תוכנה? האם הבעיה קורית רק ברשת ספציפית? כלי ניטור כמו Activity Monitor, יחד עם ה-Console ו-Wi-Fi Diagnostics, מהווים את הבסיס להבנת הבעיה ולצמצומה לרכיב הבודד שכשל, לפני שמתחילים לבצע שינויים או תיקונים כלשהם.

[!TIP] הידעת? (History - Activity Monitor & Logs): בימי ה-Classic Mac OS, הדאגה המרכזית הייתה לרוב ניהול זיכרון ולא ביצועי ה-CPU. כלי ה-Activity Monitor המוכר לנו היום לא היה קיים, ורק עם הגעת Mac OS X הופיעו הכלים "Process Viewer" ו-"CPU Monitor" (שאוחדו ל-Activity Monitor בשנת 2003). בגרסאות אלו המערכת הריצה רק כ-34 תהליכי רקע בהשוואה למאות כיום, כך שבידוד תקלות היה קל משמעותית! כמו כן, ה-Console עבד מול קבצי טקסט פשוטים עד macOS Sierra (2016), אז החליפה אותם ה-Unified Logging System המהירה והמורכבת יותר.

בסביבות macOS מודרניות, במיוחד ב-macOS 26 Tahoe, מורכבות מערכת ההפעלה דורשת ממנהלי המערכת ליישם בידוד לוגי קפדני. כאשר אפליקציה הופכת ללא תגובתית, במקום להתקין מחדש את מערכת ההפעלה באופן מיידי, על טכנאי ה-IT לקבוע תחילה את ההיקף. בידוד כולל יצירת משתמשי בדיקה, הפעלה למצבים ספציפיים ושימוש בכלי עזר לאבחון כדי לשלול משתנים. שאלת היסוד תמיד נשארת: האם ניתן לבודד בעיה זו לקובץ בודד, לחשבון משתמש יחיד, להרחבת צד-שלישי ספציפית או לתנאי רשת מסוים?

2. Deep Technical Architecture

ארכיטקטורת ה-macOS מגבילה באופן טבעי את "רדיוס הפגיעה" של תקלות באמצעות מנגנון Sandbox (ארגז חול) והפרדה בין תהליכים ברמת משתמש לעומת תהליכי מערכת (User Space vs. System Space). כאשר נצפית צריכת משאבים חריגה ב-Activity Monitor, עיקרון הבידוד מתחיל בניתוח של מי הבעלים של התהליך: האם זהו LaunchAgent (הרץ בסביבת המשתמש בלבד) או LaunchDaemon (הרץ ברמת ה-root כחלק מה-System Space)?

בנוסף, אדריכלות ה-Unified Logging System אוספת נתונים בזמן אמת לתוך חוצצי זיכרון (Memory Buffers) ולדיסק, ומאפשרת בחינה מדוקדקת ב-Console. בהקשר הרשתי, ארכיטקטורת ה-Wi-Fi מפרידה את שכבת החומרה משכבת התוכנה. רוב תעבורת האלחוט ומצב הקישוריות מנוהלים על ידי תהליך רקע בשם airportd, מה שמאפשר לבודד בעיות קישוריות על ידי איסוף דיאגנוסטיקה אלחוטית מקיפה מבלי להפריע למצב החומרה שמתחת.

[!NOTE] Deep Dive 🤿: מה Activity Monitor באמת מודד? במחשבי Apple Silicon, הנתונים המוצגים בעמודות השונות עשויים לעיתים להטעות ואינם תמיד משקפים נתונים פיזיקליים מדויקים:

  • CPU %: ערכים יכולים לחצות בקלות את ה-100% (כל ליבה נספרת כ-100%). המדידה אינה מייצגת במדויק את העומס הפיזי המדויק על המעבד עקב חלוקת העבודה בין ליבות היעילות (E-cores) לליבות הביצועים (P-cores). Activity Monitor מחשב את ה-CPU % על ידי חיבור אחוז התושבות הפעילה (active residency) של כל ליבת מעבד. באופן קריטי, הנתון אינו לוקח בחשבון את תדר הפעולה. מכיוון ש-P-cores פועלות בתדרים גבוהים בהרבה מ-E-cores, ליבת E שמדווחת על 100% שימוש מבצעת חלק זעיר מהעבודה של ליבת P המדווחת על 100%. לכן, מדד ה-CPU % נותר מטעה ביסודו ב-Apple Silicon.
  • Energy Impact: הנתון אינו צריכת חשמל חשמלית בוואט, אלא ציון יחסי ("Score") המחושב על ידי אלגוריתם היוריסטי להערכת צריכת סוללה יחסית. מדד ה-Energy Impact מבוסס בעיקר על צריכת החשמל של ליבות ה-CPU ואינו לוקח בחשבון את משך המשימה. והכי חשוב, הוא משמיט לחלוטין את צריכת החשמל של ה-GPU. הדבר מגביל מאוד את השימושיות שלו כאשר מנתחים עומסי עבודה מורכבים כמו הרצת בינה מלאכותית (AI) מקומית או עיבוד וידאו, הנשענים במידה רבה על ה-GPU או ה-Neural Engine.
  • טיפ להדרכה: הדגישו לתלמידים שמטרת הכלים הללו ב-macOS המודרנית היא פשוט למצוא חריגות קיצוניות ("Runaway Processes") ולא לשמש כבנצ'מארק מדויק. כאשר נדרשים מדדי חומרה עמוקים, כלי ה-CLI בשם powermetrics הוא מקור האמת היחיד.

3. Terminal Commands, Plists & Logs

בעוד שממשק Activity Monitor الجרפי מצוין להצצה מהירה, ממשק שורת הפקודה (CLI) מספק גישה גולמית ולא מסוננת לדיאגנוסטיקה של המערכת.

  • ניתוח תהליכים ב-Activity Monitor דרך CLI: פקודת הדגימה מאפשרת לחלץ את המצב המדויק של תהליך, על ידי לקיחת תמונת מצב של ה-thread stack traces שלו. פעולה זו זהה לבחירה ב-"Sample Process" בממשק הגרפי. sample <pid> 10 10 -file /tmp/process_sample.txt

  • סינון לוגים במערכת: שימוש ממוקד לאיתור שגיאות ובידוד מקור הקריסה. ה-Unified Logging System נשענת במידה רבה על פסוקיות התניה (Predicates). log show --predicate 'eventMessage contains "error"' --last 5m

  • יצירת Spindumps: אם אפליקציה תקועה לחלוטין (unresponsive), ניתן ליצור spindump כדי לנתח למה האפליקציה ממתינה. sudo spindump <pid> -file /tmp/spindump.txt

  • הפעלת דיאגנוסטיקה אלחוטית מוסתרת: בעוד שהממשק הגרפי נגיש על ידי Option+קליק על סמל ה-Wi-Fi בשורת התפריטים (ובחירה ב-Wireless Diagnostics), ניתן לאסוף מידע אלחוטי מפורט בטרמינל.

  • נתיבי דיאגנוסטיקה: לאחר סיום תהליך האבחון האלחוטי, מיוצר קובץ אוסף בנתיב: /var/tmp/ (או על ה-Desktop) בפורמט .tar.gz. ארכיון זה מכיל לוגים נרחבים, קבצי plist ומידע על מצב ממשק הרשת.

  • גישה לדו"חות קריסה: macOS מייצרת קבצי .ips (Crash Reports) כאשר אפליקציה קורסת בפתאומיות. ניתן לצפות בהם ב-Console או לגשת ישירות ל-~/Library/Logs/DiagnosticReports/ או /Library/Logs/DiagnosticReports/.

4. Edge Cases & Troubleshooting

מקרי קצה הקשורים לבידוד מתרחשים כאשר תקלה פוגעת בכל המשתמשים, אך לא ניתן לשחזר אותה במצב בטוח (Safe Mode). הדבר מעיד בבירור שהבעיה נובעת מהרחבת מערכת צד-שלישי עמוקה (כמו אנטי-וירוס, סוכן EDR או כלי MDM שמשפיע מערכתית).

  • דליפות זיכרון באפליקציות (App Memory Leaks): תופעה הגורמת לאיטיות קשה במק (אך ללא הפעלת מאווררים, בניגוד לעומס CPU). בעזרת מעקב ב-Activity Monitor (לשונית Memory), ניתן לזהות תהליך שטביעת הזיכרון שלו הולכת ומתרחבת. בניגוד לשימוש טבעי שבו הזיכרון חוזר למערכת כשסוגרים חלון, בדליפה הזיכרון פשוט "נאכל" ולא משתחרר. הפתרון המידי הוא Quit או Force Quit לאפליקציה ופתיחתה מחדש.
  • דליפות זיכרון בקרנל (Kernel Memory Leaks): בעוד שדליפות באפליקציות גורמות לרוב רק לאיטיות, דליפת זיכרון ברמת הליבה (לרוב בגלל Kernel Extensions של צד-שלישי או באגים בדרייברים) לרוב מובילה לקריסה (Kernel Panic) כיוון שהיא ממצה אזורי זיכרון קריטיים (Mach zones) השמורים למערכת (zone map exhausted). במקרים אלה Activity Monitor לא יעזור; תחת זאת, נדרש איתור ה-panic log והסרת ההרחבה התקולה.
  • תהליכים סוררים (Runaway Processes): אם המק מתחמם או חווה איטיות קיצונית, יש לבדוק את לשונית ה-CPU לאיתור תהליכים "סוררים" שצורכים אחוז גבוה בצורה בלתי רגילה מקיבולת המעבד, תוך זכירה של הניואנסים של Apple Silicon לפיהם ליבות E וליבות P מטופלות באופן שווה במונחים של אחוזים.

מקרה קצה מרתק נוסף הוא קריסה פתאומית בה מרחב המשתמש אינו רלוונטי כלל, ועל הטכנאי לבודד אם מדובר ברכיב חומרה פגום או דרייבר בעייתי. בדומה לכך, בעת בידוד בעיות קישוריות (כמו נפילות Wi-Fi), הבעיה לרוב נמצאת בתשתית הרשת (למשל, Captive Portal שלא נטען כראוי) ולא במק עצמו.

2. כוחו של ה-Safe Mode

1. High-Level Theory & History

מצב בטוח (Safe Mode / Safe Boot) הוא אחד מכלי האבחון הוותיקים והקריטיים ביותר, הקיים עוד מימי Mac OS X המוקדמים. היסטורית, תפקידו היה להעלות את המערכת בסביבה מינימלית, תוך נטרול הרחבות קרנל (Kexts) חיצוניות ומטמוני גופנים (Font Caches) שהיו נוטים להשחית את המערכת.

במחשבי Apple Silicon המודרניים (המריצים את macOS Tahoe), ה-Safe Mode משמש לא רק כסביבת בידוד מוחלטת להפרדה בין רכיבי תוכנה של אפל לרכיבי צד-שלישי, אלא גם כפעולת תחזוקה אקטיבית, אשר מתקנת תקלות מערכת בעצם תהליך ההפעלה אל תוכו. זהו אולי הצעד הראשון והעוצמתי ביותר העומד לרשות מנהל רשת בפתרון תקלות.

2. Deep Technical Architecture

מבחינה טכנית נמוכה, בעת אתחול למצב בטוח (Safe Boot), המערכת מבצעת בדיקה עצמית לוגית ותיקון שגיאות ב-Volume האתחול באמצעות הפעלת מנוע ה-fsck_apfs ברקע (על ה-Data Volume, שכן ה-Sealed System Volume חתום קריפטוגרפית ומוגן מפני שינויים).

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

ברמת הליבה וספריות המערכת, המערכת משליכה אקטיבית מטמונים דינמיים. היא מוחקת Kernel Caches, מטמוני גופנים, ומטמונים של ה-Dynamic Loader (dyld), ומאלצת את המערכת לבנות אותם מחדש מאפס. כמו כן, האצת חומרה (Metal Hardware Acceleration) לרוב מנוטרלת, ולכן תהליך ה-WindowServer רץ במצב תצוגה גיבוי בסיסי (Fallback Display Mode). היעדר האצת GPU זה בדיוק מה שגורם לחוויית המשתמש להרגיש "איטית", מקרטעת וכבדה מאוד בזמן שהייה ב-Safe Boot.

3. Terminal Commands, Plists & Logs

  • בדיקת מצב Safe Mode מתוך הטרמינל: sysctl kern.safeboot (יחזיר ערך 1 אם המחשב נמצא כעת ב-Safe Mode, ו-0 אם במצב רגיל).

  • כניסה למצב בטוח במחשבי Apple Silicon: בניגוד לעבר בו הוחזק מקש ה-Shift בעת ההדלקה, כיום יש ללחוץ ולהחזיק את כפתור ההפעלה עד להגעת למסך ה-Startup Options. אז, יש לבחור את ה-Volume הרצוי (למשל Macintosh HD), להחזיק את מקש Shift רצוף, וללחוץ על "Continue in Safe Mode".

  • זיהוי Safe Mode דרך ה-GUI: כאשר המשתמש מחובר, יופיע כיתוב אדום ובולט "Safe Boot" בפינה הימנית העליונה בשורת התפריטים, המבהיר למשתמש או לטכנאי באיזה מצב המחשב נמצא.

[!TIP] פקודת NVRAM (למחשבי אינטל בלבד - היסטורי): בעבר ניתן היה לכפות עלייה ב-Safe Mode על ידי כתיבה ל-NVRAM. sudo nvram boot-args="-x" במחשבי Apple Silicon, פעולה זו מנוהלת ומאובטחת בקפדנות על ידי ה-Startup Security Utility וה-LocalPolicy, מה שהופך שינוי ישיר של NVRAM למטרה זו למיושן וחסום לרוב.

4. Edge Cases & Troubleshooting

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

מקרה קצה מעניין בפתרון תקלות: אם המחשב סובל מקפיאות (Freezes) חוזרות או מ-Kernel Panics במצב רגיל, אך פועל ביציבות מושלמת במצב בטוח (Safe Mode), הוכח בבידוד מוחלט שהבעיה טמונה בתוכנת צד-שלישי (למשל סוכן ארגוני סורר או דרייבר תקול), ולא בחומרה או בקבצי מערכת הליבה.

פעמים רבות, עצם העלייה ל-Safe Mode וביצוע ה-Restart חזרה למצב רגיל, פותרים תקלות תצוגה וביצועים בזכות ניקוי ה-Caches האגרסיבי והאוטומטי שהתרחש מאחורי הקלעים.

3. חקירת המערכת באמצעות System Information (GUI)

1. High-Level Theory & History

למרות הגישה הגרפית והנקייה של macOS ב-System Settings, כלי ה-System Information (שנקרא בעבר System Profiler) מציע יכולות סריקה וחקירה מקיפות שאינן מושפעות מתקלות ברמת הממשק הגרפי. פקודת system_profiler והממשק הגרפי המקביל שלה היו מאז ומתמיד נשק הסודי של תומכי IT. הם מאפשרים לייצר דוחות עמוקים על מצב החומרה, התוכנה והרשת מבלי להסתמך על חוויית המשתמש המקומית.

בעוד ש-Activity Monitor בוחן את המצב הדינמי (מה התהליכים עושים כרגע), System Information בוחן את המצב הסטטי (איזו חומרה מחוברת, אילו גרסאות תוכנה מותקנות, אילו ממשקי רשת קיימים). בעת פתרון תקלות בציוד היקפי, הרחבות קרנל או טופולוגיית רשת, System Information הוא מקור האמת המוחלט.

2. Deep Technical Architecture

הממשק הגרפי של System Information הוא למעשה עטיפה (Wrapper) ויזואלית שמתשאלת את הבינארי system_profiler, אשר בתורו מתשאל את אובייקטי ה-I/O Kit (עץ ה-Registry של כלל החומרה והדרייברים ב-macOS, שניתן לעיין בו בצורה גולמית בעזרת הפקודה ioreg).

כאשר מפעילים את System Information, הוא שולף נתונים משכבות ליבה שונות: סוגי זיכרון, ממשקי רשת אקטיביים, פרופילי חומרה, וטופולוגיות USB/Thunderbolt מחוברות. הכלי מנתח את הנתונים הגולמיים הללו ופולט אותם בפורמט סטנדרטי וקריא. הוא גם משמש כגשר עבור פלטפורמות ניהול מכשירים ניידים (MDM), שלעיתים קרובות קוראות לבינארי system_profiler שמאחורי הקלעים כדי לבצע סריקות מלאי (Inventory Sweeps) ולאמת תאימות (למשל, לבדוק אם FileVault פעיל או לאמת את גרסת ה-build המדויקת של macOS).

3. Terminal Commands, Plists & Logs

למרות שהממשק הגרפי נגיש מאוד, המקבילה בשורת הפקודה (system_profiler) מנוצלת רבות באוטומציה ובסביבות ארגוניות.

  • שליפת נתוני חומרה ותוכנה בסיסיים: system_profiler SPHardwareDataType SPSoftwareDataType

  • שליפת נתוני רשת וסדר עדיפויות ללא העמסת פלט: system_profiler SPNetworkDataType -detailLevel mini

  • זיהוי מזהי החומרה של ממשקי הרשת (en0, en1): networksetup -listallhardwareports

  • ייצוא מתקדם: מערכות MDM וסקריפטי IT מותאמים אישית משתמשים לעיתים קרובות בפורמט הפלט JSON כדי לנתח נתוני מערכת באופן תכנותי. system_profiler SPUSBDataType -json

  • גישה גולמית ל-I/O Registry: עבור דיבאגינג החומרה העמוק ביותר (למשל, וידוא האם חיבור USB ספציפי זוהה כיאות ברמת הליבה), טכנאים עוקפים את system_profiler לחלוטין ומשתמשים ב: ioreg -p IOUSB או ioreg -l

4. Edge Cases & Troubleshooting

יש לקחת בחשבון שהרצה של system_profiler ללא ציון "DataType" תחזיר את כל הנתונים של המחשב, מה שיכול לקחת דקות ארוכות ולגרום לטרמינל להיראות תקוע (Hung), במיוחד אם הוא סורק כונני רשת כבדים או כונן קשיח מפוצל.

קשיי אבחון ב-CLI יכולים להיווצר כשיש תקלות התקני I/O פגומים שמכניסים את החקירה ללולאה אין-סופית. אם ה-system_profiler נתקע לחלוטין, זהו סמן מובהק לכך שדרייבר חומרה (לרוב USB, Thunderbolt או רשת) תקוע במצב המתנה של הקרנל.

ב-GUI, הכלי System Information שימושי להפליא לבידוד בעיות ציוד היקפי. אם משתמש מתלונן שכונן USB-C חיצוני אינו מופיע על שולחן העבודה, בדיקה ב-System Information -> USB או Thunderbolt מאפשרת לטכנאי לבודד את הבעיה: אם הכונן מופיע ברשימת System Information, חיבור החומרה תקין והבעיה היא בעיית תוכנה/מערכת קבצים. אם הכונן אינו מופיע ב-System Information, מדובר בבעיה חשמלית/חומרתית טהורה (כבל פגום, כונן מת, פורט תקול).

4. תיבול ארגוני: איך תמיכת IT מבודדת בעיה כשיש המון פרופילי MDM ברקע

1. High-Level Theory & History

בסביבה ארגונית מנוהלת (MDM / Enterprise), פתרון תקלות הופך לאתגר מורכב משמעותית, משום שלכל בעיה מתווספת השאלה: "האם מדובר בתקלת תוכנה/חומרה מקורית, או בפרופיל תצורה (Configuration Profile) שמגביל את המשתמש בכוונה?".

תמיכת IT חייבת לדעת כיצד לבודד בעיה בין מערכת ההפעלה הבסיסית לבין Payload ארגוני ספציפי. סוגיה נפוצה במיוחד בסביבות Enterprise היא אבחון ותיקון של תקלות מול מערכות Single Sign-On (SSO) ומנגנון ה-Kerberos, המשמשים כדי להעניק למשתמשים גישה חלקה לשירותי הארגון (כגון שרתי קבצים ואינטרא-נט) ללא הזנת סיסמה חוזרת ונשנית.

2. Deep Technical Architecture

הניהול המוסדי ב-macOS מבוסס על תהליך ה-mdmclient שמחיל Configuration Profiles ישירות להגדרות ולמדיניות ברמת המערכת.

במקרים של מנגנון הזדהות, ארכיטקטורת ה-Extensible Single Sign-On של אפל מאפשרת לאפליקציית הרחבה (App Extension) ליירט בקשות אימות רשת, ליצור קשר עם ה-Identity Provider הארגוני (או Active Directory מקומי), ולשלוף תעודת Kerberos מסוג TGT (Ticket Granting Ticket) התקפה לזמן מוקצב.

כאשר תהליך זה כושל, כל הגישה הארגונית קורסת גם אם ה-Wi-Fi מחובר ויציב במאת האחוזים. הסיבה לרוב קשורה לפורטים חסומים בחומת האש הארגונית (כגון פורט 88 ו-464 הייעודיים ל-Kerberos) או חוסר סנכרון שעונים. בנוסף, מטענים (Payloads) עלולים לחסום גישה ל-Preference Panes מסוימים ב-System Settings, להשבית פורטים של USB, או לכפות שרתי פרוקסי (Web Proxies), כל אלו נראים כ-"באגים" למשתמש שאינו מודע לכך.

3. Terminal Commands, Plists & Logs

  • סקירה של כל פרופילי ה-MDM המותקנים על המחשב: profiles list

  • בחינת התצורה הפנימית של הפרופילים כדי למצוא מגבלות נסתרות: profiles show -type configuration

  • אבחון Single Sign-On (SSO) - רשימת כרטיסי ה-Kerberos הפעילים (TGT): klist

  • משיכה ידנית של כרטיס Kerberos לבדיקת חיבוריות (SSO Troubleshooting): kinit <username> (ידרוש הזנת סיסמת חשבון ארגוני כדי לראות אם יש תקשורת לשרת).

  • מעקב לוגים חי למנגנון ה-Enterprise SSO: log show --predicate 'subsystem == "com.apple.ExtensibleEnterpriseSSO"'

  • אילוץ סנכרון MDM: אם פרופיל הוסר או עודכן בשרת ה-MDM, ניתן לאלץ את הקליינט להתעדכן: sudo profiles renew -type enrollment

4. Edge Cases & Troubleshooting

בפתרון תקלות Kerberos ו-SSO, האויב הגדול ביותר של ה-IT הוא חוסר סנכרון בשעון (Clock Skew). ארכיטקטורת Kerberos בנויה כך שאם יש פער של יותר מחמש דקות בין השעון המקומי של המק לבין שרת ה-Domain Controller, כל ניסיון חיבור (SSO) יידחה אוטומטית ויציג שגיאה גנרית, ללא הסבר ברור על פער הזמנים.

בנוסף, בניסיון לבודד תקלות פרופילים, קיימים מצבים בהם ה-MDM אוסר לחלוטין על הסרת הפרופיל על ידי המשתמש (מגבלת Zero-Touch Deployment). הדרך היחידה לבצע בידוד (Isolation) יעיל במקרה כזה היא שהאדמין יעביר זמנית את המחשב לקבוצת החרגה (Exclusion Group) בקונסולת ה-MDM, ידחוף פקודת הסרה לפרופיל ספציפי, ויבחן האם התקלה נפתרה.

גישה אחרת לעקיפת מדיניות לצורך בידוד היא פתיחת Local Account זמני חדש (במידה ויש הרשאות), משום שפרופילים מסוימים (User Channel לעומת Device Channel) חלים רק ברמת המשתמש הספציפי. בדומה לכך, בידוד תקלות שנגרמו מסוכן אבטחה אגרסיבי (EDR) שעלול לחסום ביצוע קבצים או תעבורת רשת, לרוב דורש השבתה זמנית של הסנסור בעזרת קוד עקיפה מנהלתי, מה שמוכיח ש-macOS עצמה בריאה לחלוטין.

💡 עזרים ויזואליים להרצאה (Presentation Visuals)

תמונות אלו ניתנות להקרנה בכיתה בעת הסבר על הנושא, או לשילוב במצגות.

[!TIP] המחשה ויזואלית (עזר לתלמיד) תמונות אלו ממחישות את הממשק או המנגנון הרלוונטי לנושא השיעור.

ActivityMonitor_Memory What_to_do_when_an_app_uses_too_much_memory_p1_41 26-Tahoe-Activity-Monitor-scaled 26-Tahoe-System-Information-scaled