بعد أن تجمّد الكمبيوتر للتو، بقي مربع أسود في وسط الشاشة لا يتجرأ عليه إلا «مدير المهام»، وفي النهاية ألقيت اللوم على Typeless

AIDO تصحيح الأخطاء
,
1

واجه هذا الجهاز قبل قليل عطلاً ممتعاً نوعاً ما في 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 كانت تعيد بناء عملية الـ overlay بشكل متكرر في تلك الفترة

عندما تضع هذه الظواهر معاً، لا تبدو كـ “تطبيق واحد تَخَبَّط”، بل أقرب إلى:

النظام اعتقد أن جهاز العرض أُزيل ثم أُضيف مجدداً، أو أن تعريف كرت الشاشة/سلسلة التركيب كانت تقوم بعملية استعادة.

وبمجرد أن تهتز سلسلة رسوميات Windows ولو قليلاً، فإن أكثر البرامج التي تعبث بسطح المكتب ستتأذى أولاً:

  • النوافذ العائمة
  • طبقات التغطية (overlays)
  • أدوات التقاط الشاشة
  • تحسين/تعزيز تبديل النوافذ
  • النوافذ الشفافة
  • اختصارات لوحة المفاتيح العامة
  • أدوات Electron الصغيرة

وعلى هذا الجهاز، المصادفة أن هذا النوع من الأشياء موجود بكثرة.

اللحظة التي حددت فيها مصدر المستطيل الأسود فعلاً

بعدها توقفت عن التخمين، وبدأت مباشرة بتعداد (enumerate) نوافذ المستوى الأعلى (top-level windows) التي تقع فوق تلك المنطقة في منتصف الشاشة.

وجاءت النتيجة ممتازة:

  • العملية: Typeless
  • عنوان النافذة: Status
  • الإحداثيات والحجم مطابقان تقريباً للمستطيل الأسود

أي أن هذا الشيء الأسود ليس المتصفح، وليس سطح المكتب، وليس OSD الخاص بكرت الشاشة، بل هو نافذة حالة عائمة تابعة لـ Typeless.

ثم رجعت إلى موارد Typeless المحلية، ووجدت حتى هذا السطر مباشرة:

  • floating_bar__window__title = "Status"

وهنا تأكد الأمر تقريباً:

ذلك المستطيل الأسود هو في جوهره نافذة الحالة العائمة لـ Typeless، لكنها بعد اضطراب سلسلة الرسوميات لم تُعَد إعادة رسمها/إغلاقها بشكل صحيح، فتحولت إلى نافذة شبح علوية سوداء بالكامل.

لماذا كانت تفصيلة “إدارة المهام لا تُحجب” مفيدة جداً

هذا السلوك يشبه كثيراً نافذة تغطية عالية المستوى.

إذا اسودّت نافذة تطبيق عادي، فستحجب إدارة المهام أيضاً.
لكن إن كانت نافذة عائمة خاصة من نوع topmost، أو نافذة أدوات، أو نافذة طبقية (layered window)، فقد تتمكن إدارة المهام أحياناً من تجاوزها بأولوية عرضها.

لذلك تفصيلة “كل النوافذ تُحجب ما عدا إدارة المهام” كانت عملياً تلمّح لك:

ابحث عن نافذة تغطية من المستوى الأعلى، ولا تركز فقط على ألسنة المتصفح.

طريقة المعالجة النهائية كانت بسيطة جداً

لا توجد “إصلاحات غامضة”.

الفعل الوحيد الذي جعل المستطيل الأسود يختفي فعلاً كان:

إنهاء عملية Typeless مباشرة.

بمجرد إغلاقها اختفى المستطيل فوراً.

وهذا يثبت أيضاً أنها لم تكن حالة “النظام فاسد ويجب إعادة التشغيل للتعافي”، بل كانت كيان نافذة ما يزال حياً، لكن محتواه أصبح معطوباً.

فهمي الحالي لـ “السبب الجذري” و“السبب المباشر”

أتعامل معها الآن على مستويين:

السبب المباشر

نافذة Status العائمة الخاصة بـ Typeless فشلت في التعافي بعد خلل سلسلة العرض، فتركت نافذة سوداء علوية.

السبب الجذري الأعمق

مكدس الرسوميات في Windows تعرّض لمشكلة في تلك الفترة، مثل:

  • انقطاع/إعادة بناء DWM
  • تفعيل حدث مراقبة الـ GPU (watchdog)
  • عدم استقرار لحظي في تعريف كرت الشاشة أو طوبولوجيا العرض

لذا Typeless ليس المصدر الوحيد للمشكلة، بل أقرب إلى أنه أحد أكثر الضحايا وضوحاً في هذه الحادثة.

بالعودة الآن: ما الأشياء الأكثر إثارة للشك

حسب أولويتي الشخصية:

  1. عدم استقرار لحظي لتعريف كرت الشاشة / مكدس الرسوميات
  2. تكدّس برامج مقيمة من نوع تعزيز النوافذ/الـ overlay بشكل مبالغ فيه
  3. Typeless نفسها لا تتعامل بثبات كافٍ مع تغيّرات طوبولوجيا العرض

ومن “البرامج عالية المخاطر” التي كانت موجودة وقتها:

  • Typeless
  • PixPin
  • alttab_windows
  • NVIDIA Overlay
  • وكذلك CPALauncher الذي حذفته لاحقاً

كل واحد من هذه قد لا يكون فيه مشكلة وحده، لكن عندما تتراكب معاً، يبدو الأمر كأنه اختبار ضغط لـ DWM و D3D11.

لو واجهت عطلاً مشابهاً لاحقاً، كيف سأتعامل أسرع

سأغيّر ترتيب التشخيص إلى التالي:

  1. أتحقق أولاً هل يمكن إدخال المستطيل الأسود داخل لقطة شاشة
  2. إن ظهر في اللقطة، أحكم فوراً أنه نافذة على مستوى البرمجيات وليس تلفاً في الشاشة
  3. أفتح إدارة المهام وأبحث عن عمليات النوافذ العائمة/الـ overlay/اللقط/تعزيز النوافذ
  4. أعدّد النوافذ أو أحدد بصرياً لأي نافذة يتبع المستطيل
  5. أنهي تلك العملية أولاً، ثم أعود لفحص سجلات النظام
  6. وأخيراً أقرر هل أتعامل مع مشكلة تعريف كرت الشاشة الأعمق أم لا

خلاصة مؤقتة

هذه المرة ليست “الشاشة تعطلت”، ولا “Chrome شاشة سوداء” بهذه البساطة.

الأدق هو:

خلل على مستوى سلسلة الرسوميات/DWM أدى إلى إسقاط مجموعة من البرامج المعتمدة على تركيب سطح المكتب؛ ونافذة Status العائمة التابعة لـ Typeless كانت سيئة الحظ، فبقيت في منتصف الشاشة على شكل نافذة شبح سوداء ضخمة.

هذا النوع من المشاكل “ويندوزي” جداً، وهو ممتع أيضاً:

ليس عطلاً يظهر من أول نظرة، بل يجب أولاً أن تتقبل حقيقة أن “المستطيل الأسود هو أيضاً كائن نافذة”، وعندها فجأة يصبح الطريق إلى الحل واضحاً.

إذا لاحقاً ضيّقت أكثر إصدار التعريف، أو شروط تكرار المشكلة، أو أي ميزة محددة داخل Typeless تسبّب هذا الوضع، سأضيف تدوينة متابعة.