دليل عملي لـ Process Monitor (ProcMon) ── تحديد «الإعدادات لا تُقرأ» وACCESS DENIED خلال 10 دقائق

«عدّلت ملف الإعدادات لكن سلوك التطبيق لم يتغيّر»، «يعمل على جهاز التطوير لكنه يتعطل مباشرة بعد الإقلاع على جهاز العميل فقط»، «كان يعمل حتى الأمس، ولم أغيّر شيئاً في البرنامج» — تصل معظم طلبات تحقيق الأعطال بهذا الشكل. وفي كثير من هذه الحالات لا تصل إلى السبب مهما دقّقت في قراءة الكود المصدري، لأن أي ملفات يقرأها التطبيق فعلياً، وأي مفاتيح Registry ينظر إليها، وما الذي فشل فيه تحدده بيئة التشغيل، لا الكود.

الأداة التي تسجّل «ما حدث فعلياً» هي Process Monitor (ProcMon)، إحدى أدوات Sysinternals التي تقدّمها Microsoft مجاناً. إنها بمثابة مسجّل سلوك Windows الذي يسجّل لحظياً كل نشاط نظام الملفات وRegistry والعمليات (processes) والخيوط (threads)، وهي من أكثر الأدوات استخداماً في تحقيقات الأعطال لدينا إلى جانب WinDbg.¹

ورغم قوتها، فإنها إن شُغّلت دون إعداد تتدفق آلاف إلى عشرات الآلاف من الأحداث في الثانية، وينتهي الأمر غالباً عند أول محاولة بشعور «الكثرة تمنع القراءة». تلخّص هذه المقالة أقصر طريق لاستخدام ProcMon عملياً — طريقة وضع الفلاتر، وقراءة عمود Result، والأنماط الشائعة حسب الأعراض، ونقاط الحذر في بيئة الإنتاج، والتمييز بينها وبين أدوات التحقيق الأخرى — من منظور ميداني لتحقيق الأعطال.

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

• السؤال الذي تجيب عنه ProcMon هو: «متى قامت هذه العملية، وبأي مسار، وبماذا فعلت، وما كانت النتيجة». يمكن خلال دقائق معرفة من أين يُقرَأ ملف الإعدادات، وبأي ترتيب يُبحَث عن DLL، وأي عملية انتهت بـ ACCESS DENIED.
• القاعدة المتّبعة هي «أولاً Include على Process Name للعملية المستهدفة، ثم التضييق عبر Result إلى الحالات الشاذة». ليست أداة تُقرأ فيها الأحداث الخام من الأعلى إلى الأسفل.
• يحتوي عمود Result على قيم كثيرة تبدو شاذة لكنها طبيعية. BUFFER OVERFLOW تبادل طبيعي لـ API، وNAME NOT FOUND غالباً مرحلة وسطى في ترتيب البحث (الفصل 4).
• الفلتر تضييق للعرض، بينما يستمر تسجيل جميع الأحداث في الخلفية. عند حفظ السجل لتسليمه لشخص آخر احفظ جميع الأحداث. في المقابل، عند الالتقاط لفترة طويلة استخدم Drop Filtered Events لحماية الذاكرة (الفصل 5).
• ProcMon ليست أداة شاملة. معرفة «أي عملية تحتجز هذا الملف الآن» من اختصاص Process Explorer، وحالة لحظة الانهيار من اختصاص ملف تفريغ الأعطال (crash dump)، ومكان استهلاك CPU من اختصاص PerfView (الفصل 7).

فيما يلي جدول مرجعي سريع لاختيار الأداة حسب العرض.

«10 دقائق» في العنوان تفترض توزيع الوقت التالي. المدة تختلف بحسب العرض والبيئة، لكن تحديد الإجراء ومدة الحيازة مسبقاً هو أفضل وقاية من إضاعة بعد الظهر في بحر الأحداث.

في الدقائق الخمس الأولى انظر إلى ثلاثة مواضع فقط. (1) ACCESS DENIED للعملية المستهدفة، (2) سلسلة NAME NOT FOUND لاسم ملف إعدادات أو DLL، (3) SUCCESS في مكان غير متوقع. إن لم يظهر شيء من الثلاثة، فسبب العرض خارج نطاق ProcMon (الملفات وRegistry والعمليات) باحتمال مرتفع؛ لا تُلح، وعد إلى الجدول أعلاه وبدّل الأداة.

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

