מדריך מלא לניתוח BSODs ו- kernel dumps ב- Windows

אינפורמטק דיגיטל » Recursos » מדריך מלא לניתוח BSODs ו- kernel dumps ב- Windows

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

עם קצת תרגול, כלים כמו WinDbg ותכונות כמו !analyze -v, .bugcheck או שימוש נכון בסמלים הם מאפשרים לנו לעבור מ"אני מקבל שגיאת מסך כחול" ל"אני יודע איזה מנהל התקן, משאב או התקן גרם ל-BSOD". במאמר זה, נפרט, שלב אחר שלב ובפירוט רב, כיצד לנתח BSOD באמצעות dump הליבה שלו, אילו סוגי dumps קיימים, כיצד להכין הכל, ואילו פקודות להשתמש כדי להפיק את המרב מהניתוח.

מהו BSOD ואיזה מידע הוא מכיל?

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

KeBugCheckEx תמיד מקבל חמישה ארגומנטים: קוד STOP (קוד בדיקת באגים) y ארבעה פרמטרים נוספים אשר מספקים הקשר טכני לכשל. אותם נתונים הם מה שאנו יכולים להתייעץ איתו לאחר מכן:

• על המסך הכחול קלאסי, אם המערכת אינה מוגדרת להפעלה מחדש אוטומטית.
• ביומן האירועים של Windows, בתוך מציג האירועים (יומן מערכת).
• בקובץ ה-dump של הזיכרון (minidump, kernel dump או full dump), באמצעות WinDbg ופקודות כמו !analyze -v o .bugcheck.

לכל קוד בדיקת באגים יש שם סמלי וערך הקסדצימלי משויךלדוגמה, בדיקת הבאגים DRIVER_POWER_STATE_FAILURE יש את הקוד 0x9Fבעוד משאב_לא_בעלות תואם 0xE3קודים אלה והפרמטרים שלהם מתועדים במדריך קודי בדיקת שגיאות של מיקרוסופט, אותו עליך לשמור בהישג יד תמיד.

