حل خطأ WHEA على رايزن بعد PBO وCurve Optimizer

خطأ WHEA ليس شاشة زرقاء عادية، بل بلاغ يرسله المعالج نفسه من طبقة العتاد، ويحمل في سجلّه نوع الخطأ والمكوّن المسؤول وأحياناً رقم النواة الفاشلة بالضبط. لذلك لا ينفع الحلّان المنتشران في المحتوى العربي: sfc /scannow وإعادة تثبيت ويندوز؛ فالأول يفحص ملفات نظام ويندوز المحمية فقط، والثاني يعالج طبقة برمجية لا صلة لها ببلاغ قادم من المعالج. حتى توثيق مايكروسوفت لكود التوقف 0x124 ينصّ صراحةً: إذا كان كسر السرعة مفعّلاً فجرّب تعطيله، ويصنّف التعريفات سبباً أقل احتمالاً. فإذا بدأت الأخطاء بعد تفعيل PBO أو Curve Optimizer أو EXPO، فالسجل سيدلّك على الجاني بدل التخمين — وهذا الدليل يمشي معك من قراءة البلاغ إلى قرار الضمان.

شاشة زرقاء أم إعادة تشغيل صامتة؟

العرض يأتي بشكلين. شاشة زرقاء WHEA_UNCORRECTABLE_ERROR بكود التوقف 0x124 تعني أن المعالج التقط الخطأ وكتبه، وستجد تفاصيله كاملة في السجل. أما إعادة التشغيل الصامتة، إذ تسودّ الشاشة ويقلع الجهاز من جديد، فتترك حدث Kernel-Power 41 بقيم صفرية: انهيار خاطف لم يمهل النظام وقتاً لتسجيل أي خطأ. والشكلان غالباً وجهان لنمط انهيار الخمول نفسه الذي يرافق الأوفست السالب العميق.

لماذا ينهار الجهاز خاملاً ويصمد تحت الحمل الكامل؟

السبب في طبيعة Curve Optimizer نفسها: الأوفست لا يعدّل نقطة تشغيل واحدة، بل يزيح منحنى الجهد والتردد بأكمله نحو الأسفل. والأنوية المفضلة تعزز إلى أعلى تردداتها تحديداً أثناء الأحمال الخفيفة أحادية النواة، بجهد صار أدنى بفعل الأوفست؛ لذلك تكشف لحظات الخمول والانتقالات الخفيفة عدم استقرار يخفيه الإجهاد الكامل، لأن تحميل كل الأنوية معاً يخفض ترددات التعزيز أصلاً. والظاهرة موثّقة عند مؤلف CoreCycler نفسه: نظام صمد يوماً كاملاً تحت الإجهاد الجماعي، ثم فضح الاختبار الفردي نواة واحدة فيه لا تحتمل إلا أوفستاً أضحل بكثير — القصة بأرقامها في مقال شرح Curve Optimizer.

يضاف إلى ذلك سلوك خادع: حين يستشعر المعالج جهداً أدنى مما يحتاجه التردد الحالي، يمدّد دورات الساعة بصمت ليحمي نفسه من الانهيار. التردد المعروض في خانة Core Clock يبقى طبيعياً، بينما ينخفض التردد الحقيقي الذي يظهره عمود Effective Clock في HWiNFO. والنتيجة المزعجة أن أوفستاً «مستقراً» مبالغاً فيه قد يجعل جهازك أبطأ وأنت تحسبه أسرع؛ فلا تحكم على الضبط من التردد المعروض وحده.

وانتبه لصيف منطقتنا الحار: التعزيز حساس للحرارة عبر المنحنى نفسه، فأوفست ضُبط شتاءً واجتاز اختباراته قد يفقد هامشه في غرفة حارة، وتعود أخطاء WHEA دون أن تغيّر شيئاً.

اقرأ السجل قبل أي تعديل

افتح Event Viewer ثم Windows Logs ثم System، ورشّح حسب المصدر WHEA-Logger. نصوص الأحداث تبقى إنجليزية حتى على ويندوز عربي. ثلاثة أرقام تهمك: الحدث 18 خطأ قاتل تسبب في الانهيار، والحدث 19 خطأ صحّحه المعالج دون انهيار، والحدث 17 خطأ PCIe مُصحَّح وقصته مختلفة عن ضبط المعالج؛ فمكوّنه المبلِّغ منفذ PCI Express، وخلفه عادةً بطاقة الرسوميات أو قرص التخزين.