2. ما هي ProcMon ── التثبيت ينتهي في دقيقة

Process Monitor واحدة من أدوات Sysinternals، وهي أداة مراقبة تعرض لحظياً نشاط نظام الملفات وRegistry والعمليات/الخيوط. إنها الخلف الذي دمج وعزّز أداتين سابقتين هما Filemon وRegmon، وتتضمّن معلومات تفصيلية لكل حدث، وفلترة غير مدمِّرة، وتسجيل مكدّس الخيوط، وتسجيل زمن الإقلاع.¹

التثبيت بسيط. لا يوجد مثبّت؛ نزّل ZIP من صفحة التنزيل وفكّ ضغطه، ثم شغّل Procmon.exe. وفي التحقيقات العاجلة يمكن أيضاً التشغيل مباشرة عبر خدمة Sysinternals Live من https://live.sysinternals.com/procmon.exe.² عند أول تشغيل تُطلب الموافقة على اتفاقية الترخيص، ولأنها تحمّل برنامج تشغيل على مستوى النواة فإنها تتطلّب صلاحيات المسؤول (رفع UAC). أما السبب العام وراء الحاجة إلى صلاحيات المسؤول فقد شرحناه في «متى تحتاج إلى صلاحيات المسؤول في Windows»، وأي أداة تراقب أحداث النظام بأكمله تقع نموذجياً ضمن فئة «تتطلّب رفع الصلاحيات».

يبدأ الالتقاط فور التشغيل، وتبدأ الأحداث بالتدفّق على الشاشة. يكفي حفظ ثلاث عمليات رئيسية.

يتكوّن سطر الحدث الواحد من: Time (الوقت)، Process Name (اسم العملية)، PID، Operation (العملية)، Path (المسار المستهدف)، Result (النتيجة)، وDetail (التفاصيل). أما Operation فبدقة تقابل تقريباً واجهات Win32 مثل CreateFile (فتح/إنشاء ملف) وReadFile/WriteFile وRegOpenKey/RegQueryValue. بمعنى آخر، سجل ProcMon هو «تسجيل للحوار بين التطبيق ونظام التشغيل»، ويكشف بوضوح الفارق بين «ما كان يُفترض» أن يقرأه التطبيق من ملف الإعدادات وبين «ما قرأه فعلياً».

3. الفلتر ── ProcMon أداة تُضيَّق أولاً ثم تُقرأ

عند الالتقاط دون إعداد، يتدفّق آلاف الأحداث في الثانية حتى في حالة خمول Windows. يمكن القول إن جدوى ProcMon تتحدّد بطريقة استخدام الفلتر، والقاعدة المتّبعة مرحلتان.

تُفتَح نافذة الفلتر من Filter > Filter… (Ctrl+L). في أعلى النافذة صف أفقي لحقول الشرط، من اليسار: «العمود (Process Name، Path، Result وغيرها)»، «العلاقة (is / is not / contains / begins with / ends with وغيرها)»، «القيمة (تدخلها أنت)»، «Include / Exclude». بعد اختيار هذه الأربعة اضغط زر Add حتى تُضاف الشرط إلى القائمة أسفل. إدخال الشرط دون Add ثم الضغط على OK والاحتار من أن «الفلتر لا يعمل» خطأ تشغيلي يمرّ به الجميع مرة. الشروط المضافة يمكن تعطيلها مؤقتاً بمربع الاختيار على يسار القائمة، وحذفها بـ Remove. فيما يلي نكتب الشروط بالترتيب عمود / علاقة / قيمة / Include أو Exclude.

المرحلة الأولى: التضييق حسب العملية. في نافذة الفلتر أضف Process Name / is / myapp.exe / Include. يمكن أيضاً سحب أيقونة الهدف من شريط الأدوات إلى نافذة التطبيق المستهدف لتضييق الفلتر على تلك العملية فقط.

