مدخل إلى جمع dump انهيار تطبيقات Windows: WER / ProcDump / WinDbg

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

الأصعب خصوصاً حالات كهذه.

• لا يقع إلا في بيئة العميل
• رسالة الاستثناء مأخوذة لكن سياق جهة الاستدعاء ناقص
• لا الجانب المُدار من C# / .NET وحده، بل يتداخل COM وP/Invoke وDLL أصلي وSDK مورّد
• لا يسقط إلا بعد تشغيل طويل

هنا ينفع dump الانهيار. إن أسقطت حالة العملية لحظة الانهيار في ملف، أمكن لاحقاً قراءة رمز الاستثناء ومكدّس الخيط الذي سقط والوحدات المحمّلة وجزء من الذاكرة أو كلّها.

على Windows، أوضح أن تفكّر بالترتيب: أولاً LocalDumps لـ WER، ثم Sysinternals ProcDump عند الحاجة، ثم MiniDumpWriteDump إن أردت مزيد تحكّم. ترتّب هذه المقالة الخطوة الأولى في جمع dump الانهيار بافتراض تطبيقات سطح مكتب Windows، وتطبيقات مقيمة، وخدمات Windows، وأدوات ربط أجهزة.

flowchart TB
    accTitle: ترتيب التفكير في وسيلة الجمع
    accDescr: مخطّط يبيّن أن جمع dump الانهيار في Windows أوضح بالتفكير بهذا الترتيب: أولاً LocalDumps لـ WER، ثم ProcDump من Sysinternals عند الحاجة، ثم MiniDumpWriteDump إن أردت مزيد تحكّم.
    w1["أولاً WER LocalDumps"] --> w2["ProcDump عند الحاجة"]
    w2 --> w3["MiniDumpWriteDump إن أردت مزيد تحكّم"]

الشكل 1: ابدأ بالوظيفة القياسية، ولا تضف أداة إلا بقدر النقص.

مصطلحات تتكرّر في هذه المقالة

نثبّتها باختصار أولاً. إن بقيت غامضة ضبابت الفصول اللاحقة.

1. الخلاصة أوّلاً

النقاط التي يُراد تثبيتها أولاً فقط.

• أولاً ضبط WER LocalDumps لكل تطبيق مأمون. تُبقي dump محلياً بعد الانهيار بلا أدوات إضافية.
• لتحقيق ميداني منخفض الإعادة، أو لرؤية first chance exception / hang أيضاً، استخدم ProcDump.
• الجمع الذاتي يُفكَّر فيه أخيراً تقريباً. يكفي النظر في MiniDumpWriteDump عندما يلزم.
• حفظ PDB والثنائي الموزَّع أهمّ بقدر الـ dump نفسه. حتى مع dump، بلا رموز ينقص المقروء كثيراً.
• الفل dump قوي، لكن الحجم وخطر اختلاط معلومات سرّية قويان أيضاً. قرّر موضع الحفظ وعدد الاحتفاظ وصلاحية الوصول وإجراءات المشاركة مسبقاً.

التكوين الموصى به في مرحلة المدخل يستقر تقريباً هنا.

باختصار: أولاً WER، ثم ProcDump، وأخيراً الذاتي. إن عكست الترتيب ثقل التصميم غالباً.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 21، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما الذي يتّضح من dump الانهيار

dump الانهيار «لقطة تلك اللحظة». أقرب إلى صورة ثابتة لمسرح حادث منه إلى كاميرا مراقبة.

لذلك هذه المعلومات سهلة الأخذ جدّاً.

• بأي رمز استثناء سقط
• أي خيط سقط
• مكدّس الاستدعاء في تلك اللحظة
• الوحدات المحمّلة
• بحسب كم الذاكرة المضمَّن، حالة الكومة ومحتوى الكائنات

بالمقابل، ما ينقص من الـ dump وحده بسهولة أيضاً.

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

لذلك في الميدان الأساس عدم محاولة الاكتمال بالـ dump وحده، والجمع مع سجلات أو heartbeat.