والفرق بين 18 و19 محدد في توثيق مايكروسوفت بدقة: الخطأ المصحَّح أصلحه العتاد أو البرنامج الثابت قبل إبلاغ نظام التشغيل أصلاً، أما القاتل غير المصحَّح فيفرض شاشة زرقاء لاحتواء الضرر. والحدث 18 الحقيقي ليس سطراً واحداً؛ في تبويب التفاصيل ستجد حقولاً مثل ApicId وMCABank وMciStat وErrorType. لا تحاول مطابقة رقم MCABank مع وحدة بعينها داخل المعالج: ترقيم البنوك يختلف بين عائلات المعالجات، ومطابقة جاهزة من منتدى قد تضللك.

نوع الخطأ يرسم دائرة الاشتباه

داخل تفاصيل الحدث سطر يذكر نوع الخطأ. «Cache Hierarchy Error» من مكوّن Processor Core يجعل المشتبه الأول جهد النواة بعد أوفست سالب عميق، وهذا أشيع سيناريو بعد ضبط Curve Optimizer. مع تحفظ ضروري: نوع الخطأ يحدد المُبلِّغ، لا الجاني بالضرورة، وهناك حالة موثّقة بلا أي كسر سرعة انتهى حلّها باستبدال مزود طاقة رديء — فمزود الطاقة الضعيف سبب وارد وإن لم يرد في توثيق رسمي.

أما «Bus/Interconnect Error» فينقل الاشتباه من الأوفست إلى الذاكرة: EXPO وجهد SoC وتردد FCLK، وهو النمط المتكرر في بلاغات مستخدمي AM5 على المنتديات. عندها ابدأ من دليل تفعيل EXPO لرام DDR5 بدل العبث بأرقام الأنوية.

وخلفية هذا النمط — من سقف جهد SoC عند 1.30V الذي فرضته AMD بعد حادثة 2023، إلى فحص نسبة 1:1 بين UCLK وMCLK — مشروحة في دليل EXPO المذكور أعلاه. المهم هنا استنتاج التشخيص: أخطاء Bus/Interconnect بعد تفعيل EXPO على طقم سريع تعني أن التحقيق يبدأ من جهد SoC وتردد FCLK ودرجة الذاكرة، لا من أوفست الأنوية.

أي نواة بالضبط؟

الحدث نفسه يذكر Processor APIC ID. القاعدة مع SMT مفعّل: رقم النواة = APIC ID ÷ 2 مع إهمال الكسر والعدّ من صفر؛ فمثلاً APIC ID 5 يعني النواة 2، وAPIC ID 9 يعني النواة 4.

لكن على المعالجات بشريحتي CCD ناقصتي الأنوية مثل 7900X قد ينقطع تسلسل الترقيم، والفجوة موثّقة على رايزن 5000: في 5900X تأخذ الشريحة الأولى الأرقام من 0 إلى 11 وتستأنف الثانية من 16، فتصبح النواة 6 عند APIC ID 16 و17. ومن المرجّح أن تسلك الأجيال الأحدث مسلكاً مشابهاً، لذا الأسلم ترك CoreCycler يطابق النواة تلقائياً: إعداده الافتراضي يفحص سجل WHEA أثناء الاختبار ويطابق APIC ID مع النواة قيد الفحص. وترقيم الأداة يبدأ من صفر ويوافق مدير المهام، فسطر مثل «Core 6 (CPU 12)» يشير إلى النواة نفسها في كليهما.

كيف يصطاد CoreCycler النواة المريضة؟

الأداة مبنية على الملاحظة السابقة نفسها: الأنوية لا تبلغ أقصى تعزيزها حين تُحمَّل معاً، لذا تثبّت تقارب برنامج الإجهاد على نواة فيزيائية واحدة ثم تتنقل عبر الأنوية كلها بالتناوب. إعداداتها الافتراضية مدروسة لهذا الهدف: Prime95 بنمط SSE مع أحجام Huge FFT لأن حرارة أقل تعني تعزيزاً أعلى، وخيط واحد لكل نواة، وruntimePerCore بقيمة 6m لكل نواة في الجولة، وخيار suspendPeriodically مفعّل يعلّق الحمل دورياً ليولّد تقلبات تشبه استخدام سطح المكتب الحقيقي — وهي بالضبط الظروف التي تسقط فيها الأوفستات المتطرفة. وللاصطياد الأسرع، يوثّق دليل الأداة أن نمطي y-cruncher المسمّيين 04-P4P و19-ZN2 هما الأسرع في كشف الأخطاء على رايزن.

العلاج: نقطتان للنواة الفاشلة وحدها

لا تصفّر كل الأنوية؛ فهذا أشيع ردّ فعل وأكثره كلفة، لأنه يضحي بأداء أنوية سليمة عقاباً على ذنب نواة واحدة. ارفع قيمة الأوفست للنواة الفاشلة وحدها نقطتين إلى ثلاث (من ‎-15 إلى ‎-13 مثلاً)، ثم أعد اختبار تلك النواة تحديداً، ولا تكتفِ باختبارات الحمل الكامل التي رأينا أعلاه كيف تخدع. منهجية الاختبار والتراجع خطوة بخطوة في مقال شرح Curve Optimizer.