المرحلة الثانية: التضييق حسب النتيجة أو العملية. إذا أردت البحث عن العمليات الفاشلة، أضف Result / is not / SUCCESS / Include (لعرض الحالات الشاذة فقط). إذا أردت رؤية عمليات الكتابة فقط، أضف Category / is / Write / Include. أما إذا أردت معرفة من يلمس ملف الإعدادات هذا دون تضييق حسب العملية، فأضف Path / contains / app.config / Include، وهكذا.

كما يُستخدم على نطاق واسع في الميدان التضييق التفاعلي عبر النقر بزر الفأرة الأيمن على سطر الحدث. بمجرد العثور على سطر قريب من الهدف، يكفي النقر بزر الفأرة الأيمن واختيار «Include ‘هذا المسار’» أو «Exclude ‘هذه العملية’»، فتتراكم الفلاتر دون فتح النافذة. الأسلوب الأساسي هو إزالة مصادر التشويش (برامج مكافحة الفيروسات، أدوات الفهرسة وغيرها) عبر Exclude، والإبقاء فقط على ما يحيط بالعملية المستهدفة. يمكن أيضاً استخدام التمييز اللوني (Ctrl+H) كمساعد بصري؛ إذ يمكن تلوين الأسطر بنفس تعبير الفلتر، فإذا أردت «رؤية التدفّق الكامل مع إبراز الحالات الشاذة فقط» فاستخدم التمييز اللوني بدل الفلتر.

هناك ثلاث خصائص قد توقعك في مأزق إن لم تكن على علم بها:

• الفلتر تضييق للعرض وليس تضييقاً للتسجيل. يستمر تسجيل جميع الأحداث في الخلفية (افتراضياً)، ويمكن العودة إلى العرض الكامل في أي وقت بإزالة الفلتر. هذا سبب تسميتها فلترة غير مدمِّرة، وهو تصميم يقلّل احتمال «التضييق المفرط الذي يفوّت الأدلة».¹
• يُحمَل إعداد الفلتر إلى الجلسة التالية. الوقوع في حيرة «لا يظهر شيء» بسبب بقاء فلتر التحقيق السابق أمر يمرّ به الجميع مرة. إذا شعرت أن العرض غير طبيعي، فابدأ بالشك في Reset Filter (Ctrl+R) من قائمة Filter.
• هناك عدد من عناصر Exclude مفعّلة افتراضياً. تُستبعَد ProcMon نفسها وعمليات الإدخال/الإخراج الخاصة بالـ paging منذ البداية. في التحقيقات التي تتطلّب «رؤية النظام بأكمله دون استثناء»، انتبه لوجود هذا الفلتر الافتراضي.

4. كيفية قراءة عمود Result ── ما يبدو شاذاً لكنه طبيعي

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

والسجل الفعلي لا يُقرأ سطراً سطراً بمعزل، بل كسلسلة. نوضّح قراءة الأسطر بمثال «عند الإقلاع لا يُعثر على mylib.dll». الجدول التالي نموذج توضيحي يقتصر على الأعمدة الثلاثة Operation / Path / Result؛ في الشاشة الفعلية تظهر عن يمينها ويسارها Time وProcess Name وPID وDetail (وفي عمود Detail لـ CreateFile تدخل معاملات مثل Desired Access: وShareMode: الممرَّرة إلى ذلك الاستدعاء).

أكثر قراءة خاطئة شيوعاً هي النظر إلى الأسطر 1–3 وحدها واستنتاج أن «غياب DLL هو السبب». ما ينبغي النظر إليه نقطتان: هل يوجد SUCCESS في النهاية، وإن وُجد فهل المسار هو المكان المقصود. استنتاج هذا المثال: «DLL موجود. لكنه ليس نسخة C:\Program Files\MyApp التي يُفترض أنها وُزِّعت، بل نسخة قديمة في C:\Tools بقيت على جهاز التطوير». إذا لم يوجد السطر 4 (انتهت السلسلة بـ NAME NOT FOUND ثم أُنهيت العملية) فهذه حالة عدم العثور الحقيقية. احفظ أنك تنظر إلى نهاية السلسلة لا إلى عدد NAME NOT FOUND.

من بين هذه القيم الثلاث الأهم في التحقيق هي NAME NOT FOUND وACCESS DENIED وSHARING VIOLATION. ولكل منها نمط تحقيق شائع، نستعرضه من جانب الأعراض في الفصل التالي.

