איתור תקלות במערכות הפעלה Windows ופתרונן – סיפורים מהחיים

אבי ורטהיימר ינואר 2017

מקרה לקוח:

הלקוח מייצר מחשבים באמצעות מפעל סיני.

המחשבים הראשונים שהוזמנו, עבדו כראוי.

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

המחשבים לא מייצרים dump file ולא נרשם כל מידע בevent log טרם האיתחול.

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

הפתרון: שינוי בקונפיגורציה של אחד הדרייברים שמשתמש בSelective suspend שלוח האם לא תומך בו.

מקרה לקוח:

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

הלקוח התקין "על עיור" את מערכת ההפעלה

בהדלקת המחשב הלקוח חווה תקשורת רשת ראשונית, אך לא ניתן ליצור קשר עם המחשב מרחוק באמצעות כתובת הIP  שלו.

הפתרון: שינוי הגדרות בBCD Store

מקרה לקוח:

הלקוח נהג להשתמש בCompact Flash בתור הboot storage על מחשב שעליו מותקנת מערכת הפעלה בwindows XP Embedde

בהזמנת רכיבי CF  חדשה, מאותו P/N, לא ניתן יותר לעשות boot למערכת ההפעלה.

הפתרון:

למרת שהCF מגיע מיצרן מכובד ולמרות שמדובר באותו הP/N, מסתבר שהיצרן משתמש בcontroller פנימי שונה שלא מותאם יותר למנגנון הboot של הWindows XP ועשיתי workaround כזה שנעשה שימוש בBOOTMGR כדי לעלות את מערכת ההפעלה

מקרה לקוח:

לקוח כתב תוכנה ב.net המבוסס על WinForm

בכל מחזור שימוש במסכי התוכנה, הזכרון של המחשב מתמלא והתוכנה נעשית איטית יותר ויותר.

פתרון: תוך שימוש בכלי ANTS Memory profiler, התברר כי המחלקות של המסכים נרשמות לאירועים של מחלקות אחרות ולא משחררות את הreference של אירועים אלו למחלקת המסכים.

מקרה לקוח:

לקוח מתלונן כי בwindows 7, בתוכנה שהוא כתב, הוא מקצה core  לכל Process ומריץ במקביל מספר אלגוריתמים זהים.

כשהתוכנה סיימה לנצל את כל הcores של הCPU הראשון ומתחילה להשתמש בcore הראשון של הCPU  השני הביצועים יורדים פי 10.

פתרון:

מניתוח של פעילות מערכת ההפעלה, באמצעות Windows Performance Analyzer עולה כי פונקצית memory allocation בnuma mode, של הkernel גוזלת את כל הזמן כשקוראים לcore של הCPU השני.

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

מקרה לקוח:

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

פתרון:

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

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

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

בוצעו חיבורי ארקות והמערכת חוברה למחשב ובבדיקה התברר כי הבעיה נעלמה.

 

מקרה לקוח:

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

פתרון:

בבחינת הקוד של התוכנה בצד הכרטיס האלקטרוני ובצד המחשב הסתבר כי הממשוק בו נעשה שימוש הינו VCP  over USB

בבדיקת הגדרות הדרייבר, התברר כי הוא מוגדר לעבודה ישירות בממשק USB  ולא דרך ממשק הVCP. בוצעו שינויי הגדרות והממשק התעורר לחיים.

לצורך הבדיקות נעשה שימוש בין היתר בUSBLYZER

מקרה לקוח:

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

 פתרון:

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

בבדיקה בrecording mode של digital oscilloscope מסתבר שרמת המתח גבולית ולעיתים נוטה לרדת, דבר שמלמד על עומס יתר במעגלים.

בוצעה הגדלה של קוי הזרם והתקשורת הפכה להיות יציבה.

מקרה לקוח:

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

פתרון:

מניתוח התעבורה באמצעות network analyzer מסתבר שכשעובדים עם מערכת בעלת מערכות הפעלה שונות, העברת מידע בכיוון אחד בלבד מייצרת retries רבים על סיבת timeout. מקור הבעיה אובחן כשכבת דרייבר של מיקרוסופט. באסקלציה של הבעיה למיקרוספט, אותרה הבעיה כבאג במערכת ההפעלה ונמצא פתרון workaround של שינוי ערך ברגיסטרי שמתייחס לממשק התקשורת במערכת ההפעלה החדשה יותר. כתוצאה מכך, מיקרוספט שחררה עדכון שמתקן את הבעיה בכל המחשבים בעולם

מקרה לקוח:

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

פתרון:

מניתוח הdump file באמצעות windbg מסתבר כי בכל המקרים, הפונקציה שפעלה בזמן הריסוק היא של דרייבר מסויים של תוכנת אנטי וירוס כלשהיא. עצם הדבר לא הסביר את עצמו, כי הרי האנטי וירוס אמור לעבוד בצורה תקינה ולכן נעשה חיפוש אחר filter driver נוספים שיתכן שמתנגשים עם האנטי וירוס ואכן הסתבר כי הUWF filter driver לא מסוגל לעבוד בשיתוף פעולה עם האנטיוירוס הספציפי הזה ולקוח הוצע לשנות שיטת הגנה על המערכת ולעבור לשיטת של white listing של חברת intel שהוכיחה יכולת לעבוד בשיתוף פעולה עם הUWF

 

מקרה לקוח:

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

פתרון:

אותרה הסיבה לכך שהמחשב לא מסוגל לייצר מסכים כחולים בכך שהוא מוגדר שלא לייצר קובץ dump כאשר אין לפחות 25 ג'יגה פנוי בדיסק הsystem

לאחר מכן, המחשב החל לייצר dump file. בניתוח הdump file הסתבר כי הדרייבר של המתאם הגרפי הוא האשם בדבר.

לאחר עדכון דרייבר הבעיה נפתרה

מקרה לקוח:

לקוח מתלונן על מסכים כחולים שהתחילו להופיע בכל המחשבים שמותקנים במכונות שהוא מייצר

פתרון:

מניתוח של הdump files של הBSOD עולה כי האשם במתאם הרשת. עדכון דרייבר לא הועיל היות והוא היה המעודכן ביותר.

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

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

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

מקרה לקוח:

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

פתרון:

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

מקרה לקוח:

תוכנת מחשב נתקעת כשמגדירים baud rate גבוה מערך מסויים בתקשורת עם כרטיס חומרה שהלקוח פיתח.

פתרון:

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

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