flowchart TB
    accTitle: الجمع بين الـ dump والسجلات
    accDescr: مخطّط يبيّن أن dump الانهيار قوي في حالة تلك اللحظة كلقطة ثابتة لمسرح حادث، وأن التسلسل حتى تلك اللحظة والحالة الخارجية تكمّلها السجلات أو heartbeat، لذلك الأساس استخدام الاثنين معاً.
    d1["dump الانهيار (لقطة اللحظة)"] --> mix["حقّق بالجمع"]
    d2["سجلات أو heartbeat (تسلسل زمني)"] --> mix
    d1 -.-> s1["قوي في رمز الاستثناء والمكدّس"]
    d2 -.-> s2["قوي في المسار حتى الوصول"]

الشكل 2: لقطة الـ dump وتسلسل السجلات ينقسم اختصاصهما بوضوح.

3. الصورة الكلّية لوسائل الجمع

في جمع dump لتطبيق Windows، الوسائل التي يُراد تثبيتها في مرحلة المدخل أربع.

الأهم للمبتدئ: قبل «بما تأخذ»، قرّر «بأي شرط» و«إلى أين» و«بأي حجم» تأخذ.

flowchart TB
    accTitle: ما يُقرَّر قبل الأداة
    accDescr: مخطّط يبيّن أنه في جمع dump الانهيار المهم تقرير بأي شرط وإلى أين وبأي حجم تأخذ أولاً، ثم الانتقال إلى اختيار الأداة.
    c1["بأي شرط تأخذ"] --> firstq["ثلاث نقاط تُقرَّر أولاً"]
    c2["إلى أين تُخرج"] --> firstq
    c3["بأي حجم تأخذ"] --> firstq
    firstq --> tool["ثم اختر الأداة"]

الشكل 3: إن قرّرت الشرط وموضع الإخراج والحجم، لم تحتَر في اختيار الأداة.

4. التوصية الأولى WER LocalDumps

4.1 قيم السجل التي تُنظر أولاً

في Windows Error Reporting (WER) يوجد LocalDumps يحفظ dump وضع المستخدم محلياً بعد الانهيار. لا تحتاج توزيع أدوات إضافية، فيسهل جدّاً كخطوة أولى.

المفتاح الأساسي هنا.

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

يمكن وضع إعداد عام هنا، لكن في الميدان الميل إلى مفتاح فرعي لكل تطبيق أسهل.

flowchart TB
    accTitle: موضع وضع إعداد LocalDumps
    accDescr: مخطّط يبيّن أنه يمكن وضع إعداد عام تحت مفتاح LocalDumps مباشرة، لكن في الميدان الميل إلى مفتاح فرعي لكل تطبيق مثل MyApp.exe أسهل.
    key1["مفتاح LocalDumps"] --> g1["إعداد عام تحته مباشرة"]
    key1 --> a1["مفتاح فرعي لكل تطبيق"]
    a1 -.-> a2["في الميدان هذا أسهل"]

الشكل 4: حتى في المفتاح نفسه، الميل إلى مفتاح فرعي باسم التطبيق يضيّق نطاق الأثر.

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

القيم التي تُنظر أولاً ثلاث.

4.2 مثال ضبط لكل تطبيق

مثلاً إن أردت إبقاء فل dump حتى 10 لـ 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

نقاط هذا المثال أربع.

• مقصور على MyApp.exe لا عام
• موضع الإخراج مفصول في مجلد مخصّص
• أولاً فل dump
• عدد الاحتفاظ محدود بـ 10

4.3 تحقّق من الأخذ

بعد وضع الإعداد، أأمن أن تُكمل أخذاً واحداً حتماً في بيئة تحقق قبل انتظار وقوع طبيعي في الإنتاج.

ما تريد التحقّق منه أربع نقاط.

1. هل يخرج .dmp في المجلد المتوقّع
2. هل الحجم يوافق افتراض التشغيل
3. هل يُفتح في WinDbg
4. هل يظهر crash في سجل Application لعارض الأحداث

flowchart TB
    accTitle: مسار التحقق بعد الضبط
    accDescr: مخطّط يبيّن أنه بعد وضع الإعداد تُكمل أخذاً واحداً حتماً في بيئة تحقق قبل انتظار وقوع طبيعي في الإنتاج، فتتحقّق من خروج dump في المجلد، وموافقة الحجم، وإمكان الفتح في WinDbg، وظهور crash في عارض الأحداث.
    v1["ضع الإعداد"] --> v2["أسقط عمداً في بيئة التحقق"]
    v2 --> v3["تحقّق من وجود الـ dump وحجمه"]
    v3 --> v4["تحقّق من الفتح في WinDbg"]
    v4 --> v5["تحقّق من سجل عارض الأحداث"]