وفي المقابل، من الأنماط التي يسهل إغفالها نمط «SUCCESS هو السبب». على سبيل المثال، حدث أكثر من مرة أن يكون سبب «ملف الإعدادات الذي عدّلته لا ينعكس» هو SUCCESS في قراءة ملف إعدادات قديم في مكان آخر. فإذا اقتصرت النظرة على الحالات الشاذة فقط، ستفوّت «الإجابة الخاطئة» التي قُرئت بنجاح طبيعي؛ لذا فإن الطريقة المضمونة هي التضييق حسب المسار ورؤية جميع عمليات الوصول لذلك النوع من الملفات بما فيها حالات النجاح.

5. أنماط التحقيق الشائعة حسب العرض

5.1 «عدّلت الإعدادات لكنها لا تنعكس» ── تحديد المكان الذي يُقرأ منه

عند وضع Include على Path / contains / اسم ملف الإعدادات وتشغيل التطبيق، ستحصل على قائمة تُظهر من أي مجلد وبأي ترتيب بحث التطبيق عن ملف بهذا الاسم. الحقيقة الشائعة غالباً واحدة مما يلي:

• كان يقرأ نسخة تحت %APPDATA% أو ProgramData وليس في نفس مجلد ملف الـ exe (تصميم ينسخ عند التشغيل الأول)
• تعرّض الوصول إلى Registry أو مجلدات النظام من عملية 32-bit لإعادة توجيه WOW64، فاختلف المكان الفعلي عن المكان المفترض
• وُوجِهت الكتابة في مجلد Program Files الخاص بمكان التثبيت بآلية الافتراضية (VirtualStore)، فتحوّلت عمليات القراءة والكتابة إلى مكان آخر

كل هذه الحالات تظهر بوضوح لأن المسار الكامل يظهر في عمود Path. أما الجانب المقابل — كيف ينبغي تصميم مكان حفظ ملف الإعدادات — فقد كتبناه في «ليس appsettings.json فقط ── الممارسة العملية لإدارة التهيئة في تطبيقات أعمال Windows».

بعد معرفة مصدر القراءة لا تتوقف؛ أدرج الخطوات الثلاث التالية في التحقيق نفسه. إسقاطها يعيد دورة «ظننت أنني أصلحت».

1. طابق جانب القراءة مع جانب الكتابة. التقط عملية الحفظ من شاشة الإعدادات بنفس الفلتر، وانظر إلى أي مسار تذهب WriteFile أو RegSetValue. إذا اختلف مصدر القراءة عن وجهة الكتابة فذلك هو جوهر العرض. وإذا وُجد البند نفسه في Registry وفي ملف إعدادات، يظهر من ترتيب السجل أيهما يُقرأ أولاً.
2. قرّر أي الجانبين هو «الصحيح». هذا حكم تصميم لا تحقيق. في الممارسة من الآمن الفصل حسب صلاحية الكتابة: البنود التي يغيّرها المستخدم من الشاشة تحت ملف تعريف المستخدم (قابل للكتابة)، والبنود الثابتة حسب البيئة في مكان التوزيع (للقراءة فقط). إذا كانت الكتابة إلى Program Files تتحوّل إلى VirtualStore، فهذه إشارة إلى إعادة النظر في المكان نفسه.
3. التقط مرة أخرى بعد التصحيح. تأكيد «أُصلح» يكون بالسجل لا بمظهر التطبيق. انظر أن الوصول إلى المسار المقصود صار SUCCESS، وأن القراءة من المكان القديم اختفت. النسخ المتبقية تحت VirtualStore أو ملف التعريف تواصل القراءة حتى بعد تصحيح الملف الأصلي، لذا لا تحكم قبل حذف الملف القديم ثم إعادة التحقق.

5.2 «لا يعمل إلا في هذه البيئة» ── تتبّع بحث DLL

