جمع crash dumps لتطبيقات Windows: متى تبدأ بـ WER أو ProcDump أو WinDbg

بمجرّد أن يبدأ تطبيق Windows في عرض روتين «يتعطّل أحياناً فقط»، تصبح السجلّات وحدها غير كافية في الغالب.

ينطبق ذلك خاصّةً عندما:

• يحدث التعطّل في بيئة العميل فقط
• لديك رسالة الاستثناء لكن سياق الاستدعاء غير كافٍ
• يعبر النظام managed code و COM و P/Invoke و native DLLs أو vendor SDKs
• لا يظهر العطل إلّا بعد فترة تشغيل طويلة

هنا تصبح crash dumps مفيدة.
إن التقطت حالة العمليّة في لحظة العطل، فإنّك تستطيع لاحقاً فحص exception code، والـ thread الذي تعطّل، والـ stack، والـ modules المحمّلة، وأحياناً جزءاً أكبر بكثير من حالة العمليّة.

في Windows، أسهل طريقة للتفكير في جمع dumps عادةً هي:

• ابدأ بـ WER LocalDumps
• أضِف ProcDump عندما تحتاج شروط الإطلاق إلى تحكّم أكبر
• لا تلجأ إلى MiniDumpWriteDump إلّا عندما تحتاج فعلاً إلى مسار جمع خاصّ بك

هذه المقالة مقدّمة لطبقة القرار الأولى تلك لتطبيقات سطح المكتب والتطبيقات المقيمة وخدمات Windows وأدوات تكامل الأجهزة.

1. النسخة المختصرة

• لخطّ أساس آمن في الإنتاج، اضبط WER LocalDumps لكلّ تطبيق على حدة.
• إن احتجت إلى تحقيق منخفض إعادة الإنتاج، أو التقاط first-chance exception، أو التقاط hang، فإنّ ProcDump عادةً ما يكون الأداة التالية.
• فكّر في الجمع المُدار ذاتيّاً أخيراً، لا أوّلاً.
• dumps ليست سوى جزء من القصّة؛ الـ PDBs والـ binaries المُسلَّمة بالضبط مهمّة بنفس القدر.
• full dumps قويّة، لكنّها أيضاً كبيرة وأكثر احتمالاً لاحتواء معلومات حسّاسة. ينبغي تحديد سياسة الاحتفاظ والتخزين والوصول مبكّراً.

أبسط مصفوفة بداية تبدو غالباً كالتالي:

باختصار:

ابدأ بـ WER، ثمّ ProcDump، ثمّ الجمع المخصّص.

2. ما الذي يستطيع crash dump إخبارك به فعلاً

crash dump هو لقطة للعمليّة في لحظة معيّنة.

إنّه جيّد في إخبارك بأشياء مثل:

• ما هو exception code الذي حدث
• أيّ thread تعطّل
• كيف بدا الـ stack في تلك النقطة
• أيّ modules كانت محمّلة
• اعتماداً على حجم dump، بعض حالة الذاكرة أو كلّها

إنّه أضعف بكثير في إخبارك بأشياء مثل:

• التسلسل الزمنيّ الكامل الذي أوصل إلى ذلك
• التدهور البطيء عبر عدّة ساعات
• حالة النظام الخارجيّ في ذلك الوقت
• سياق العمل الكامل قبل التعطّل مباشرةً

لذلك تعمل dumps بأفضل شكل عندما تُدمج مع السجلّات أو بيانات heartbeat أو قياسات أخرى بدلاً من معاملتها كمصدر الحقيقة الوحيد.

3. خيارات الجمع الرئيسيّة

على المستوى التمهيديّ، تهمّ أربعة مسارات جمع أكثر من غيرها:

أهمّ قرار عمليّ غالباً ليس «أيّ أداة» بل:

• تحت أيّ شروط يتمّ الالتقاط
• أين يُخزَّن dump
• ما حجم dump المطلوب

4. أسهل خطوة أولى: WER LocalDumps

4.1 قيم الـ registry التي تهمّ أوّلاً

يوفّر Windows Error Reporting خاصّيّة LocalDumps لالتقاط dumps في وضع المستخدم.
إنّها خطوة أولى عمليّة جدّاً لأنّها لا تتطلّب توزيع أداة إضافيّة.

المفتاح الأساسيّ هو:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

من الناحية العمليّة، يكون عادةً أنظف استخدام مفتاح فرعيّ خاصّ بالتطبيق:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe

أوّل ثلاث قيم ينبغي الاهتمام بها هي:

4.2 مثال على إعداد خاصّ بالتطبيق

على سبيل المثال، للاحتفاظ بما يصل إلى 10 full dumps لـ MyApp.exe في C:\CrashDumps\MyApp:

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpFolder /t REG_EXPAND_SZ /d "C:\CrashDumps\MyApp" /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpCount /t REG_DWORD /d 10 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 2 /f

التفاصيل المفيدة هنا هي:

• حدّده على executable واحد
• اكتب إلى مجلّد مخصّص
• ابدأ بـ full dumps عندما يكون الهدف هو التحقيق الفعليّ
• حدّد العدد المحتفظ به

