دليل عملي لأداة Process Monitor (ProcMon) — تحديد سبب «عدم قراءة الإعدادات» و«ACCESS DENIED» خلال 10 دقائق

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

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

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

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

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

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

2. ما هي ProcMon — التثبيت يستغرق دقيقة واحدة

Process Monitor واحدة من أدوات Sysinternals، وهي أداة مراقبة تعرض بشكل لحظي نشاط نظام الملفات وRegistry والعمليات/الخيوط. إنها الخَلَف الذي دمج وعزّز أداتين سابقتين هما Filemon وRegmon، وتتضمن معلومات تفصيلية لكل حدث، وفلترة غير مدمِّرة (non-destructive filter)، وتسجيل مكدّس الخيوط (thread stack)، وتسجيل زمن الإقلاع (boot-time logging).¹

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

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

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

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

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

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

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

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

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

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

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

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

الثلاث الأهم في التحقيق من بين هذه القيم هي 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 في ProcMon. أما الجانب المقابل، أي كيفية تصميم مكان حفظ ملف الإعدادات، فقد كتبناه في «ليس appsettings.json فقط — الممارسة العملية لإدارة التهيئة».

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 بفضل تسجيلها الزمني المتسلسل.

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

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

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

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

5.6 مشاكل الإقلاع وتسجيل الدخول — تسجيل زمن الإقلاع (Boot Logging)

في الحالات التي تقع فيها المشكلة قبل أن تتمكن من تشغيل 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، اختر All events وليس Events displayed using current filter، واحفظ بصيغة PML، ثم اضغطه في ملف ZIP وأرسله

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

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

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

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

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

• الشبكة: تسجّل ProcMon أحداث الاتصال والإرسال/الاستقبال عبر TCP/UDP (أي عملية اتصلت بماذا)، لكن لا يمكنها رؤية محتوى الحزمة نفسها. للتحقيق على مستوى البروتوكول انتقل إلى Wireshark أو أداة pktmon القياسية في Windows.⁴
• الذاكرة: لا يمكن تتبّع «استمرار زيادة استخدام الذاكرة» عبر ProcMon. إذا كانت الكومة المُدارة (managed heap)، انتقل إلى تمييز GC عن تسرب الذاكرة، وإذا كانت المقابض فانتقل إلى إجراءات تحقيق تسرب المقابض.
• المكدّس (Stack): في الواقع تسجّل ProcMon أيضًا مكدّس الخيط المصدر لكل حدث (النقر المزدوج على الحدث ← تبويب Stack)، وإذا أُعدّت الرموز (symbols) يمكن تحديد «من أصدر عملية الوصول إلى هذا الملف» على مستوى الكود. عند هذا المستوى يتصل الأمر مباشرة بعالم 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) وتسجّل كمًا هائلًا من الأحداث، لذا فهي تستهلك بشكل ملحوظ وحدة المعالجة المركزية والذاكرة على الخوادم ذات معدل الأحداث المرتفع. هناك ثلاثة إجراءات وقائية: (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 مؤشر على خلل أو هجوم؟

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

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

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

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

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

غو كومورا

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

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