الشكل 5: قبل انتظار وقوع طبيعي في الإنتاج، أكمل أخذاً واحداً في بيئة تحقق.

4.4 كود أدنى للإسقاط عمداً

حتى مع «أكمل أخذاً»، انتظار انهيار حقيقي لا يصير تحققاً. أسرع أن تجهّز للتحقق EXE صغيراً يسقط عمداً فقط.

في .NET يكفي تطبيق وحدة تحكّم يلقي استثناء غير معالج فقط. الاستثناء غير المعالج المُدار في .NET يُنهي العملية، فيصير هدفاً لـ WER كما هو.

// CrashTest.csproj: <TargetFramework>net8.0</TargetFramework>
using System;
using System.Threading;

internal static class Program
{
    private static void Main()
    {
        Console.WriteLine($"PID={Environment.ProcessId} / سأسقط العملية بعد 3 ثوانٍ.");
        Thread.Sleep(3000);

        throw new InvalidOperationException("intentional crash for dump collection test");
    }
}

إن أردت تحققاً من الجانب الأصلي، أقرب إحداث انتهاك وصول (0xC0000005). أضف volatile حتى لا يمحوه التحسين.

// crash_test.cpp / C++17 / MSVC
int main()
{
    volatile int* p = nullptr;
    *p = 1;  // ここで STATUS_ACCESS_VIOLATION が発生します
    return 0;
}

هنا نقطة واحدة يسهل إسقاطها. اسم المفتاح الفرعي لـ LocalDumps يجب أن يطابق اسم ملف EXE الذي تسقطه الآن. إن صنعت مفتاح MyApp.exe فقط وأسقطت CrashTest.exe، لن يخرج dump طبعاً. عند التحقق، إمّا اصنع مفتاح CrashTest.exe مؤقّتاً، أو جرّب من جانب الإعداد العام.

flowchart TB
    accTitle: فخ تطابق اسم المفتاح الفرعي
    accDescr: مخطّط يبيّن أن اسم المفتاح الفرعي لـ LocalDumps إن لم يطابق اسم ملف EXE الذي تسقطه الآن لم يخرج dump، لذلك عند التحقق اصنع مفتاح CrashTest.exe مؤقّتاً أو جرّب من جانب الإعداد العام.
    t1["تصنع مفتاح MyApp.exe فقط"] --> t2["تسقط CrashTest.exe"]
    t2 --> t3["لا يخرج dump"]
    t3 -.-> t4["واءم اسم المفتاح مع اسم EXE المسقط"]

الشكل 6: انحراف اسم المفتاح الفرعي عن اسم EXE فخ شائع يجعل التحقق فارغاً.

NotMyFault من Sysinternals يُذكر كثيراً أيضاً أداة «إسقاط عمداً»، لكنها لإسقاط نظام Windows نفسه crash / hang وصنع dump شاشة زرقاء، وتحتاج امتياز مدير أيضاً. لتحقّق LocalDumps لتطبيق وضع مستخدم، EXE صغير ذاتي كالذي أعلاه أأمن وأوثق.

5. مشاهد استخدام ProcDump

كثيراً ما يكفي WER، لكن هناك مشاهد يكون فيها ProcDump مريحاً.

• تريد تجنّب تثبيتاً دائماً في السجل
• تريد مراقبة عملية قيد التشغيل أصلاً فقط
• تريد المراقبة من الإقلاع التالي فقط
• تريد رؤية first chance exception
• تريد أخذ hang
• تريد الأخذ بعدّاد أداء أو بشرط

5.1 خيارات تُستخدم كثيراً

إن حصرت ما يُحفظ في مرحلة المدخل، يكفي حفظ التالي لـ ProcDump للقتال كثيراً.

5.2 أمثلة أوامر نموذجية

فل dump عند استثناء غير معالج لعملية قيد التشغيل أصلاً

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

انتظر الإقلاع التالي، ثم فل dump عند استثناء غير معالج

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

شغّل بنفسك وراقب كما هو

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

تريد first chance exception أيضاً

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

تريد أخذ hang

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

5.3 سبب عدم جعل -i الخطوة الأولى

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

لذلك أسهل البدء من ضبط WER لكل تطبيق أو -w / -x / تعيين PID لـ ProcDump.