إن كان تخزين الإنتاج ضيّقاً، خفّض DumpType إلى 1 لـ mini dumps.

4.3 تحقّق من مسار الجمع قبل انتظار حادث حقيقيّ

لا تنتظر أوّل تعطّل حقيقيّ لدى العميل لتكتشف أنّ مسار الجمع كان خاطئاً.

تحقّق على الأقلّ من:

1. ظهور ملفّ .dmp في المجلّد المتوقّع
2. ملاءمة الحجم للتوقّع التشغيليّ
3. قدرة WinDbg على فتحه
4. وضوح التعطّل في سجلّ Application

إدخالات Event Viewer مثل Application Error وأحداث WER reporting مفيدة لتأكيد أنّ مسار الفشل مرئيّ على الأقلّ للنظام.

5. عندما يكون ProcDump هو الأداة الأفضل

غالباً ما يكون WER كافياً، لكنّ ProcDump يصبح جذّاباً عندما تحتاج إلى تحكّم أكبر:

• لا تريد إعداداً دائماً مبنيّاً على الـ registry
• تريد فقط مراقبة عمليّة قيد التشغيل بالفعل
• تريد الانتظار للإطلاق التالي
• تحتاج إلى first-chance exceptions
• تحتاج إلى التقاط hang
• تحتاج إلى سلوك إطلاق شرطيّ

5.1 الخيارات الشائعة التي تستحقّ الحفظ مبكّراً

لنموذج ذهنيّ تمهيديّ:

• الأعطال -> -e
• مراقبة الاستثناءات المبكّرة -> -e 1
• hangs -> -h
• full dumps أوّلاً -> -ma
• تحديد عدد dumps -> -n

5.2 أمثلة شائعة على الأوامر

الإلحاق بعمليّة قيد التشغيل بالفعل والتقاط full dumps عند exception غير معالج

procdump -accepteula -ma -e 1234 C:\CrashDumps\MyApp

الانتظار للإطلاق التالي والتقاط full dumps عند exception غير معالج

procdump -accepteula -ma -e -w MyApp.exe C:\CrashDumps\MyApp

إطلاقها تحت ProcDump والمراقبة فوراً

procdump -accepteula -ma -e -x C:\CrashDumps\MyApp MyApp.exe

التقاط first-chance exceptions أيضاً

procdump -accepteula -ma -n 3 -e 1 MyApp.exe C:\CrashDumps\MyApp

التقاط hangs

procdump -accepteula -h MyApp.exe C:\CrashDumps\MyApp

5.3 لماذا لا ينبغي أن يكون -i هو الخطوة الأولى

يستطيع ProcDump تثبيت نفسه بوصفه postmortem debugger مع -i، لكنّ ذلك يؤثّر على سلوك التعطّل على مستوى الجهاز بأكمله.
ذلك يجعله خطوة أولى أثقل ممّا قد يبدو في البداية.

على جهاز مشترك أو نظام عميل، يكون عادةً أكثر أماناً البدء بـ:

• WER LocalDumps خاصّة بالتطبيق
• أو ProcDump مرتبط عبر -w أو -x أو PID

6. متى تفكّر في MiniDumpWriteDump

الجمع المُدار ذاتيّاً منطقيّ في حالات مثل:

• زرّ في واجهة المستخدم لـ «حفظ بيانات التشخيص»
• تجميع السجلّات والإعدادات وdump معاً
• جمع بيانات العمليّات المساعدة ذات الصلة أيضاً
• تطبيق إخفاء بياناتك الخاصّ أو التغليف قبل التحميل

الـ API الرئيسيّ لذلك المسار هو MiniDumpWriteDump.

لكنّ قاعدتين عمليّتين تهمّان فوراً:

1. يُفضَّل استدعاؤه من عمليّة أخرى إن أمكن
2. عامِل عائلة DbgHelp بوصفها بنية تحتيّة فعليّاً single-threaded

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

7. الاختيار بين mini dumps و full dumps

هذا أحد أكثر الأسئلة شيوعاً.

القاعدة العمليّة الصديقة للمبتدئين هي:

• full dump على أجهزة التطوير والاختبار
• mini أو full في بيئات العميل بحسب التخزين والحساسيّة
• يُفضَّل full dumps عندما تكون native DLLs أو COM أو P/Invoke أو memory corruption أو مشكلات الحالة طويلة المدى متورّطة

8. حدّد القواعد التشغيليّة مبكّراً

يفشل جمع dumps تشغيليّاً قبل أن يفشل تقنيّاً في الغالب.

8.1 احتفظ بالـ PDBs والـ binaries المُسلَّمة بالضبط

هذه أهمّ نقطة.

تحتاج إلى الاحتفاظ بـ:

• إصدارات EXE / DLL المُسلَّمة بالضبط
• الـ PDBs المطابقة
• هويّة الـ build أو الـ commit التي أنتجتها

بدون ذلك، حتى dump مُلتقَط بشكل مثاليّ يمكن أن يكون أصعب بكثير في القراءة.

