استنزاف وحدة المعالجة المركزية بواسطة ReportCrash على Mac

ما هو ReportCrash على Mac؟

على macOS، يعد ReportCrash معالج الأعطال المدمج الذي يعمل تحت العملية الأم "launchd". كلما تعطل تطبيق أو عملية في الخلفية بشكل غير متوقع، يستيقظ هذا المكون، ويفحص ما حدث، ويكتب تقريرًا تشخيصيًا على القرص حتى يتمكن المطورون (وأحيانًا أنت) من معرفة الخطأ الذي حدث.

من الناحية الفنية، يعمل ReportCrash في نسختين:

• كـ LaunchAgent للعمليات على مستوى المستخدم، حيث يكتب التقارير في مجلد
  ~/Library/Logs/DiagnosticReports/ الخاص بك؛
  
• كـ LaunchDaemon لعمليات النظام وتلك المملوكة للجذر (root)، حيث يخزن التقارير في أدلة سجل التشخيص على مستوى النظام.

في إصدارات macOS الحديثة، يعد الحوار المألوف "تعطل التطبيق، هل تريد إرساله إلى Apple؟" جزءًا من حزمة تقارير أوسع مع Problem Reporter كواجهة أمامية مرئية و ReportCrash الذي يقوم بمعظم العمل الشاق خلف الكواليس.

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

لماذا يمكن لـ ReportCrash احتكار وحدة المعالجة المركزية

عندما ترى ReportCrash يستهلك 50-300% من وحدة المعالجة المركزية (على الأنظمة متعددة النوى) ويظهر باستمرار في مراقب النشاط (Activity Monitor)، فإنه ليس الجاني الفعلي أبدًا تقريبًا. إنه الرسول. المشكلة الحقيقية هي شيء آخر يستمر في التعطل في حلقة ضيقة.

النمط الشائع هو:

1. تنطلق عملية ما.
2. تتعطل على الفور تقريبًا.
3. يقوم launchd بإعادة تشغيلها.
4. يستيقظ ReportCrash لمعالجة فشل آخر.
5. يتكرر هذا بلا توقف.

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

تشمل الجناة الأساسيين المعتادين:

• شياطين المزامنة والفهرسة (مثل جهات الاتصال، الاقتراحات، أو الخدمات المتعلقة بالبحث) التي تختنق بالبيانات التالفة؛
• تطبيقات شريط القائمة أو المساعدين من جهات خارجية التي تعطلت بعد تحديث macOS؛
• بقايا التطبيقات التي تم إلغاء تثبيتها والتي تستمر LaunchAgents أو LaunchDaemons الخاصة بها في بدء تشغيل ملفات ثنائية لم تعد موجودة؛
• أدوات المطورين أو المحاكيات (Xcode، محاكيات iOS، إلخ) حيث يتعطل مكون بشكل متكرر أثناء الاختبار.

باختصار، ReportCrash صاخب لأن شيئًا آخر مريض. الهدف هو العثور على ذلك "الشيء"، وإصلاحه أو إزالته، وعندها فقط التفكير في لمس ReportCrash نفسه.

بالمناسبة، هذا النمط مشابه جدًا لقصص وحدة المعالجة المركزية العالية الأخرى التي قمت بتغطيتها والتي تتضمن chronod، contactsd، syspolicyd، و wdavdaemon – عامل صغير في الخلفية يخرج عن المسار ويسحب أداء النظام معه للأسفل.

كيفية إصلاح الاستخدام العالي لوحدة المعالجة المركزية بواسطة ReportCrash على Mac

الخطوة 1. حدد ما الذي يتعطل في حلقة

إذا فعلت شيئًا واحدًا فقط، فافعل هذا. تحتاج إلى معرفة أي عملية تسحب ReportCrash إلى وضع الإرهاق.

1. افتح Console
   • اضغط على Command–Space، واكتب Console، واضغط على Return.
2. في الشريط الجانبي، ابحث عن Crash Reports (أو استخدم قسم "Crash Reports" تحت "Reports").
3. قم بالفرز حسب التاريخ (Date) وتحقق من الإدخالات الأحدث:
   • من المحتمل أن ترى نفس اسم العملية يتكرر عدة مرات في فترة زمنية قصيرة.
4. إذا بدت تقارير الأعطال (Crash Reports) فارغة، فانتقل إلى:
   • system.log أو All Messages، ثم ابحث عن مصطلحات مثل crash، Service only

دوّن:

• اسم العملية المسيئة (مثل suggestd، تطبيق شريط القائمة، مساعد ما)،
• مسارها إذا كان مرئيًا، و
• تقريبًا كم مرة تتعطل.

هذا هو المشتبه به الرئيسي.

الخطوة 2. إزالة أو إصلاح التطبيق أو المكون المسيء

بمجرد معرفة ما الذي يتعطل، فإن أفضل حل عادة هو تحديث أو إعادة تعيين أو إلغاء تثبيت ذلك العنصر المحدد.

1. إذا كان تطبيقًا عاديًا تعرفه وتستخدمه:
   • قم بإنهائه إذا كان قيد التشغيل.
   • تحقق من وجود تحديث في قائمته (غالبًا AppName ▸ Check for Updates) أو عبر متجر App Store.
   • إذا استمرت الأعطال، جرب إعادة تثبيت نظيفة:
     • اسحب التطبيق من التطبيقات (Applications) إلى سلة المهملات.
     • أعد التشغيل.
     • قم بتنزيل نسخة جديدة من المصدر الرسمي وأعد التثبيت.
2. إذا كان تطبيقًا لم تعد تهتم به:
   • في التطبيقات (Applications)، قم بإزالته مع أدوات المساعدة الواضحة (برامج إلغاء التثبيت، برامج التحديث).
   • ثم تحقق من المكونات المتبقية في:
     • ~/Library/Application Support/
     • ~/Library/LaunchAgents/
     • /Library/LaunchDaemons/
   • احذف فقط العناصر المرتبطة بوضوح بذلك التطبيق (التي تطابق اسمه أو اسم البائع).

3. إذا كانت خدمة نظام (مثل suggestd، أو متعلقة بجهات الاتصال، أو مزامنة iCloud):
   • قم بتعطيل الميزات المرتبطة مؤقتًا:
     • أوقف الحسابات التي بها مشاكل في إعدادات النظام ▸ حسابات الإنترنت.
     • قم بتبديل الخدمات مثل iCloud Contacts، أو Siri & Spotlight suggestions، أو عناصر مماثلة إلى إيقاف التشغيل، وانتظر قليلاً، ثم أعد تشغيلها.
   • إذا هدأت عاصفة وحدة المعالجة المركزية بعد تعطيل حساب أو ميزة معينة، فمن المحتمل أن تكون البيانات التالفة موجودة هناك.

الفكرة بسيطة: إذا اختفى الشيء الذي يستمر في التعطل أو بدأ في التصرف بشكل صحيح، فلن يكون لدى ReportCrash سبب للعمل بلا توقف.

الخطوة 3. مسح سجلات الأعطال والتشخيصات الضخمة

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

يمكنك تنظيفها بأمان على النحو التالي:

1. في Finder، اضغط على Shift–Command–G لفتح Go to Folder…
2. قم بزيارة هذه المواقع واحدًا تلو الآخر:
   • ~/Library/Logs/DiagnosticReports/
   • /Library/Logs/DiagnosticReports/ (قد تحتاج إلى حقوق المسؤول)
3. انقل ملفات .crash و .panic القديمة إلى سلة المهملات (أو مجلد أرشيف إذا كنت تريد نسخة احتياطية).
4. أفرغ سلة المهملات عندما تتأكد من استقرار كل شيء.

لن يوقف هذا استخدام وحدة المعالجة المركزية لـ ReportCrash بشكل مباشر إذا استمر السبب الجذري، لكنه يبقي جهاز Mac الخاص بك مرتبًا ويمكن أن يقلل قليلاً من الإدخال/الإخراج في الخلفية.

الخطوة 4. تعطيل عناصر تسجيل الدخول والمساعدين في الخلفية التي بها مشاكل

سيناريو شائع جدًا هو وجود عنصر تسجيل دخول أو LaunchAgent لتطبيق منسي منذ فترة طويلة يحاول بدء تشغيل شيء لم يعد موجودًا. يفشل ذلك الملف الثنائي في الإطلاق بشكل صحيح، ويتعطل على الفور، ويتم إغراق ReportCrash بالرسائل.

قم بالتنظيف التالي:

1. تحقق من عناصر تسجيل الدخول (Login Items)
   • اذهب إلى إعدادات النظام ▸ عام ▸ عناصر تسجيل الدخول.
   • تحت كل من فتح عند تسجيل الدخول و السماح في الخلفية، قم بتعطيل العناصر التي لا تتعرف عليها أو لم تعد تستخدمها.
