המצב הזה קורה לעיתים קרובות כשמריצים את ChromeDriver או את Chrome באמצעות ערכת בדיקה מיוחדת (אולי IDE) או מערכת build רציפה (כמו Jenkins).
מנסים להפעיל את אותו קובץ בינארי של Chrome שבו הבדיקה משתמשת, ממסוף הפקודה הרגיל של המשתמש. מוודאים איזה קובץ בינארי של Chrome נמצא בשימוש בקובץ chromedriver.log. אם מעבירים ל-Chrome מחרוזות או ארגומנטים מיוחדים של שורת הפקודה, צריך לכלול גם אותם. אם Chrome לא מצליח להתחיל לפעול כמו שצריך, צריך לתקן את ההתקנה של Chrome. מנסים להתקין מחדש.
נניח שאתם יכולים להריץ את Chrome מתוך שורת הפקודה. השלב הבא הוא לבדוק אם אותה בעיה מתרחשת כשמריצים את הבדיקה בסביבת בדיקה. מומלץ להפעיל את קובץ ה-binary או הסקריפט של הבדיקה ישירות ממסוף הפקודה של משתמש רגיל. מוודאים שאפשר להפעיל את Chrome ישירות מהבדיקה, בלי להשתמש ב-WebDriver או ב-ChromeDriver. לדוגמה, ב-Java אפשר להשתמש ב-ProcessBuilder API כדי להפעיל את קובץ הבינארי של Chrome ישירות. אם אותה בעיה מופיעה בבדיקה גם בסביבת בדיקה, צריך לשלוח דיווח על בעיה חדשה עם הוראות לשחזור הבעיה.
אחרת, אם הבעיה מתרחשת רק בסביבת הבדיקה המיוחדת שלכם:
משתמשים במנהל ההתקנה החלופי של Chrome. הפעולה הזו מתקינה את Chrome לכל המשתמשים. פעולה זו פותרת לעיתים קרובות בעיות אם אתם מפעילים את Selenium כשירות ברקע.
אחת מהסיבות הנפוצות לקריסה של Chrome במהלך ההפעלה היא הפעלת Chrome כמשתמש root (אדמין) ב-Linux. אפשר לעקוף את הבעיה הזו על ידי העברת הדגל --no-sandbox כשיוצרים את הסשן של WebDriver, אבל לא תהיה תמיכה בהגדרה כזו ואין להמליץ עליה. מגדירים את הסביבה כך שתפעיל את Chrome כמשתמש רגיל במקום זאת.
אם אף אחד מהפתרונות האלה לא פותר את הבעיה, יש לשלוח דיווח חדש עם הוראות לשחזור הבעיה. אם הבעיה מתרחשת רק בסביבת בדיקה מיוחדת ולא רגילה, חשוב לדעת שמפתחי ChromeDriver עשויים לא לבחור לבדוק ולפתור את הבעיה.