פרסום המקור: . עדכון המקור: . תרגום ובדיקה: .
כאשר חוקרים חשד לדליפת זיכרון ביישום מנוהל, אפשר להשתמש ב־WinDbg ובהרחבת האבחון SOS כדי לבחון את ערימת הזיכרון המנוהלת — האזור שבו נשמרים אובייקטים שבניהול סביבת הריצה, CLR. הנתונים מספקים נקודת התחלה לחקירה; דוח בודד של אובייקטים גדולים אינו מוכיח שיש דליפה.
1. מתחברים לתהליך מורשה וטוענים את ההרחבה
פתחו את WinDbg והתחברו רק לתהליך שאתם מורשים לאבחן, בחלון זמן מתואם. חיבור מנפה שגיאות עשוי לעצור את התהליך או להשפיע על פעולתו; אל תבצעו זאת בשירות ייצור ללא תיאום מתאים. השתמשו בגרסאות מתאימות של מנפה השגיאות, סביבת הריצה וההרחבה. אפשרויות החיבור מתוארות במדריך Microsoft לחיבור לתהליך.
בתהליך של .NET Framework 4.x, כאשר המודול clr כבר טעון, פקודת הטעינה היא:
.loadby sos clrהפקודה מחפשת את ההרחבה לצד המודול clr. זו השלמה לתחביר החסר במקור, לפי תיעוד .loadby. עבור .NET המודרני, שהמשיך את .NET Core, יש להשתמש בהוראות ההתקנה והטעינה המתאימות לו ולא להעתיק אוטומטית את המסלול הזה.
2. מציגים סיכום של הזיכרון המנוהל
!dumpheap -statהאפשרות -stat מציגה סיכום לפי סוג האובייקט, עם מספר המופעים והגודל הכולל שלהם. זהו מידע על הזיכרון המנוהל, ולא מיפוי של כל הקצאות הזיכרון בתהליך.
3. מסננים לפי גודל האובייקט
כדי להתמקד באובייקטים שגודלו של כל אחד מהם לפחות 1,000 בתים, אפשר להשתמש בדוגמה הבאה:
!dumpheap -stat -min 0x3e8הערך 0x3e8 בכתיב הקסדצימלי (בסיס 16) שווה ל־1,000 בבסיס 10. הכתיב המפורש מונע עמימות בפירוש המספר. האפשרות -min מסננת אובייקטים בודדים לפני חישוב הסיכום לפי סוג; היא אינה מסננת את עמודת הסכום TotalSize.
הפקודות והאפשרויות מתועדות במדריך SOS עבור .NET Framework. התאימו את השימוש לגרסה המותקנת ובדקו את העזרה שלה כשיש הבדל בתחביר או בפלט.
להמשך החקירה, השוו את צריכת הזיכרון לאורך זמן ובדקו אילו הפניות משאירות אובייקטים בזיכרון. מדריך האבחון של Microsoft עבור .NET המודרני מסביר את העיקרון, עם כלים ופקודות שמתאימים לסביבה זו.
שמרו על סודיות נתוני האבחון: זיכרון תהליך וקובצי צילום זיכרון (dump) עלולים לכלול מידע רגיש. הגנו על הגישה אליהם ואל תעלו נתונים לא מסוננים לשירות ציבורי. תיעוד איסוף צילומי הזיכרון מפרט גם מגבלות והשפעות אפשריות של האיסוף.