flowchart TB
    accTitle: سبب عدم جعل -i الخطوة الأولى
    accDescr: مخطّط يبيّن أن -i لـ ProcDump استخدام قوي يسجّل كمنقّح بعد الوفاة لكنه يدخل في سلوك الانهيار للجهاز كلّه، لذلك في مرحلة المدخل أسهل البدء من ضبط WER لكل تطبيق أو -w أو -x أو تعيين PID لـ ProcDump.
    i1["تسجيل بـ -i لـ ProcDump"] --> i2["يدخل في سلوك الجهاز كلّه"]
    i2 -.-> i3["يثقل كخطوة أولى للمدخل"]
    i4["أولاً ضبط لكل تطبيق"] --> i5["ضبط WER لكل تطبيق"]
    i4 --> i6["-w أو -x أو تعيين PID لـ ProcDump"]

الشكل 7: ابدأ بمدخل ينحصر نطاق أثره في التطبيق.

6. النظرة عند استخدام MiniDumpWriteDump في جمع ذاتي

الجمع الذاتي يناسب مشاهد مثل هذه.

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

الواجهة المحورية هنا MiniDumpWriteDump.

غير أن هنا طبعاً قليلاً. ما لا تريد إسقاطه خصوصاً في المدخل نقطتان.

1. إن أمكن، استدع من عملية غير هدف الـ dump
2. عامل عائلة DbgHelp بافتراض خيط واحد

flowchart TB
    accTitle: نقطتان لا تسقطهما في الجمع الذاتي
    accDescr: مخطّط يبيّن أنه في الجمع الذاتي بـ MiniDumpWriteDump لا تسقط نقطتين: الاستدعاء من عملية غير هدف الـ dump إن أمكن، ومعاملة عائلة DbgHelp بافتراض خيط واحد.
    md1["جمع ذاتي بـ MiniDumpWriteDump"] --> md2["استدع من عملية أخرى"]
    md1 --> md3["DbgHelp بافتراض خيط واحد"]
    md2 -.-> md4["تنفيذ فجّ ينكسر بالعكس"]
    md3 -.-> md4

الشكل 8: طبع الجمع الذاتي يتركّز في موضعين: أين تستدعي، والخيط.

7. اختيار الميني dump / الفل dump / الحجم الوسط

هنا يحتار كثيرون. نضع الاختيار العملي في جدول.

توصية المبتدئ بسيطة جدّاً.

• على جهاز التطوير / التحقق فل dump
• في بيئة العميل اختر الميني أو الفل بحسب شروط التشغيل
• إن اشتُبه بتلف ذاكرة أو DLL أصلي أو COM أو P/Invoke أو خلل حالة بعد تشغيل طويل فمل إلى الفل

flowchart TB
    accTitle: الاختيار الأوّل لنوع الـ dump
    accDescr: مخطّط يبيّن اختياراً يجعل الفل dump على جهاز التطوير والتحقق، ويختار الميني أو الفل في بيئة العميل بحسب شروط التشغيل، ويميل إلى الفل إن اشتُبه بتلف أو حدود أصليّة أو خلل حالة بعد تشغيل طويل.
    e1{"في أي بيئة تأخذ"}
    e1 -->|"جهاز تطوير / تحقق"| f1["فل dump"]
    e1 -->|"بيئة عميل"| f2["ميني أو فل بحسب شروط التشغيل"]
    f2 -.->|"رائحة تلف أو حدود أصليّة"| f1

الشكل 9: إن حرت فاحسم بالبيئة، وكلّما كثف الاشتباه مل إلى الفل.

7.1 MiniPlus / المخصّص: كيف يُعيَّن فعلاً

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

في WER LocalDumps اجعل DumpType هو 0 (مخصّص) ثم ضع توليفة بتّات MINIDUMP_TYPE في CustomDumpFlags. CustomDumpFlags قيمة تُستخدم فقط عندما DumpType=0، والافتراضي 0x00000121 (توليفة MiniDumpWithDataSegs و MiniDumpWithUnloadedModules و MiniDumpWithProcessThreadData).

reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v DumpType /t REG_DWORD /d 0 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\MyApp.exe" /v CustomDumpFlags /t REG_DWORD /d 0x121 /f

في ProcDump -mp هو MiniPlus، و -mc <Mask> هو المخصّص.

procdump -accepteula -mp -e MyApp.exe C:\CrashDumps\MyApp

