הרגע נתקלתי במחשב הזה בתקלה די משעשעת ב-Windows, אז אני מתעד את תהליך הבדיקה.
קודם כל בתיאור “בשפת בני אדם”:
המחשב נתקע לרגע, ואז הופיע במרכז המסך מלבן שחור ענק. הכי מופרך: הוא חוסם חלונות אחרים, אבל משום מה מנהל המשימות דווקא לא נחסם על ידו.
התחושה ממש מוזרה, כי זה לא נראה כמו קיפאון מערכת, לא כמו מסך תקול, אלא יותר כאילו נוסף על המסך “חלון רפאים” יש מאין.
האינטואיציה הראשונית שלי הלכה לכמה כיוונים:
- פאנל המסך התקלקל
- Chrome או חלון של דפדפן כלשהו התפוצץ ברינדור
- דרייבר הכרטיס הגרפי בדיוק עבר איפוס
- תוכנת חלון צף/שכבת-על שרצה תמיד קרסה, אבל “השאריות” של החלון נשארו על שולחן העבודה
אחר כך עברתי אחד-אחד, ובגדול צמצמתי את התשובה.
קודם מאמתים שזה לא מסך תקול
הפרט הכי קריטי הוא: אפשר לתפוס את הגוש השחור בצילום מסך.
זה חשוב מאוד, כי אם מדובר בפגם פיזי בפאנל, “דליפת נוזלים”, או נזק לחץ—בדרך כלל זה לא יופיע בצילום מסך.
אם רואים את זה גם בצילום מסך, זה אומר שזה משהו בתוך מחסנית הגרפיקה של Windows, כלומר “חלון ברמת תוכנה”, לא תקלה פיזית במסך.
ואז הולכים ליומני המערכת
בדקתי את הלוגים סביב 2026-04-06 01:27, וציר הזמן די מעניין:
01:27:12：alttab_windows.exeנתקע01:27:19：DWM(מנהל חלונות שולחן העבודה) יצא והופעל מחדש01:27:20：CPALauncher.exeקרס- אחר כך הופיעה גם שורה של
LiveKernelEvent 117 / 141 / 1a8 / 1b8 - והופיע גם
WindowsBlackScreenDiagnosticsV1
הדבר הכי בעל ערך פה הוא לא מי קרס, אלא שבחריגת ה-.NET של CPALauncher כתוב מפורשות:
קומפוזיציית שולחן העבודה הושבתה,
DwmExtendFrameIntoClientAreaלא הצליחה להשלים
המשמעות של המשפט הזה מאוד ישירה:
לא CPALauncher הפיל את המערכת קודם, אלא ש-קומפוזיציית שולחן העבודה / DWM נותקה לרגע קודם; הוא פשוט ניגש לממשק של DWM בדיוק באותו רגע, ואז התפוצץ יחד עם זה.
כלומר הכיוון הכללי כבר די ברור:
מה שקרה קודם הוא חריגה בשרשרת התצוגה/הגרפיקה, ורק אחר כך יישומים שונים התחילו לדווח שגיאות בשרשרת.
למה בהמשך חשדתי שזה לא יישום בודד, אלא שכל שרשרת הגרפיקה רעדה
כי ה”רעש” אחר כך היה מסודר מדי:
- בלוג של Sentry של
Typelessהופיע שוב ושובscreen.display-removed / added / metrics-changed PixPin.exeאחר כך קרס פעמיים עלd3d11.dll- גם
NVIDIA Overlayבאותו פרק זמן בנה מחדש שוב ושוב את תהליך שכבת-העל
כשמחברים את זה יחד, זה פחות נראה כמו “יישום אחד שעשה שטויות”, ויותר כמו:
המערכת חושבת שהתקן תצוגה הוסר והוסף מחדש, או שדרייבר הכרטיס הגרפי/שרשרת הקומפוזיציה עושים התאוששות.
ברגע שמחסנית הגרפיקה של Windows רועדת קצת, התוכנות שאוהבות “להתעסק” עם שולחן העבודה נופלות ראשונות:
- חלונות צפים
- שכבות-על
- כלי צילום מסך
- שדרוגים למעבר חלונות
- חלונות שקופים
- מקשי קיצור גלובליים
- כלי Electron קטנים
ועל המחשב הזה, במקרה יש לא מעט דברים מהסוג הזה.
הרגע שבאמת איתר את הגוש השחור
בהמשך כבר לא ניחשתי; פשוט מניתי את חלונות ה-top-level שמעל האזור המרכזי הזה במסך.
התוצאה שנפלה הייתה יפה:
- תהליך：
Typeless - כותרת חלון：
Status - הקואורדינטות והגודל—כמעט בדיוק חופפים לגוש השחור
כלומר, הדבר השחור הזה הוא לא הדפדפן, לא שולחן העבודה, לא ה-OSD של הכרטיס הגרפי עצמו, אלא חלון סטטוס צף של Typeless.
ואז בדקתי את המשאבים המקומיים של Typeless, ושם אפילו אפשר לראות ישירות:
floating_bar__window__title = "Status"
זה כבר די חותם את הסיפור:
הגוש השחור הוא בעצם חלון הסטטוס הצף של Typeless, אבל אחרי חריגה בשרשרת הגרפיקה הוא לא צויר/נסגר נכון, ולכן הפך לחלון רפאים top-level שחור לחלוטין.
למה הפרט “מנהל המשימות לא נחסם” כל כך שימושי
התופעה הזו ממש מרגישה כמו חלון שכבת-על בדרגת עדיפות גבוהה.
אם חלון של אפליקציה רגילה נהיה שחור, גם מנהל המשימות בדרך כלל ייחסם.
אבל אם זה חלון צף top-level מיוחד, חלון “תמיד מעל”, חלון כלי (tool window), או חלון בשכבות (layered window), לפעמים מנהל המשימות יכול לעבור מעליו בזכות עדיפות התצוגה שלו.
אז הפרט “חלונות אחרים נחסמים, מנהל המשימות לא” בעצם מאוד מרמז לך:
תחפש חלונות שכבת-על top-level, אל תתקע רק על לשוניות בדפדפן.
בסוף דרך הטיפול הייתה די פשוטה
אין פה תיקון מיסטי.
הפעולה היחידה שבאמת העלימה את הגוש השחור הייתה:
פשוט לסיים את התהליך Typeless.
סגרתי—והגוש השחור נעלם מייד.
זה גם אומר שלא מדובר במצב של “המערכת כבר מקולקלת וחייבים ריסטרט כדי להתאושש”, אלא בישות חלון שעדיין חיה, אבל שהתוכן שלה כבר התקלקל.
ההבנה הנוכחית שלי לגבי “שורש הבעיה” ו”הגורם המיידי”
אני מפרק את זה לשתי שכבות:
הגורם המיידי
חלון ה-Status הצף של Typeless נכשל בהתאוששות אחרי חריגה בשרשרת התצוגה, והשאיר חלון top-level שחור.
שורש עמוק יותר
מחסנית הגרפיקה של Windows באותו פרק זמן קודם נכנסה לבעיה, למשל:
- DWM נקטע/נבנה מחדש
- הופעל אירוע ה-watchdog של ה-GPU
- דרייבר הכרטיס הגרפי או טופולוגיית התצוגה הפכו לרגע לא יציבים
אז Typeless הוא לא המקור הבלעדי לבעיה, אלא יותר אחד הנפגעים הבולטים בתקרית הזו.
במבט לאחור, מה הכי חשוד
לפי סדר העדיפויות שלי:
- דרייבר כרטיס גרפי / מחסנית גרפיקה לא יציבה רגעית
- יותר מדי תוכנות קבועות מסוג שדרוג חלונות/שכבות-על זו על גבי זו
- Typeless עצמו לא יציב מספיק בטיפול בשינויי טופולוגיית תצוגה
באותו זמן היו “תוכנות מסוג עתיר-סיכון” כגון:
TypelessPixPinalttab_windowsNVIDIA Overlay- וגם
CPALauncherשכבר הסרתי
כל אחד מהם בנפרד לא בהכרח בעייתי, אבל יחד זה ממש נראה כמו מבחן עומס ל-DWM ול-D3D11.
אם בפעם הבאה אתקל בתקלה דומה, איך אטפל מהר יותר
עכשיו סדר הבדיקה שלי לבעיות כאלה ישתנה כך:
- קודם לבדוק אם הגוש השחור נכנס לצילום מסך
- אם הוא נכנס—לקבוע מייד שזה חלון ברמת תוכנה, לא מסך תקול
- קודם לפתוח מנהל המשימות, ולחפש תהליכים של חלונות צפים/שכבות-על/צילום מסך/שדרוג חלונות
- למנות או לזהות בעין לאיזה חלון הגוש השחור שייך
- קודם לסיים את התהליך הזה, ורק אחר כך לחזור ליומני המערכת
- ורק בסוף להחליט אם צריך לטפל עמוק יותר בדרייבר הכרטיס הגרפי
מסקנה זמנית
זה לא “המסך התקלקל”, וגם לא “Chrome מסך שחור” בצורה פשוטה.
יותר נכון לומר:
חריגה ברמת שרשרת הגרפיקה/DWM הפילה שרשרת של תוכנות שתלויות בקומפוזיציית שולחן העבודה; וחלון ה-Status הצף של Typeless היה חסר מזל, ובסוף נשאר במרכז המסך בדמות חלון רפאים שחור ענק.
זה באמת מאוד Windows, וגם די מעניין:
זו לא תקלה שרואים במבט ראשון, אלא צריך קודם לקבל את העובדה ש”גוש שחור הוא גם אובייקט חלון”, ואז כל ההמשך פתאום מסתדר.
אם בהמשך אצליח לצמצם עוד את גרסת הדרייבר, תנאי שחזור, או איזה פיצ’ר ספציפי ב-Typeless שמפעיל את המצב הזה—אוסיף עוד פוסט.