פתרון חקירת קריסה וסמלים

פתרון התרגיל הראשון

הכתובת שהודפסה היא כתובת שהמערכת הקצתה בהצלחה, ולכן אינה אמורה להיות null. ההגנה שלה היא PAGE_NOACCESS. בתוך הקשר החריגה נמצא הוראת store שנוצרה עבור הכתיבה דרך address. האוגר המדויק תלוי בקומפיילר ובbuild, ולכן לא נעתיק שם אוגר מתשובה מוכנה בלי לקרוא את הdisassembly.

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

פתרון התרגיל השני

הגרסה המאופטמת עדיין כוללת symbols, אבל symbols אינם משחזרים משתנים שהקומפיילר לא שמר. המתודות סומנו noinline כדי לשמור גבולות מסוימים בניסוי, אך זה לא מבטיח layout זהה של registers או locals.

נשמור לכל גרסה exe, PDB, flags וhash. אם קובץ symbols נדחה בגלל אי־התאמה, נחזור לartifact המתאים. כפיית PDB לא נכון יכולה לייצר שורת מקור שנראית תקינה ומצביעה על פעולה שלא רצה באותה כתובת.

פתרון התרגיל השלישי

מידע region יכול לומר שאזור קיים, committed ומוגן, גם בלי שכל תוכנו נשמר. לכן כשל קריאה של debugger מתוך dump אינו מוכיח שהזיכרון לא היה קריא בתהליך החי. נבדוק קודם אם העמוד נכלל באיסוף.

באיסוף מלא נוכל לעיתים לחקור יותר תוכן ויחסים בין אובייקטים, אבל עדיין לא נקבל את היסטוריית הכתיבות. אם מצאנו pointer פגום, השלב הבא יכול להיות data breakpoint או PageHeap בהרצה חדשה עם repro. הדוח יציין את הסיבה המוכחת לקריסה הנוכחית ואת ההשערה לגבי מי יצר אותה, בלי לאחד אותן למסקנה שלא נבדקה.