MiniPlus، رغم الاسم، محتواه أميل إلى الفل كثيراً. بحسب الوثائق يضمّ كل الذاكرة الخاصة، وكل ذاكرة image / mapped للقراءة/الكتابة، ثم يستثني أكبر منطقة خاصة تتجاوز 512MB فقط لكبح الحجم. النتيجة موضع «بتفصيل يقارب الفل dump، والحجم 10٪ إلى 75٪ من الفل».

غير أن نقطتي انتباه.

• عملية CLR، لقيود التصحيح، تُؤخذ فل (-ma) حتى مع تعيين -mp. الرهان على خفض حجم MiniPlus في تطبيق .NET يخيب غالباً
• إن كان دافع كبس الحجم «تقليل اختلاط معلومات سرّية»، فأطبعي التفكير من جانب الميني dump لا MiniPlus

flowchart TB
    accTitle: موضع MiniPlus وقيوده
    accDescr: مخطّط يبيّن أن MiniPlus يضمّ كل الذاكرة الخاصة تقريباً وذاكرة image أو mapped للقراءة/الكتابة، ويستثني أكبر منطقة خاصة تتجاوز 512MB فقط فينحصر في عشر إلى سبعة أعشار الفل تقريباً، لكن عملية CLR تُؤخذ فل حتى مع تعيين -mp.
    mp1["أخذ بـ MiniPlus"] --> mp2["الذاكرة الخاصة تُضمَّ كلها تقريباً"]
    mp2 --> mp3["تُستثنى المنطقة الخاصة الضخمة فقط"]
    mp3 --> mp4["أصغر من الفل وأفصل"]
    mp1 -.->|"عملية CLR"| mp5["تُؤخذ فل"]

الشكل 10: MiniPlus محتواه أميل إلى الفل، وفي تطبيق .NET لا ينفع خفض الحجم.

8. ما يُقرَّر مسبقاً في التشغيل

جمع الـ dump كثيراً ما يسقط في التشغيل لا في التنفيذ. نذكر ما يُراد تقريره مسبقاً.

8.1 كيف تُبقي PDB والثنائي

هذا الأهم.

• الإصدار الدقيق لـ EXE / DLL الموزَّع
• PDB الموافق لذلك الإصدار
• من أي commit / أي مسار بناء صُنع
• معلومات إصدار المثبّت أو الموزَّع

8.2 إلى أين تُخرج، وكم تُبقي

الفل dump يصير كبيراً جدّاً. أأمن تقرير سياسة الإخراج والاحتفاظ من البداية.

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

8.3 من يجوز أن يرى

قد يختلط في الفل dump معلومات سرّية أو شخصية.

• إعداد نص واضح
• سلسلة اتّصال
• رموز أو بيانات اعتماد
• بيانات عمل عولجت للتو
• مسارات ملفات أو أسماء مستخدمين

لذلك يلزم تقرير «من يجوز أن يلمس» مع تصميم «الأخذ».

flowchart TB
    accTitle: ثلاث نقاط تُقرَّر مسبقاً في التشغيل
    accDescr: مخطّط يبيّن أن جمع dump الانهيار يسقط في التشغيل أكثر من التنفيذ، لذلك قرّر مسبقاً حفظ PDB والثنائي، وموضع الإخراج وعدد الاحتفاظ، وسياسة الوصول من يجوز أن يرى.
    op1["حفظ PDB والثنائي"] --> op4["قرّر مسبقاً"]
    op2["موضع الإخراج وعدد الاحتفاظ"] --> op4
    op3["من يجوز أن يرى"] --> op4
    op4 -.-> op5["يسقط في التشغيل أكثر من التنفيذ"]

الشكل 11: فشل جمع الـ dump يأتي غالباً من نقص قرارات التشغيل.

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

بعد أخذ الـ dump، ما يُفعل أولاً أبسط ممّا يُظن.

9.1 ثبّت WinDbg

WinDbg الحالي سهل التثبيت من Microsoft Store أو winget.

winget install Microsoft.WinDbg

9.2 افتح الـ dump

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

اسم الملف هنا الاسم الافتراضي الذي يضعه ProcDump. الاسم الافتراضي لـ ProcDump هو PROCESSNAME_YYMMDD_HHMMSS.dmp، ويمكن استخدام PROCESSNAME / PID / EXCEPTIONCODE / YYMMDD / HHMMSS كبادلات.