عندما ينهار التطبيق فور الإقلاع أو تظهر أخطاء من نوع «لم يُعثر على DLL»، ضع Include على العملية ثم أضف Path / ends with / .dll وراقب سلسلة NAME NOT FOUND. يتبع بحث DLL في Windows ترتيباً محدداً لتتبّع المجلدات، لذا يظهر في سجل ProcMon نمط «سلسلة من NAME NOT FOUND بترتيب البحث، وفي مكان ما ينتهي إلى SUCCESS (أو لا يُعثر عليه أبداً)». الـ DLL الذي لا ينتهي بـ SUCCESS في النهاية هو الجاني. وفي المقابل يمكن هنا أيضاً اكتشاف نمط «SUCCESS لكن يحتجز نسخة قديمة من DLL في مكان غير مقصود». راجع منطق ترتيب البحث في «آلية حل أسماء DLL في Windows».

تظهر مشكلة «الفئة غير مسجّلة» المتعلقة بـ COM/ActiveX بنمط مشابه، حيث تُلاحَظ كـ NAME NOT FOUND تحت مفتاح CLSID عبر RegOpenKey. أما حوادث الخلط بين 32-bit و64-bit التي تؤدي إلى النظر في عرض مختلف من Registry، فProcMon هو أقصر طريق كما في الإجراءات المكتوبة في «سبب عدم عمل ActiveX في Office 2024/Microsoft 365 وخطوات التحقق».

5.3 «تظهر ACCESS DENIED» ── الشك في هوية المستخدم الذي تعمل تحته العملية

عند العثور على ACCESS DENIED، انقر نقراً مزدوجاً على ذلك الحدث وتحقق من تبويب Process في خصائص الحدث. سيظهر لك بأي مستخدم كانت تلك العملية تعمل، فتتضح هنا حالات التناقض مثل «كانت الخدمة تعمل بحساب خدمة مقيّد وليس SYSTEM» أو «كان المستخدم مختلفاً فقط عند التشغيل عبر Task Scheduler». وإذا كان الهدف ملفاً، فمطابقة ذلك مع ACL الخاصة بذلك المسار تحدّد السبب بشكل قاطع. وفي الحالات التي يتدخّل فيها برنامج مكافحة الفيروسات، غالباً ما يظهر أن عملية أخرى (محرك برنامج المكافحة) تلمس نفس المسار قبل الحدث وبعده مباشرة، وهذا أيضاً دليل فريد تقدّمه ProcMon بفضل تسجيلها الزمني. بعد تصحيح ACL أو حساب الخدمة، التقط مرة أخرى بنفس الفلتر وتأكد أن العملية المعنية صارت SUCCESS. من الأنماط الشائعة أن يُزال ACCESS DENIED الأول ثم يتوقف المسار التالي؛ بدون تأكيد بالسجل يبدو الأمر «أصلحت لكن العرض لم يتغيّر».

5.4 «يفشل معالجة الملف أحياناً» ── البحث عن الجهة المسبِّبة لـ SHARING VIOLATION

انتهاك المشاركة تحقيق يعتمد كلياً على الترتيب الزمني. عند الالتقاط مع Include على المسار دون تضييق حسب العملية، ستظهر في الأسطر المحيطة بلحظة الفشل الجهة التي كانت تفتح نفس الملف. برامج النسخ الاحتياطي ومكافحة الفيروسات وعمليات Excel المتبقية من الأمثلة الشائعة. أما التصميم الذي يمنع أصل هذا التنافس في تكامل الملفات فقد لخصناه في «أساسيات التحكم الحصري في تكامل الملفات»، ومشكلة بقاء عملية Excel في «مشكلة بقاء EXCEL.EXE عند التعامل مع Excel عبر C#». وتجدر الإشارة إلى أنه إذا كنت تريد فقط معرفة «من يحتجزه الآن»، فبحث المقابض (Ctrl+F) في Process Explorer أسرع من ProcMon.³

5.5 «الإقلاع بطيء» ── تحديد أين يُستهلك الوقت

افتح Options > Select Columns… وفعّل Duration من قائمة الأعمدة لرؤية الوقت المستغرق لكل عملية. كما يمكن عبر Process Activity Summary وFile Summary في قائمة Tools تجميع عدد مرات العملية والوقت حسب العملية أو الملف. هذا كافٍ لتكوين فرضية مثل «كان هناك عشرات آلاف من قراءات Registry عند الإقلاع» أو «كان الوصول إلى مسار عبر الشبكة ينتظر حتى انتهاء المهلة». لكن التنميط الجاد لمكان استهلاك CPU ليس من اختصاص ProcMon. إذا كان البطء ناتجاً عن الحساب لا الإدخال/الإخراج، فانتقل إلى PerfView وdotnet-trace.