ولا تتجاهل الحدث 19 بحجة أن النظام لم ينهر. توثيق CoreCycler صريح: النظام المستقر لا ينتج أي أخطاء أو تحذيرات WHEA، والأداة تعامل التحذير المُصحَّح كفشل حقيقي افتراضياً. التصحيحات المتراكمة إنذار مبكر رخيص، وتجاهلها اليوم يعني مطاردة انهيار عشوائي غداً.

متى لا يكون الأوفست هو السبب؟

خطوة العزل بسيطة، لكن كثيرين يفسدونها بمسح CMOS ثم إعادة تطبيق الملف المحفوظ كاملاً دفعة واحدة — هكذا تُمحى الأدلة من دون تشخيص. العزل الصحيح متغير واحد في كل مرة: صفّر Curve Optimizer مؤقتاً مع إبقاء EXPO مفعّلاً؛ إن استمر الخطأ فالمشكلة في الذاكرة أو الجهود، وإن اختفى فهي في أوفست نواة. ثم اعكس التجربة عند الحاجة.

وهناك اختبار حاسم للعينات المشكوك فيها: عطّل Core Performance Boost مؤقتاً من البايوس، فيثبّت تعطيل CPB الأنوية عند ترددها الأساسي بلا أي تعزيز. إذا توقفت الأخطاء فقط مع CPB معطّلاً وأنت على إعدادات مصنعية، فالمؤشر يتجه نحو عينة معالج متدهورة لا نحو ضبطك.

أما ظهور WHEA على إعدادات مصنعية بالكامل فيعني تحديث البايوس أولاً: عند إطلاق رايزن 5000 وثّق المستخدمون حالات مماثلة، حُلّ كثير منها بتحديثات AGESA وانتهى بعضها باستبدال المعالج نفسه. لكن ضع الأرقام في نصابها قبل اتهام العتاد: أحد المجمّعين زعم نسبة عيوب تقارب 6%، بينما أظهرت بيانات الإرجاع لدى تاجر تجزئة نسباً بين 0.37% و0.77% فقط — المعالج المعيب حقيقي لكنه أندر بكثير مما توحي المنتديات. وقاعدة الضمان واضحة: استمرار أخطاء WHEA على إعدادات مصنعية كاملة مع بايوس محدّث، وخصوصاً إن كانت تختفي بتعطيل CPB وحده، يضعك في أرض مطالبة RMA المشروعة.

راقب العدّاد بعد الإصلاح

HWiNFO يعرض عدّاد أخطاء WHEA ضمن الحساسات، ويجمعه من سجل ويندوز، وأي رقم غير صفري بعد جلسة استخدام يعني أن المشكلة لم تُحل. ولعدّ الأحداث حسب نوعها مباشرة:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} | Group-Object Id -NoElement

وبعد تطبيق إصلاح جديد، احصر العدّ في الأسبوع الأخير وحده:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'; StartTime=(Get-Date).AddDays(-7)} | Group-Object Id -NoElement

ولمن لا يرتاح لسطر الأوامر، يفتح الأمر perfmon /rel مراقب الموثوقية: خط زمني يقيّم استقرار النظام من 1 إلى 10 مع فئة مستقلة لأعطال العتاد — لمحة بصرية سريعة تُظهر هل توقفت الانهيارات بعد تعديلك.

من نص البلاغ إلى خطوتك التالية

ما يقوله السجل	خطوتك التالية
Cache Hierarchy Error	ارفع أوفست النواة الفاشلة نقطتين إلى ثلاث وأعد اختبارها
Bus/Interconnect Error	راجع الذاكرة: EXPO وجهد SoC وتردد FCLK
الحدث 19 يتكرر دون انهيار	عامله كفشل حقيقي واتبع مسار العلاج نفسه
WHEA على إعدادات مصنعية	حدّث البايوس أولاً، ثم اشتبه بالعتاد نفسه
الأخطاء تختفي فقط بتعطيل CPB على إعدادات مصنعية	عينة متدهورة على الأرجح: جهّز مطالبة RMA

القاعدة واحدة في كل الحالات: السجل قبل التعديل. دقيقتان في Event Viewer توفران عليك أياماً من التخمين وإعادة تثبيت لن تصلح شيئاً. وإن كنت لا تزال في مرحلة اختيار القطع، فاختيار اللوحة والتغذية من البداية يقيك نصف هذه المشاكل: دليل تجميع كمبيوتر AM5.