2. افحص LaunchAgents و LaunchDaemons
   في Finder، استخدم Go ▸ Go to Folder… وانظر في:
   • ~/Library/LaunchAgents/
   • /Library/LaunchAgents/
   • /Library/LaunchDaemons/
   
   
3. لكل مجلد:
   • قم بالفرز حسب الاسم وابحث عن العناصر التي تنتمي بوضوح إلى التطبيقات التي تم إلغاء تثبيتها.
   • انقل ملفات .plist المشبوهة إلى مجلد مؤقت على سطح المكتب بدلاً من حذفها مباشرة.
   • أعد التشغيل وراقب مراقب النشاط (Activity Monitor) لمعرفة ما إذا كان ReportCrash يهدأ.

إذا كان كل شيء يعمل بشكل جيد لبضعة أيام، فيمكنك حذف ملفات .plist المعزولة بأمان. إذا تعطل شيء مهم، أعد نقلها.

الخطوة 5. الاختبار في الوضع الآمن (Safe Mode)

الوضع الآمن هو طريقة سريعة لمعرفة ما إذا كانت المكونات الخارجية متورطة. في وضع التشخيص هذا، يقوم macOS بتحميل الامتدادات الأساسية فقط ويعطل معظم عناصر تسجيل الدخول و LaunchAgents.

1. قم بإيقاف تشغيل جهاز Mac الخاص بك.
2. قم بتشغيله و اضغط باستمرار على المفتاح المناسب لنوع وحدة المعالجة المركزية الخاصة بك:
   • Intel Mac: اضغط باستمرار على Shift فور سماع نغمة بدء التشغيل حتى ترى نافذة تسجيل الدخول.
   • Apple silicon Mac:
     • اضغط باستمرار على زر الطاقة حتى يظهر "تحميل خيارات بدء التشغيل".
     • حدد قرص بدء التشغيل الخاص بك، واضغط باستمرار على Shift، ثم انقر فوق متابعة في الوضع الآمن.
3. قم بتسجيل الدخول وافتح مراقب النشاط (Activity Monitor).

إذا كان ReportCrash هادئًا في الوضع الآمن ولكنه يجن جنونه مرة أخرى بعد إعادة تشغيل طبيعية، فأنت تتعامل بشكل شبه مؤكد مع برامج تابعة لجهات خارجية (عناصر تسجيل الدخول، امتدادات النواة، أدوات المساعدة). استخدم هذا الدليل لإعادة زيارة الخطوتين 2 و 4 بشكل أكثر عدوانية.

الخطوة 6. إعادة تعيين SMC و NVRAM (للحالات المستعصية)

بينما لا يرتبط ذلك بشكل مباشر بـ ReportCrash، فإن الخلل ذي المستوى المنخفض في إدارة الطاقة أو حالة الأجهزة يظهر أحيانًا كأعطال عشوائية ومتكررة وعدم استقرار النظام. يمكن أن تساعد إعادة تعيين SMC (أجهزة Intel Mac) و NVRAM في إزالة تلك الشوائب.

يعتمد الإجراء على طراز جهاز Mac الخاص بك، ولكن بشكل عام:

• إعادة تعيين NVRAM (Intel Macs):
  1. قم بإيقاف تشغيل جهاز Mac الخاص بك.
  2. قم بتشغيله واضغط فورًا مع الاستمرار على Option–Command–P–R.
  3. استمر في الضغط على المفاتيح لمدة 20 ثانية تقريبًا، ثم حررها.
• إعادة تعيين SMC (Intel Macs):
  تختلف الخطوات بالنسبة لـ MacBook ببطارية قابلة للإزالة/غير قابلة للإزالة، و iMac، و Mac mini. راجع تعليمات Apple لطرازك الدقيق وإصدار macOS.
  

على أجهزة Apple silicon Macs، لا توجد إعادة تعيين منفصلة لـ SMC أو NVRAM – فتسلسل إيقاف التشغيل والتشغيل النظيف يقوم بنفس الشيء بشكل فعال.

إذا استمر الاستخدام العالي لوحدة المعالجة المركزية لـ ReportCrash حتى بعد استبعاد الأسباب على مستوى التطبيق وإجراء عمليات إعادة التعيين هذه، فأنت في منطقة "التعديلات المتقدمة".

الخطوة 7. (متقدم) تعطيل ReportCrash مؤقتًا

هذه الخطوة اختيارية وموجهة للمستخدمين ذوي الخبرة. في البيئات التي توجد فيها حلقة تعطل معروفة لا مفر منها (مثل الـ fuzzing، أو إعدادات اختبار محددة)، يختار بعض المسؤولين تعطيل ReportCrash حتى لا يهدر الموارد في إنشاء سجلات لا نهاية لها.