8.2 حدّد إلى أين تذهب dumps وكم تبقى

تصبح full dumps كبيرة بسرعة كبيرة.

حدّد مبكّراً:

• لا تحتفظ بها إلى أجل غير مسمّى على قرص النظام
• استخدم مجلّداً مخصّصاً
• حدّد العدد بـ DumpCount أو ProcDump -n
• افصل التخزين قصير المدى عن الاحتفاظ طويل المدى عند الحاجة

8.3 حدّد من يُسمح له بالوصول إليها

يمكن أن تحتوي full dumps على معلومات حسّاسة:

• إعدادات نصّ صريح
• connection strings
• tokens أو credentials
• بيانات عمل تمّ التعامل معها مؤخّراً
• مسارات وأسماء مستخدمين

لذا فإنّ «من يجوز له قراءة dumps أو استلامها» يحتاج إلى سياسة، لا مجرّد مجلّد.

8.4 اقرن dumps بالسجلّات

تكون dumps أقوى عندما تحتفظ أيضاً بأشياء مثل:

• معلومات الإصدار
• arguments الإطلاق
• معرّفات العمليّة أو المهمّة
• آخر أحداث السجلّ المهمّة
• ملخّص حالة الـ endpoint أو الجهاز الهدف

8.5 تحقّق من التدفّق باستخدام Release build

تحدث الأعطال الحقيقيّة عادةً في Release builds، لا في Debug builds.

لذلك ينبغي التحقّق من الجمع في بيئة شبيهة بـ Release أيضاً.

9. أقصر مسار تحليل مفيد بعد الجمع

9.1 ثبّت WinDbg

في هذه الأيّام، يسهل الحصول على WinDbg من Store أو winget:

winget install Microsoft.WinDbg

9.2 افتح dump

windbg -z C:\CrashDumps\MyApp\MyApp_YYMMDD_HHMMSS.dmp

لا يحتاج جهاز التحليل أن يكون نفس الجهاز الذي تعطّل.

9.3 إعداد الرموز

ابدأ برموز Microsoft العامّة، ثمّ أضِف موقع PDB الخاصّ بك:

.symfix C:\Symbols\Microsoft
.sympath+ C:\Symbols\MyApp
.reload

9.4 ابدأ بالتحليل التلقائيّ

!analyze -v

ثمّ افحص:

• exception code
• الـ module المُسبّب للعطل
• مقدار ما يظهر من كودك في الـ stack
• ما إذا كانت الـ threads الأخرى تُظهر أيضاً انتظارات أو حصاراً مشبوهاً

10. الفخاخ الشائعة

10.1 dump موجود، لكن الـ PDBs ليست كذلك

هذا شائع للغاية.
نجح الجمع، لكنّ مادّة التحليل غير مكتملة.

10.2 لم يتحقّق أحد من الـ ACL على DumpFolder

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

10.3 full dumps تستمرّ في ملء قرص النظام

هذا حادث تشغيليّ كلاسيكيّ.
ينبغي التخطيط مسبقاً لحدود الاحتفاظ ومجلّدات dump المعزولة.

10.4 توقّع أنّ WER وحده يحلّ تحقيق الـ hang

WER LocalDumps أداة أولى قويّة لالتقاط الأعطال.
سيناريوهات hangs و first-chance exceptions تلائم ProcDump بشكل أفضل في الغالب.

10.5 ترك -e 1 مفعّلاً إلى الأبد

التقاط first-chance exceptions قويّ ومُزعج.
استخدمه بحدود أو نوافذ زمنيّة أو نطاق مستهدف.

10.6 نسيان أنّ التطبيق يحتوي بالفعل على crash reporters مخصّصة

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

11. الخلاصة

crash dumps هي إحدى أقوى نقاط المراقبة لأعطال Windows منخفضة إعادة الإنتاج.
تصبح أكثر قيمة عندما تكون COM أو P/Invoke أو native DLLs أو السلوك طويل المدى جزءاً من النظام.

ترتيب بداية نظيف هو:

1. ابدأ بـ WER LocalDumps خاصّة بالتطبيق
2. أضِف ProcDump عندما يهمّ التحكّم في الإطلاق
3. انتقل إلى MiniDumpWriteDump فقط عندما تحتاج فعلاً إلى سير عمل جمع مخصّص

هذا الترتيب يُبقي الحلّ عمليّاً ويتجنّب جعل الخطوة الأولى أثقل ممّا يحتاج إليها.

12. المراجع

• Microsoft Learn: Collecting User-Mode Dumps - Win32 apps
• Microsoft Learn: ProcDump v11.1 - Sysinternals
• Microsoft Learn: MiniDumpWriteDump function
• Microsoft Learn: User-mode dump files
• Microsoft Learn: Analyzing a user-mode dump file
• Microsoft Learn: Install WinDbg
• Microsoft Learn: Symbol path for Windows debuggers
• Microsoft Learn: !analyze (WinDbg)
• Microsoft Learn: Troubleshoot processes by using Task Manager
• Microsoft Learn: Enabling Postmortem Debugging

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.