מקרה בוחן של תשתית בדיקות לנתיבי שגיאה עם Application Verifier

סקירת המקרה

מקרה זה לא הסתיים בתיקון נקודתי: השתמשנו ב-Application Verifier כדי להכין את תשתית הבדיקות לנתיבי שגיאה עצמה. המטרה לא הייתה רק “למצוא את התקלה הנוכחית”, אלא להשאיר מצב מוכן שבו יהיה קל לחקור גם את התקלה הבאה.

תסמינים

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

אילוצים

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

מה בחנו

• הגדרות Verifier כגון Handles,‏ Heaps ו-Low Resource Simulation.
• עקבות של נתיבי שגיאה, כולל !htrace ו-page heap.
• ההתאמה בין יומני מחזור החיים שלנו לבין מידע העצירה של Verifier.

כיצד בודדנו את הבעיה

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

כיצד שיפרנו

• הכנו תשתית בדיקות שעוברת במכוון דרך נתיבי השגיאה.
• אפשרנו לצפות בחריגות של handles ושל heap במחזורים קצרים יותר.
• ארגנו את נקודות התצפית באופן שקל להחזיר לסקירות תכנון ולצעדים למניעת הישנות.

שירותים הקשורים למקרה זה

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

מאמרים קשורים

צרו איתנו קשר

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