5.6 مشاكل الإقلاع وتسجيل الدخول ── تسجيل زمن الإقلاع

في الحالات التي تقع فيها المشكلة قبل أن تتمكّن من تشغيل ProcMon يدوياً، مثل «الخدمة تفشل قبل تسجيل الدخول» أو «التطبيق المسجَّل في قائمة بدء التشغيل لا يعمل»، استخدم Enable Boot Logging من قائمة Options. تُسجَّل الأحداث من بداية الإقلاع التالي، وعند تشغيل ProcMon بعدها يُطلَب منك الحفظ. تسجيل زمن الإقلاع ميزة رسمية تقدّمها ProcMon،¹ وهي الوسيلة الوحيدة في تحقيقات ترتيب بدء التشغيل وسكربتات تسجيل الدخول.

6. حفظ السجل وتسليمه ── عند طلب الالتقاط في بيئة العميل

في ممارسة تحقيق الأعطال، ليس نادراً أن تكون بيئة إعادة الإنتاج متوفرة فقط لدى العميل. يمكن حفظ سجل ProcMon كملف PML، ويمكن فتحه على جهاز آخر مع رؤية جميع الأعمدة والتفاصيل، مما يجعل تقسيم العمل «يجمعه العميل ونحلّله نحن» ممكناً. إليك شكل دليل الإجراءات الذي نعتمده عند الطلب:

1. شغّل Procmon.exe كمسؤول ووافق على اتفاقية الترخيص
2. بعد التشغيل، أوقف الالتقاط مؤقتاً بـ Ctrl+E وامسح العرض بـ Ctrl+X
3. ابدأ الالتقاط بـ Ctrl+E وقم بإعادة إنتاج المشكلة
4. فور إعادة الإنتاج (أو ظهور الخطأ) أوقف الالتقاط فوراً بـ Ctrl+E
5. اختر File > Save… (Ctrl+S)، وحدّد في النافذة المفتوحة البندين التاليين ثم احفظ
   • Events to save: من الخيارات الثلاثة (All events / Events displayed using current filter / Highlighted events) اختر All events
   • Format: من الخيارات الثلاثة (Native Process Monitor Format (PML) / Comma-Separated Values (CSV) / Extensible Markup Language (XML)) اختر Native Process Monitor Format (PML)
6. اضغط ملف PML الناتج في ZIP وأرسله

سبب اختيار الصيغة الأصلية (PML) في Format هو أن PML وحدها تحتفظ بجميع البيانات ويمكن فتحها كما هي في ProcMon على جهاز آخر.¹ CSV سهل الفتح في برنامج جداول، لكن ما يُصدَّر هو محتوى الأعمدة المعروضة فقط، ولا تبقى تفاصيل مثل المكدّس. لا يناسب التسليم على افتراض أن التحليل سيكون من جانبنا.

النقطة الأهم في الخطوة 5 هي «All events». فحتى لو بقي فلتر معيّن مفعّلاً على شاشة الطرف الآخر، فإن التسجيل نفسه شامل بالكامل، مما يتيح لنا إعادة التضييق بحرية. أما في المشاكل التي تستغرق وقتاً طويلاً لإعادة الإنتاج أو التي لا يُعرف متى ستقع، فسيؤدي تركها كما هي إلى استهلاك مستمر للذاكرة؛ لذا حدّد على الأقل واحداً من الخيارين: تفعيل Filter > Drop Filtered Events لتسجيل العملية المستهدفة فقط، أو تبديل وجهة الحفظ عبر File > Backing Files من الذاكرة الافتراضية إلى ملف. إذا تُرك الأمر يعمل طوال الليل دون معرفة هذين الخيارين، فستُستنفَد الذاكرة وتصل ProcMon نفسها إلى حدها قبل الوصول إلى الهدف المراد تحقيقه.