בנוסף לקוד, המסך הכחול יכול להציג את שם של מנהל התקן .sys שלכאורה מעורבאם מדובר במנהל התקן של צד שלישי (אנטי-וירוס, כרטיס רשת, כרטיס מסך וכו'), לעתים קרובות יש לנו חשוד ברור. אם מה שמופיע הוא רכיב מערכת כללי (ntoskrnl.exe, win32k.sys...) או ששום דבר לא מופיע כלל, נצטרך להשתמש ב-memory dump וב-WinDbg כדי לחפור לעומק.

סוגי זיכרון dump ב-Windows

כדי שנוכל לנתח BSOD לעומק מסוים, אנו זקוקים ל-Windows שיפיק א קובץ dump של זיכרון (DMP) כאשר מתרחשת הכשל. קובץ זה לוכד את מצב המערכת בזמן השגיאה ויכול להיות מסוגים שונים.

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

זיכרון Dump קטן (Minidump)

El Minidump זהו הפורמט הקטן ביותר (כ-64 KB) וגם המוגבל ביותר לניפוי שגיאות מתקדם. עם זאת, הוא עדיין שימושי עבור לקבל אבחון מהיר בתרחישי BSOD רבים.

מיני-dump מאחסן, בין היתר, נתונים:

• הודעת העצירה, קוד בדיקת הבאגים והפרמטרים שלה.
• הקשר המעבד (PRCB) של המעבד שגרם לכשל.
• מידע על תהליך הליבה (EPROSS) של התהליך הפעיל בזמן הקריסה.
• מידע על השרשור בליבת הגרעין (ETHREAD) של השרשור שגרם לקריסה.
• מחסנית קריאות במצב ליבה עבור השרשור הזה (עד 16 KB).
• רשימת מנהלי התקנים שהוטענו בזמן מתן הפסיקה.
• רשימת מודולים שהועלו והורדו.
• בלוק נתונים של ניפוי שגיאות עם מידע בסיסי על המערכת.

סוג זה של dump נשמר בדרך כלל ב %SystemRoot%\Minidump (למשל, C:\Windows\Minidump). עבור מקרים רבים של תמיכה בסיסית או אבחון, מיני-dump מנותח היטב עם ! לנתח -v יכול להיות די והותר.

שקע זיכרון ליבה

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

dump זה נשמר כ זיכרון.DMP en %SystemRoot% (בְּרִירַת מֶחדָל, C:\Windows\MEMORY.DMPגודלו תלוי בזיכרון בו משתמש הליבה, אך בדרך כלל הוא גדול בהרבה מ-minidump וקל הרבה יותר לניהול מ-dump מלא.

זיכרון זיכרון מלא

El dump זיכרון מלא זה חוסך בפועל כל תוכן ה-RAM בזמן השגיאה: ליבה, תהליכי משתמש וכו'. זהו המפורט ביותר אך גם זה שתופס את רוב המקום והוא התובעני ביותר מבחינת תצורה.

כדי ש-dump מלא יהיה תקף, יש לעמוד במספר דרישות:

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

בסביבות ייצור עם הרבה זיכרון RAM, dump מלא עשוי להיות לא מעשי, אבל עבור מקרים מורכבים מאוד או מזדמנים זה יכול לעשות את כל ההבדל כשמדובר באיתור הבעיה.

הגדרת Windows ללכידה ורישום של BSODs

לפני שנתחיל עם WinDbg, חיוני לוודא שהמערכת זה יוצר נכון את ה-dumps ורושם את האירוע מהמסך הכחול.

בחלון "הפעלה ושחזור" אנו מוצאים מספר אפשרויות רלוונטיות:

• כתוב אירוע ליומן המערכתיש להפעיל את האפשרות כדי שבדיקת הבאגים תירשם במציג האירועים.
• כתיבת מידע על ניפוי שגיאותכאן אנו בוחרים Minidump, Kernel memory dump או Complete memory dump.
• נתיב קובץ ה-dumpברירת מחדל %SystemRoot%\MEMORY.DMP עבור ליבה/מלא.
• אתחול אוטומטיתמומלץ לבטל את הסימון אם נרצה צפו בשקט במסך הכחול ושימו לב למה שמופיע.

עבור חלק מהיצרנים או מחלקות התמיכה, כמו במקרה של מתאמי רשת מסוימים, המשתמש מתבקש ל שלח את קובץ ה-dumpזה בדרך כלל ב C:\Windows\memory.dmp ומומלץ לאתר אותו לפי תאריך/שעה כדי לזהות את זה המתאים לתקלה האחרונה.

אם מה שאנחנו רוצים זה כוח לכפות dump גם כאשר המערכת קפואה (ללא תגובה של המקלדת או העכבר), יש גם טריק שימושי מאוד עבור מקלדות PS/2 (לא USB/Bluetooth), הכולל הגדרת הרישום להפעלת קובץ dump באמצעות צירוף מקשים.

כפיית dump באמצעות המקלדת במקרה של קיפאון

כדי ליצור קובץ dump של זיכרון גם אם המסך קפוא לחלוטין, נוכל להשתמש באפשרות CrashOnCtrlScroll שיטה זו אינה תקפה עבור מקלדות USB או Bluetooth.

ברישום, עלינו ליצור או לשנות את המפתח הבא:

HKEY_LOCAL_MACHINE
  System
    CurrentControlSet
      Services
        i8042prt
          Parameters

Nombre: CrashOnCtrlScroll
Tipo:   REG_DWORD
Valor:  1

לאחר הפעלה מחדש, בכל עת (גם כאשר המסך קפוא) נוכל לגרום לתאונה מבוקרת ושהמערכת מייצרת את מאגר הזיכרון על ידי לחיצה על המקש CTRL ימני ואז, לחץ פעמיים על מקש Scroll Lockזה מאוד שימושי לחקירת קריסות קשות שלא מראות BSODs בעצמן.

מבוא ל-WinDbg לניתוח קבצי ליבה (core dumps)

WinDbg הוא הכלי החיוני של מיקרוסופט עבור ניפוי שגיאות בליבת הגרעין וניתוח dump של זיכרוןהוא זמין בחינם (כרגע גם בחנות מיקרוסופט כ-WinDbg Preview) ולמרות שזה אולי נראה מרתיע במבט ראשון, עבור ניתוח BSOD ראשוני אנחנו צריכים לנהל רק כמה אפשרויות בסיסיות.

נוכל להתקין את WinDbg על המכונה הפגועה עצמה או על... כל קבוצה אחרתניתן להעתיק את קובץ ה-.dmp דרך רשת, דרך USB, או אפילו לדחוס אותו לקובץ CAB. ייתכן שהמעבד וגרסת Windows ששימשו לניתוח קובץ ה-dump לא תואמים לאלה של המחשב שנתקע.

הפעל את WinDbg עם קובץ dump משורת הפקודה

דרך קלאסית לפתוח קובץ dump של זיכרון ב-WinDbg היא להשתמש בשורת הפקודה עם הפרמטר -z ציון נתיב קובץ ה-dump. נוכל לשלב זאת עם פרמטרים אחרים כגון נתיב הסמל או הנתיב הבינארי:

windbg -y <RutaSimbolos> -i <RutaBinarios> -z <RutaDump>

המשנה -v להפעיל את מצב מפורט (מפורט)וזה מאוד שימושי כדי לראות יותר הקשר. מלבד WinDbg, יש גם kd.exe, גרסת ניפוי באגים מבוססת קונסולה המאפשרת לך לעשות כמעט את אותו הדבר אך ללא ממשק גרפי:

kd.exe -z "Ruta\al\volcado.dmp" -y "Ruta\simbolos" -i "Ruta\busqueda\binarios"

פתח קובץ dump מהממשק הגרפי

אם כבר יש לנו את WinDbg פתוח במצב פסיבי, נוכל לטעון קובץ dump באמצעות התפריט. קובץ → פתיחת מטמון קריסה או עם קיצור הדרך Ctrl + Dאנו בוחרים את קובץ ה-.dmp (או אפילו קובץ .cab שמכיל אותו) ו-WinDbg יטען את פרטי ה-dump.

אלטרנטיבה נוספת היא להפעיל את WinDbg, ולאחר מכן להפעיל את הפקודה .opendump ציון הנתיב לקובץ ה-dump ולאחר מכן הפקודה g (Go) כדי להתחיל סשן ניפוי באגים של dump:

.opendump C:\Windows\Memory.dmp
g

WinDbg אפילו מאפשר לנקות מספר פסולת בבת אחתהוספת מספר פרמטרים -z בשורת הפקודה או על ידי חזרה על .opendump עם מסלולים שונים וניהול הסשן מרוב היעדים.

הגדרת נתיב הסמלים ב-WinDbg

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

כדי להשתמש בסמלים הציבוריים של מיקרוסופט מבלי להוריד אותם ידנית, השיטה הטובה ביותר היא להגדיר שרת סמלים מצביע על שרת מיקרוסופט הרשמי ועל ספריית מטמון מקומית. לדוגמה, נוכל ליצור תיקייה מראש. C:\סמלים ולאחר מכן, ב-WinDbg, הגדר את נתיב הסמלים באופן הבא:

SRV*c:\symbols*https://msdl.microsoft.com/download/symbols

ניתן לעשות זאת מהתפריט קובץ → נתיב קובץ סמלים או, בתצוגה מקדימה של WinDbg, מ קובץ ← הגדרות ← הגדרות ניפוי באגים התאמת "נתיב הסמלים המוגדר כברירת מחדל". בפעם הראשונה שאנו מנתחים קובץ dump ממערכת ספציפית, ניפוי הבאגים יוריד אוטומטית את הסמלים הדרושים דרך האינטרנט, דבר שעשוי לקחת מספר דקות בהתאם לחיבור.

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

ניתוח ראשון: פקודות בסיסיות ובדיקת באגים

לאחר טעינת קובץ ה-dump ותצורת הסמלים מוגדרים, WinDbg בדרך כלל מציג כותרת עם מידע מערכת ואזהרה. "השתמש ב-!analyze -v כדי לקבל מידע מפורט על ניפוי שגיאות."זוהי התחנה הראשונה שלנו לניתוח ראשוני.

הפקודה ! לנתח -v הוא מבצע ניתוח אוטומטי של ה-dump ובדרך כלל מספק:

• קוד בדיקת הבאגים (לדוגמה, 0xE3, 0xD1, 0x9F, 0x44…).
• הפרמטרים Arg1, Arg2, Arg3 ו-Arg4 מבדיקת הבאגים.
• המודול או הדרייבר הסביר ביותר סיבת הכשל (Probably caused by).
• התהליך הנלווה באותו רגע (לדוגמה, Teams.exe).
• מחסנית הקריאה (מעקב מחסנית) של השרשור שגרם לקריסה.
• מידע על הדלי ו-hashes של כשל, שימושיים לקישור בין שגיאות חוזרות ונשנות.

לדוגמה, בתרחיש בדיקת באגים בעולם האמיתי משאב_לא_בבעלות (0xE3)הניתוח עשוי להצביע על כך שניסה שרשור לשחרר משאב שאין ברשותומראה כיצד התהליך Teams.exe ומצביע על win32kbase.sys בפונקציה כמו הגדרות תצוגה של DrvEnumזה נותן לנו רמז שהשרשור שנכשל ביצע שאילתה או מניפולציה של הגדרות תצוגה ממרחב המשתמש דרך שכבת הגרפיקה של Windows.

כדי להתעמק מעט בפרטי קוד העצירה והפרמטרים שלו, יש לנו גם את הפקודה בדיקת באגיםאשר שוב מציג את בדיקת הבאגים ואת ארבעת הארגומנטים, וזה שימושי אם אנחנו רוצים לחזור על מידע זה מבלי להריץ הכל מחדש. !analyze -v.

מקרים מעשיים: גורמים מניעים וקונפליקטים אופייניים

ניתוח BSOD בדרך כלל סובב סביב זיהוי נהגים פגומים או בעלי התנהגות לא תקינההתנגשויות בין בקרים, גישה לא מורשית לזיכרון, טיפול שגוי ב-IRPs (חבילות בקשת קלט/פלט) וכו'. בואו נבחן כמה דוגמאות מעשיות שנלקחו ממקרים אמיתיים כדי להבין טוב יותר את התהליך.

RESOURCE_NOT_OWNED (0xE3) המשויך ל-Teams ול-win32kbase.sys

בתרחיש של Windows 10 שבו לאחר מספר ימי פעילות מופיע הודעת BSOD עם בדיקת באגים 0xE3 (משאב לא בבעלות)ה-minikernel dump מציג משהו כזה:

RESOURCE_NOT_OWNED (e3)
A thread tried to release a resource it did not own.
Arguments:
Arg1: <dirección recurso>
Arg2: <dirección thread>
Arg3: 0
Arg4: 0

PROCESS_NAME: Teams.exe

STACK_TEXT:
...
win32kbase!DrvEnumDisplaySettings+0x356
win32kbase!NtUserEnumDisplaySettings+0x59
win32k!NtUserEnumDisplaySettings+0x15
nt!KiSystemServiceCopyEnd+0x28
...

כאן ניפוי הבאגים מציין שבדיקת הבאגים מופעלת על ידי רצף תגובות המשויך ל- Teams.exeאבל הקוד שנמצא בפועל על המחסנית ברגע הקריטי שייך ל win32kbase.sys, ספציפית לפונקציה הגדרות תצוגה של DrvEnumזה לא בהכרח אומר ש-Teams היא ה"אשמה" הישירה, אלא ש... מתבצעת קריאה ל-API של משתמש מ-Teams אשר מסתיים בבאג סנכרון או שחרור משאבים בתת-המערכת הגרפית.

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

DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) עם NotMyFault

שירות לא באשמתי הכלי של Sysinternals הוא משאב חינוכי המאפשר לך ליצור שגיאות ליבה בצורה מבוקרת כדי ללמוד כיצד לנתח צילומי מסך. לדוגמה, אם נפעיל את האפשרות מ-NotMyFault תקלת IRQL גבוהה (מצב ליבה) ונלחץ על "בצע באג", נכפה מנהל התקן IRQL לא פחות או שווה (0xD1).

על המסך הכחול נראה משהו כזה DRIVER_IRQL_NOT_LESS_OR_EQUAL ואולי גם נהג מועמד (לדוגמה, MyFault.sys(מנהל ההתקן בו משתמש הכלי). לאחר יצירת קובץ ה-dump ופתיחתו באמצעות WinDbg, הפלט הראשוני עשוי להיראות דומה ל:

Use !analyze -v to get detailed debugging information.
BugCheck D1, {e1071800, 1c, 0, f7cda403}
*** ERROR: Module load completed but symbols could not be loaded for myfault.sys
Probably caused by : memory_corruption
Followup: memory_corruption

למרות שפותח הבאגים מצביע על פגם_זיכרוןאנו יודעים שהסיבה האמיתית קשורה ל-NotMyFault ולמנהל ההתקן שלו. כדי לאשר זאת, נוכל להמשיך במעקב באמצעות פקודות כמו !פְּתִיל כדי לראות אילו קריאות השרשור מבצע בזמן הכישלון, ו !irp כדי לנתח את ה-IRP המעורב אם בדיקת הבאגים קשורה לפעולות קלט/פלט.

לדוגמה, עם !פְּתִיל נוכל לראות את מעקב המחסנית של ה-thread ולאתר את ההוראה במקום בו היא מופיעה. האשם שלי+0x403זה אומר לנו היכן טעה מנהל ההתקן של הבדיקה. משם, נוכל לבחון את ה-IRP, את מצב הזיכרון וכו', בדיוק כפי שהיינו עושים עם באג אמיתי.

MULTIPLE_IRP_COMPLETE_REQUESTS (0x44) וקונפליקטים ב-USB

מקרה נוסף הממחיש מאוד הוא בדיקת הבאגים בקשות_השלמה_רבות_IRP (0x44)שגיאה זו מתרחשת כאשר IRP (חבילת בקשת קלט/פלט) הושלמה יותר מפעם אחת, בדרך כלל משום ששני נהגים שונים מאמינים שהם בעלי אותו IRP ושניהם מתקשרים IoCompleteRequest().

הניתוח עם ! לנתח -v זה עשוי לייצר תיאור דומה לזה:

MULTIPLE_IRP_COMPLETE_REQUESTS (44)
A driver has requested that an IRP be completed (IoCompleteRequest()), but
the packet has already been completed.
...
Arguments:
Arg1: <IRP_ADDRESS>
Arg2: 00000d75
Arg3: 00000000
Arg4: 00000000

Probably caused by : usbehci.sys

בתחילה נראה כי החשוד הוא usbehci.sysמנהל התקן של מיקרוסופט עבור בקרי USB EHCI. עם זאת, נדיר יחסית שהבאג נגרם על ידי מנהל התקן מקורי של Windows ללא כל אינטראקציה של צד שלישי. כדי להגיע לעיקר, אנו משתמשים בכתובת ה-IRP שניתנה לנו על ידי בדיקת הבאגים (Arg1) ומפעילים !irp:

!irp 87e5a490
Irp is active with 3 stacks 3 is current (= 0x87e5a548)
...
> [ f, 0] 0 c0 8a055618 00000000 b69de300-00000000 Success Error
  \Driver\usbehci ax88172
Args: b70989c0 00000000 00220003 00000000

בשורה האחרונה אנו רואים בבירור את השרשרת \מנהל התקן\usbehci ax88172, אשר מגלה כי ה-IRP עבר כל כך הרבה usbehci.sys כמו למשל על ידי נהג בשם ax88172.sys, המשויך לערכת שבבים ספציפית לרשת USB (AX88172). לכן, אנו יכולים להסיק שהסכסוך נובע מכך מנהל התקן של כרטיס רשת USB של צד שלישילא מנהל ההתקן הגנרי של מיקרוסופט EHCI.

הפתרון, במקרה כזה, טמון ב עדכן את מנהל ההתקן של מתאם ה-USB, החלף את ההתקן, או, אם אין אפשרות אחרת, הסר אותו.סוג זה של ניתוח באמצעות IRP שימושי במיוחד ב-BSODs הקשורים ל-USB, אחסון, כרטיסי רשת, ובכלל, כל רכיב המשתמש באופן אינטנסיבי ב-I/O.

פקודות WinDbg שימושיות במצב ליבה

מעבר ! לנתח -v y בדיקת באגיםישנן מספר הרחבות ופקודות WinDbg שהן שימושיות מאוד כאשר אנו רוצים להתעמק מעט יותר ב- kernel dumping.

חלק מהנפוצים ביותר הם:

• !פְּתִילמציג מידע מפורט על רצף הליכים, כולל מחסנית הקריאה שלו, המצב, ה-IRPs המשויכים וכו'. מאפשר לך לראות את "הפעולות האחרונות" של הרצף שפעל כאשר המערכת קרסה.
• תהליך 0 0זה מפרט את כל התהליכים הפעילים בזמן הקריסה. זה שימושי לזיהוי אם היו תהליכים חשודים, שירותים, EDR, אנטי-וירוס וכו', שפעלו על המכונה.
• !irpמנתח IRP ספציפי ומציג עקבות הנהגים שעברו דרכםפקודת הקלט/פלט, דגלים וכו', הם המפתח לבאגים הקשורים ל- MULTIPLE_IRP_COMPLETE_REQUESTS ושגיאות קלט/פלט אחרות.
• !מידע על מעבדיםמספק מידע על המעבד (יצרן, מגהרץ, חתימות, מאפיינים), שימושי לאימות סביבות חומרה.
• !פבמציג פרטים על ה-PEB (בלוק סביבת התהליך), כגון שם המחשב, נתיב ההתקנה של Windows, מספר המעבדים וכו'.
• !אֲסִימוֹן: מספק מידע על אסימוני אבטחה, הרשאות והקשר אבטחה של התהליך או השרשור.
• .cls: מנקה את חלון הפקודות, כמו בקונסולה רגילה.

יתר על כן, סיומות ספציפיות רבות (לדוגמה, עבור מערכות קבצים, PnP, NTFS וכו') מאפשרות לחלץ מידע רב אף יותר מקבצי ה-dump. במקרים מסוימים, WinDbg יצביע על נוכחות של קופסה שחורה* (BLACKBOXBSD, BLACKBOXNTFS, BLACKBOXPNP, BLACKBOXWINLOGON), שהם בלוקי נתונים נוספים שנלכדים בזמן בדיקת הבאגים כדי להקל על האבחון של אזורים ספציפיים במערכת.

שימוש במאמת מנהלי התקנים כדי למצוא מנהלי התקנים בעייתיים

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

El אימות נהגים הוא פועל בזמן אמת ומעביר את הנהגים שנבחרו סדרה של בדיקות ומבחני מאמץ: הוא מאמת את שימוש נכון בזיכרון, מאגרי ליבה, IRQL, IRP וכו'.אם הוא מזהה שנהג עושה משהו לא בסדר, הוא יכול לכפות BSOD מבוקר כדי שנוכל לנתח מטמון הרבה יותר ברור, שבו בדרך כלל מזוהה בצורה ברורה מאוד את האשם.

כדי להפעיל את מנהל אימות מנהלי ההתקנים, פשוט פתחו שורת פקודה עם הרשאות מנהל והקלידו:

verifier

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

ברגע ש-Verifier יפעיל הודעת BSOD לאחר זיהוי התנהגות שגויה, נוכל לנתח את קובץ ה-dump של הליבה באמצעות WinDbg, ובתקווה, לראות בבירור. איזה נהג נתפס ומה זה עשה לא נכון? מאמרי ההפניה של מיקרוסופט בנושא Driver Verifier מסבירים בפירוט את האפשרויות השונות ואסטרטגיות השימוש.

עצות מעשיות למהנדסים וטכנאים

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

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

בתרחישים אחרים, בדיקות באגים עשויות לנבוע מ... מנהלי התקנים, חומרה או תוכנה של צד שלישי שאנחנו לא שולטים בהם. במקרים אלה, המטרה עוברת מ"תיקון הקוד" ל לבודד ולמתן את הבעיה:

• זהה את מנהל ההתקן או רכיב החומרה החשוד באמצעות ניתוח WinDbg ו-dump.
• עדכון או חזרה לגרסה הקודמת גרסאות מנהלי התקנים, BIOS, קושחה או יישומים קשורים.
• הסרה או החלפה התקני USB, כרטיסי מסך, מתאמי רשת קונפליקט.
• להישען על ה- מציג אירועים, Sysinternals, כלי ניטור וניתוח רשת להקשר נוסף.

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

כמו כן, יש לזכור כי בסביבות כמו זו שגרמה לאירוע של CrowdStrike Falcon ו-EDR אחרים, השאלות הנפוצות ביותר סובבות סביב מה גרם ל-BSOD וכיצד לזהות אותו במהירותהגדרה נכונה של WinDbg, עם סמלים והליך ברור לפתיחה וניתוח של קבצי dump, מאפשרת לך לצמצם תוך דקות את מה שעלול להסתיים ב"פרמוט והתקנה מחדש" מבלי להבין באמת את הסיבה.

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