بالمقابل، WER LocalDumps يصنع الملف بتسمية مختلفة عن ProcDump. قاعدة التسمية غير منصوص عليها صراحة في Microsoft Learn، لذلك أوثق من تخمين الاسم النظر إلى مجلد الإخراج مرتّباً بتاريخ التحديث.

dir /o-d "C:\CrashDumps\MyApp\*.dmp"

إن لم تضبط DumpFolder، موضع الإخراج الافتراضي %LOCALAPPDATA%\CrashDumps. غير أن انهيار خدمة يخرج إلى مجلد ملف تعريف حساب التشغيل. خدمة System فـ %WINDIR%\System32\Config\SystemProfile، وNetwork Service / Local Service فتحت %WINDIR%\ServiceProfiles. إن ظننت «لم يخرج dump»، ابدأ بالشك هنا.

flowchart TB
    accTitle: أين تبحث عندما لا تجد الـ dump
    accDescr: مخطّط يبيّن أن الافتراضي إن لم يُضبط DumpFolder هو CrashDumps تحت LOCALAPPDATA، وأن انهيار خدمة يخرج إلى مجلد ملف تعريف حساب التشغيل، لذلك إن ظننت أنه لم يخرج فشكّ هناك.
    fq1["لا تجد الـ dump"] --> fq2{"بأي شكل كان يعمل"}
    fq2 -->|"تطبيق عادي"| fp1["CrashDumps تحت LOCALAPPDATA"]
    fq2 -->|"خدمة"| fp2["تحت ملف تعريف حساب التشغيل"]
    fp2 -.-> fp3["SystemProfile أو ServiceProfiles"]

الشكل 12: موضع الإخراج الافتراضي يختلف حسب الحساب، فابدأ بالشك من موضع البحث.

9.3 اضبط الرموز

اجعل رموز Microsoft العامة قابلة للاستخدام أولاً، ثم أضف موضع PDB الخاص بك.

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

9.4 انظر التحليل التلقائي أولاً

!analyze -v

ثم انظر بالترتيب.

• أي رمز استثناء
• ما هي faulting module
• إلى أين يظهر كودك في المكدّس
• هل في خيوط غير خيط الاستثناء انتظار أو احتباس مشبوه

flowchart TB
    accTitle: أقصر مسار تحليل بعد الأخذ
    accDescr: مخطّط يبيّن تثبيتاً لـ WinDbg، وفتح الـ dump، وضبط رموز Microsoft العامة وPDB الخاص، ثم النظر أولاً إلى التحليل التلقائي analyze -v، ثم قراءة رمز الاستثناء والمكدّس بالترتيب.
    an1["ثبّت WinDbg"] --> an2["افتح الـ dump"]
    an2 --> an3["اضبط الرموز وPDB"]
    an3 --> an4["انظر التحليل التلقائي أولاً"]
    an4 --> an5["اقرأ رمز الاستثناء والمكدّس بالترتيب"]

الشكل 13: الأقصر الفتح، ثم تمرير الرموز، ثم البدء من التحليل التلقائي.

10. مواضع احتباس شائعة

10.1 أُخذ الـ dump لكن لا PDB

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

10.2 لم تنظر إلى ACL لـ DumpFolder

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

ACL الحالية تُرى بـ icacls.

icacls C:\CrashDumps\MyApp

إن نقص حق الكتابة، أضف M (تعديل) لحساب التشغيل. مجلد الـ dump يحتاج الصلاحية نفسها للملفات تحته، فألحق (OI) و (CI) للتوريث.

rem 例: Network Service で動くサービスの場合
icacls C:\CrashDumps\MyApp /grant "NT AUTHORITY\NETWORK SERVICE:(OI)(CI)M"

(OI) يورّث ACE للملفات تحته، و (CI) للمجلدات تحته. نطاق التوريث يصير كما هو «من يستطيع قراءة الـ dump»، فتحقّق قبل الإضافة أنه لا يخالف السياسة المقرّرة في 8.3.

flowchart TB
    accTitle: مسار فحص ACL لـ DumpFolder
    accDescr: مخطّط يبيّن أنه في خدمة أو عملية مفصولة الصلاحيات يسهل الفراغ عند الكتابة، لذلك افحص ACL الحالية بـ icacls، وإن نقصت امنح حساب التشغيل حق تعديل مع توريث، وقابل نطاق التوريث بسياسة الاطّلاع.
    ac1["انظر ACL الحالية بـ icacls"] --> ac2{"هل حساب التشغيل يكتب"}
    ac2 -->|"لا يكتب"| ac3["امنح حق تعديل مع توريث"]
    ac2 -->|"يكتب"| ac4["شغّل كما هو"]
    ac3 -.-> ac5["قابل نطاق التوريث بسياسة الاطّلاع"]