للأتمتة يمكن أيضاً استخدام مفاتيح سطر الأوامر. /AcceptEula لتجاوز نافذة الموافقة، و/BackingFile لتحديد ملف التسجيل، و/Runtime لتحديد إيقاف تلقائي بعدد ثوانٍ، و/Terminate لإنهاء ProcMon قيد التشغيل. بهذه المجموعة يمكن الوصول إلى شكل «يكفي أن يشغّل المشغّل ملف دفعة واحداً عند وقوع العطل ليُحفَظ الدليل». وفكرة تحديد ما يجب جمعه مسبقاً عند وقوع عطل مشتركة مع جمع ملفات تفريغ الأعطال وتصميم سجل الأحداث.

7. حدود ProcMon والتمييز بينها وبين الأدوات الأخرى

ProcMon أداة لرؤية «التسلسل الزمني للعمليات»، وليست مناسبة لكل تحقيق. تقسيم الأدوار في تحقيقاتنا يبدو كما يلي:

الجدول أعلاه قائمة من منطلق الأداة، لذا نقلبه أيضاً من جهة «المجالات التي لا تراها ProcMon». إذا جاء التحقيق فارغاً، ابحث عن وجهة الانتقال في هذا الجدول.

هناك ثلاث نقاط يسهل التردد فيها عند رسم الحدود:

• الشبكة: تسجّل ProcMon أحداث الاتصال والإرسال/الاستقبال عبر TCP/UDP (أي عملية اتصلت بماذا)، لكن لا يمكنها رؤية محتوى الحزمة نفسها. للتحقيق على مستوى البروتوكول انتقل إلى Wireshark أو أداة pktmon القياسية في Windows.⁴
• الذاكرة: لا يمكن تتبّع «استمرار زيادة استخدام الذاكرة» عبر ProcMon. إذا كانت الكومة المُدارة فانتقل إلى تمييز GC عن تسرب الذاكرة، وإذا كانت المقابض فانتقل إلى إجراءات تحقيق تسرب المقابض.
• المكدّس: في الواقع تسجّل ProcMon أيضاً مكدّس الخيط المصدر لكل حدث (النقر المزدوج على الحدث ← تبويب Stack)، وإذا أُعدّت الرموز يمكن تحديد «من أصدر عملية الوصول إلى هذا الملف» على مستوى الكود. عند هذا المستوى يتصل الأمر مباشرة بعالم WinDbg، وتصبح إدارة رموز التصحيح (PDB) عاملاً مؤثراً.

8. الخلاصة ── انظر إلى الحقائق قبل قراءة الكود

أول ما يجب فعله عند تحقيق عطل معتمد على البيئة ليس قراءة الكود ولا وضع الفرضيات، بل تسجيل ما حدث فعلياً. ProcMon هي أقصر طريق لذلك؛ فبتثبيت يستغرق دقيقة والتقاط يستغرق دقائق، يمكن الحصول على حقائق ثابتة عن «أي مسار، وبأي ترتيب، وبأي صلاحية تم لمسه، وما الذي فشل». إتقان هذه النقاط الثلاث — مرحلتا الفلتر (العملية ثم Result)، وكيفية قراءة Result التي تبدو شاذة لكنها طبيعية، والتسليم بحفظ جميع الأحداث — يجعل التحقيق الذي كان متوقفاً عند عبارة «لا يمكن إعادة إنتاجه على جهاز التطوير» يتقدّم خطوة في نفس اليوم.

نتولى في شركة كومورا سوفت ذ.م.م. تحقيق الأعطال التي لا تُعرف شروط إعادة إنتاجها، وتجهيز إجراءات جمع الأدلة للأعطال التي تقع فقط في بيئة العميل، وتحليل الأسباب بالجمع بين ProcMon وWinDbg وPerfView. يمكننا المساعدة حتى من مرحلة «لا يظهر شيء في السجل لكن التطبيق لا يعمل».

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

• قراءة ملفات تفريغ الأعطال عبر WinDbg + SOS ── مدخل عملي للتحليل بعد الجمع
• تحديد «البطء» باستخدام PerfView وdotnet-trace ── مدخل عملي للتحقيق في أداء .NET
• مدخل إلى جمع ملفات تفريغ أعطال Windows - WER/ProcDump/WinDbg
• آلية حل أسماء DLL في Windows - ترتيب البحث وSxS
• تحقيق انهيار التشغيل الطويل لكاميرا صناعية - قسم تسرب المقابض

مجالات الاستشارة ذات الصلة

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