بالنسبة لجهاز Mac منزلي أو مكتبي عادي، أوصي بهذا فقط كـ حل مؤقت قصير المدى أثناء تعقب الجاني الحقيقي، وليس كإصلاح دائم. ستفقد تشخيصات الأعطال التلقائية وقد تخفي علامات لمشاكل أعمق.

إذا كنت لا تزال ترغب في المتابعة، فيمكنك تفريغ LaunchAgent و LaunchDaemon الخاص بـ ReportCrash من Terminal:

1. افتح Terminal من التطبيقات ▸ الأدوات المساعدة.
2. قم بتشغيل هذه الأوامر بعناية (سيُطلب منك كلمة مرور المسؤول للأمر الثاني):

launchctl unload -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

يمنع هذا ReportCrash من البدء تلقائيًا لعمليات المستخدم والنظام.

لـ إعادة تمكين الإبلاغ عن الأعطال لاحقًا، قم بتشغيل:

launchctl load -w /System/Library/LaunchAgents/com.apple.ReportCrash.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.ReportCrash.Root.plist

مرة أخرى، تعامل مع هذا كملاذ أخير، وليس كخطوتك الأولى. إذا كان تعطيل ReportCrash يبدو وكأنه "يحل" المشكلة، فقد قمت في الواقع بإزالة مقياس الحرارة فقط، ولم تعالج الحمى.

كيفية منع مشاكل ReportCrash مستقبلاً

لا يمكنك إيقاف كل عطل، ولكن يمكنك تقليل احتمالات حدوث حادث ReportCrash جامح من خلال الالتزام ببعض العادات:

• حافظ على تحديث macOS والتطبيقات الأساسية: تعد إصلاحات الاستقرار أمرًا ثابتًا في ملاحظات إصدار النظام والتطبيقات.
• كن انتقائيًا مع عناصر بدء التشغيل: راجع بانتظام عناصر تسجيل الدخول وقم بتعطيل أي شيء لا تحتاج إلى تحميله عند كل تمهيد.
• إلغاء تثبيت التطبيقات بشكل نظيف: عند التوقف عن استخدام تطبيق ما، قم بإزالة ملفات الدعم ومساعدي الإطلاق الخاصة به، وليس فقط الحزمة الرئيسية في التطبيقات.
• تجنب المثبتات والحزم المشبوهة: تعد البرامج الإعلانية ووكلاء الخلفية المكتوبون بشكل سيء مصدرًا شائعًا للأعطال الغريبة، وليس فقط خاطفي المستعرض.
• راقب مراقب النشاط: إذا زادت سرعة المراوح فجأة، فإن نظرة سريعة على علامتي تبويب CPU و Energy يمكن أن تلتقط العمليات التي تسيء التصرف قبل أن تتحول إلى مشاكل مزمنة.

الخلاصة

عندما يبدأ التأثير على وحدة المعالجة المركزية، فإن إلقاء اللوم على ReportCrash نفسه هو سوء فهم. عندما تحتكر العملية وحدة المعالجة المركزية لساعات، فهذا مؤشر قوي على أن بعض التطبيقات أو الخدمات أو المكونات المتبقية عالقة في حلقة تعطل وإعادة تشغيل لا هوادة فيها.

الحل عادة ما يكون منهجيًا وليس دراميًا: حدد ما الذي يتعطل، وقم بإصلاحه أو إزالته، ونظف عناصر تسجيل الدخول و LaunchAgents، وعندها فقط فكر في اتخاذ تدابير متقدمة مثل تعطيل ReportCrash مؤقتًا. بمجرد اختفاء عدم الاستقرار الأساسي، يجب أن يعود جهاز Mac الخاص بك إلى سلوكه المعتاد الهادئ والبارد وغير المزعج.

أسئلة متكررة

1. هل ReportCrash فيروس أو برنامج ضار على Mac؟

2. هل من الآمن إنهاء عملية ReportCrash في مراقب النشاط؟

3. كيف أعرف أي تطبيق يتسبب في استخدام ReportCrash لوحدة المعالجة المركزية العالية؟

4. هل يمكنني تعطيل الإبلاغ عن الأعطال على جهاز Mac الخاص بي بشكل دائم؟

5. متى يجب أن أفكر في إعادة تثبيت macOS لإصلاح مشاكل ReportCrash؟