الشكل 14: فحص إمكان الكتابة وفحص من يستطيع القراءة يُنجزان في الموضع نفسه.

10.3 إخراج فل dump باستمرار إلى محرّك نظام جهاز الإنتاج

هذا حادث سعة شائع. حدّ عدد الاحتفاظ وفصل موضع الإخراج يُدخلان من البداية.

10.4 محاولة رؤية hang كلّه بـ WER وحده

WER LocalDumps قوي أولاً في الانهيار. hang وfirst chance exception في مواضع يناسبها ProcDump أكثر.

10.5 إدخال -e 1 دائماً فيصير عاصفة استثناءات

first chance exception مريح، لكنه كثير عادة. الواقعي وضع حدّ للعدد، أو إدخاله وقتاً قصيراً فقط، أو حصر الهدف.

11. الخلاصة

dump الانهيار نقطة رصد قويّة جدّاً لعطل منخفض الإعادة. خصوصاً إن تداخل في تطبيق Windows أمر COM أو P/Invoke أو DLL أصلي أو تشغيل طويل، يستحق تقرير «ما الذي يبقى إن سقط» من البداية.

الترتيب الموصى به بسيط.

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

بهذا الترتيب يصعب الانحراف كثيراً.

روابط مرجعية

• Microsoft Learn, Collecting User-Mode Dumps
• Microsoft Learn, ProcDump v11.1 - Sysinternals
• Microsoft Learn, MiniDumpWriteDump function (minidumpapiset.h)
• Microsoft Learn, User-mode dump files
• Microsoft Learn, Analyze a user-mode dump file
• Microsoft Learn, Install the Windows debugger
• Microsoft Learn, Symbol path for Windows debuggers
• Microsoft Learn, !analyze (WinDbg)
• Microsoft Learn, Troubleshoot processes by using Task Manager
• Microsoft Learn, Enabling Postmortem Debugging
• Microsoft Learn, MINIDUMP_TYPE enumeration (minidumpapiset.h)
• Microsoft Learn, icacls
• Microsoft Learn, NotMyFault - Sysinternals

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

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

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

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

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما dump الانهيار، وما الذي يتّضح منه؟

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

أين يُضبط LocalDumps لـ WER؟

تحت مفتاح السجل HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps. في الميدان أسهل الميل إلى مفتاح فرعي لكل تطبيق مثل MyApp.exe لا إلى إعداد عام. القيم التي تُنظر أولاً ثلاث: DumpFolder لموضع الإخراج، وDumpCount لعدد الاحتفاظ، وDumpType للنوع. تُبقي dump بعد الانهيار محلياً بلا توزيع أدوات إضافية.

أيهما يُختار، الميني dump أم الفل dump؟

على جهاز التطوير والتحقق الفل dump (DumpType=2)، وفي بيئة العميل يُختار الميني (DumpType=1) أو الفل بحسب السعة ومتطلبات السرّية. إن اشتُبه بتلف ذاكرة أو DLL أصلي أو COM أو P/Invoke أو خلل حالة بعد تشغيل طويل فالميل إلى الفل أوفر. غير أن الفل dump كبير، وفيه خطر اختلاط معلومات سرّية مثل سلسلة اتّصال أو رمز، لذلك يلزم تقرير موضع الحفظ وعدد الاحتفاظ وصلاحية الوصول مسبقاً.

متى يُستخدم ProcDump؟

WER LocalDumps موجّه أساساً إلى الانهيار، لذلك يناسب ProcDump عندما تريد hang أو first chance exception أيضاً، أو تجنّب تثبيتاً دائماً في السجل، أو مراقبة عملية قيد التشغيل أصلاً فقط. الخيارات النموذجية: -ma للفل dump، و-e للأخذ عند استثناء غير معالج، و-h لكشف التعليق، و-w لانتظار الإقلاع. -e 1 لاستهداف first chance exception يكثر عدده بسهولة، لذلك الواقعي تقييد المدة والنطاق مع حدّ بـ -n.

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

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

غو كومورا

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

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