• تحقيق الأخطاء وتحليل الأسباب
• الاستشارات التقنية ومراجعة التصميم
• تعديل وصيانة برامج Windows القائمة
• اتصل بنا

روابط مرجعية

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

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

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

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

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

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

هل يمكن تشغيل ProcMon بأمان في بيئة الإنتاج؟

التقاط قصير المدة شائع في الميدان، لكنه ليس آمناً بلا قيد. تحمّل ProcMon برنامج تشغيل (driver) وتسجّل كماً هائلاً من الأحداث، فتستهلك بوضوح CPU والذاكرة على الخوادم ذات معدل الأحداث المرتفع. الإجراءات الثلاثة: (1) ابدأ الالتقاط قبيل عملية إعادة الإنتاج مباشرة وأوقفه فور انتهائها لتقصير المدة إلى أدنى حد؛ (2) عند الحاجة إلى مراقبة طويلة فعّل Drop Filtered Events من قائمة Filter حتى لا تُحفَظ الأحداث خارج الفلتر؛ (3) اضبط Backing File لتوجيه التسجيل إلى ملف بدل الذاكرة. ويُنصح بإدراجه ضمن عملية الموافقة نفسها لعمليات التغيير المعتادة، مثل التنفيذ خارج ساعات العمل أو بعد أخذ لقطة (snapshot).

الأحداث كثيرة جداً ولا أجد السطر المطلوب. كيف أضيّق النطاق؟

القاعدة هي أولاً Include على Process Name لحصر العرض في العملية المستهدفة، ثم التضييق عبر Result إلى الحالات الشاذة (مثل NAME NOT FOUND وACCESS DENIED). بعد العثور على سطر واحد قريب من الهدف، انقر بزر الفأرة الأيمن واستخدم Include وExclude للتضييق التفاعلي. في المقابل، من الأخطاء الشائعة حفظ السجل والفلتر مفعّل ثم اكتشاف نقص المعلومات؛ لذا عند حفظ السجل لتسليمه لشخص آخر تذكّر أن الفلتر تضييق للعرض فقط، واحفظ جميع الأحداث. كذلك يُحمَل إعداد الفلتر إلى التشغيل التالي، فإذا ظهرت الشاشة فارغة فتحقق أولاً من فلتر قديم عبر Reset Filter في قائمة Filter.

هل BUFFER OVERFLOW في عمود Result مؤشر على خلل أو هجوم؟

لا. لا علاقة لها بهجمات تجاوز سعة المخزن المؤقت في الأمن السيبراني؛ بل هي تبادل طبيعي لـ API بمعنى «البيانات المطلوبة أكبر من المخزن المؤقت الذي جهّزه المستدعي، فأعاد النظام الحجم اللازم». كثير من واجهات البرمجة تُستدعى أولاً بمخزن صغير لمعرفة الحجم، ثم يُعاد التخصيص والاستدعاء؛ فإذا تلا ذلك مباشرة SUCCESS على نفس المسار فلا مشكلة. وبالمثل غالباً ما تعني NAME NOT FOUND «لم يُعثر عليه في مرحلة وسطى من ترتيب البحث»، وإن انتهى الأمر بـ SUCCESS في مكان ما فليست حالة شاذة. لا تُعدّ قيمة Result الشاذة سبباً إلا بعد التأكد من أن فشل تلك العملية مرتبط سببياً بأعراض التطبيق.

كيف نميّز بين استخدام Process Explorer وProcess Monitor؟

Process Monitor تسجّل «تدفق العمليات» (متى، أي عملية، أي مسار، ماذا فعلت، وما النتيجة) بترتيب زمني، بينما Process Explorer تعرض «الحالة الآنية» (أي عملية تفتح أي ملف أو DLL الآن، واستخدام CPU والذاكرة). إذا أردت معرفة «لا يمكنني حذف هذا الملف، من يحتجزه؟» فبحث المقابض في Process Explorer هو الأسرع، أما إذا أردت معرفة «متى وبأي ترتيب يقرأ التطبيق هذا الملف؟» فProcess Monitor أنسب. في الميدان نُبقي الأداتين معاً ضمن Sysinternals Suite: الحالة عبر Process Explorer، والتاريخ عبر Process Monitor.

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

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

غو كومورا

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

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