02 يونيو 2025·8 دقيقة
مارك روسينوفيتش وداخليات ويندوز: المراقبة والموثوقية
تعرف كيف شكّلت عقلية مارك روسينوفيتش في داخليات ويندوز أدوات Sysinternals، سير عمل WinDbg، وممارسات رصد عملية لتصحيح الأخطاء وزيادة موثوقية ويندوز.
تعرف كيف شكّلت عقلية مارك روسينوفيتش في داخليات ويندوز أدوات Sysinternals، سير عمل WinDbg، وممارسات رصد عملية لتصحيح الأخطاء وزيادة موثوقية ويندوز.
إذا كنت تشغّل ويندوز في بيئة إنتاج—على لابتوبات أو خوادم أو VDI أو آلات افتراضية بالسحابة—فأعمال مارك روسينوفيتش ما زالت تظهر في العمليات اليومية. ليس بسبب شخصية أو حنين، بل لأنه ساعد في تعميم نهج «الأدلة أولًا» لحل المشكلات: انظر إلى ما يفعله نظام التشغيل فعليًا، ثم فسّر الأعراض بدليل.
المراقبة (Observability) تعني أن بإمكانك الإجابة عن «ما الذي يحدث الآن؟» باستخدام الإشارات التي ينتجها النظام (أحداث، تتبعات، عدادات). عندما يتباطأ خدمة أو يتعطل تسجيل الدخول، فالمراقبة هي الفرق بين التخمين والمعرفة.
التصحيح (Debugging) هو تحويل مشكلة غامضة («تجمّد») إلى آلية محددة («هذا الخيط محجوز على I/O»، «هذه العملية تستخدم ملف الصفحة بشكل مفرط»، «حقن DLL غيّر السلوك»).
الموثوقية هي القدرة على الاستمرار في العمل تحت الضغط والتعافي بشكل متوقع—حوادث أقل، استعادة أسرع، وتغييرات أكثر أمانًا.
معظم "انقطاعات الغموض" ليست غامضة—إنها سلوكيات ويندوز لم تُحدَّد بعد: تسريبات مقابض، عمليات أطفال خارجة عن السيطرة، برامج تشغيل عالقة، انتهاء مهلة DNS، إدخالات بدء تلقائي تالفة، أو أدوات أمنية تضيف حملًا. فهم أساسي لداخليات ويندوز (عمليات، خيوط، مقابض، خدمات، ذاكرة، I/O) يساعدك على التعرف على الأنماط بسرعة وجمع الأدلة الصحيحة قبل أن يختفي السبب.
سنركز على سير عمل عملي وصديق للتشغيل باستخدام:
الهدف ليس تحويلك إلى مهندس نواة، بل جعل حوادث ويندوز أقصر، أكثر هدوءًا، وأسهل في الشرح—حتى تصبح التصحيحات أكثر أمانًا وقابلة للتكرار.
"داخليات" ويندوز هي ببساطة مجموعة الآليات التي يستخدمها ويندوز لإنجاز العمل الحقيقي: جدولة الخيوط، إدارة الذاكرة، بدء الخدمات، تحميل برامج التشغيل، التعامل مع نشاط الملفات والسجل، وفرض حدود الأمان. الوعد العملي واضح: عندما تفهم ما يفعله نظام التشغيل، تتوقف عن التخمين وتبدأ في الشرح.
هذا مهم لأن معظم الأعراض التشغيلية غير مباشرة. "الآلة بطيئة" قد تعني ت contention على CPU، خيط ساخن واحد، عاصفة مقاطعات لبرنامج تشغيل، ضغط على الصفحة، أو مرشح مضاد فيروسات يعرقل I/O للملفات. "يتجمد" قد يكون قفلًا ميتًا، نداء شبكة عالق، مهلة تخزين، أو خدمة تنتظر تبعية. معرفة الداخليات تحول الشكاوى الغامضة إلى فرضيات قابلة للاختبار.
بشكل عام، وضع المستخدم هو حيث تعمل معظم التطبيقات والخدمات. عندما تتعطل، عادةً ما تنهار العملية فقط. وضع النواة هو حيث يعمل ويندوز نفسه وبرامج التشغيل؛ قد تؤدي المشكلات هناك إلى تجميد النظام بأكمله، أو حدوث bugcheck (شاشة زرقاء)، أو تدهور هادئ في الموثوقية.
لا تحتاج نظرية عميقة—فقط ما يكفي لاختيار الأدلة. عملية تستهلك CPU عادةً تكون في وضع المستخدم؛ إعادة تهيئة التخزين المتكررة أو مشكلات برنامج تشغيل الشبكة عادةً تشير إلى وضع النواة.
عقلية روسينوفيتش—المنعكسة في أدوات مثل Sysinternals وفي كتاب Windows Internals—هي "الأدلة أولًا." قبل تغيير إعدادات، أو إعادة التشغيل عشوائيًا، أو إعادة التثبيت، التقط ما يفعله النظام: أي عملية، أي خيط، أي مقبض، أي مفتاح سجل، أي اتصال شبكي، أي برنامج تشغيل، وأي حدث.
ما أن تستطيع الإجابة عن "ما الذي يفعله ويندوز الآن، ولماذا"، تصبح التصحيحات أصغر، أكثر أمانًا، وأسهل للتبرير—وتتوقف أعمال الموثوقية عن كونها إطفاء حرائق تفاعليًا.
يمكن فهم Sysinternals كـ"طقم أدوات للرؤية" على ويندوز: أدوات صغيرة ومحمولة تكشف ما يفعله النظام فعلًا—عملية تلو الأخرى، مقبضًا تلو الآخر، مفتاح سجل تلو الآخر. بدلًا من معاملة ويندوز كصندوق أسود، تتيح لك أدوات Sysinternals ملاحظة السلوك وراء أعراض مثل "التطبيق بطيء" أو "CPU عالٍ" أو "الخادم يقطع الاتصالات."
كثير من الألم التشغيلي ينبع من تخمينات تبدو معقولة: لابد أنها DNS، ربما مضاد الفيروس، تحديث ويندوز معطل مجددًا. عقلية Sysinternals بسيطة: ثق بحدسك بما يكفي لتكوين فرضية، ثم تحقق منها بالأدلة.
عندما ترى أي عملية تستهلك CPU، أي خيط ينتظر، أي مسار ملف يتعرض للضرب، أو أي قيمة سجل يعاد كتابتها، تتوقف عن مناقشة الآراء وتبدأ في تضييق الأسباب. هذا التحول—من السرد إلى القياس—هو ما يجعل معرفة الداخليات عملية، لا أكاديمية.
تُبنى هذه الأدوات للحظة "كل شيء يحترق":
هذا مهم عندما لا تستطيع دفع دورة إعداد طويلة، أو نشر عميل ثقيل، أو إعادة تشغيل لمجرد جمع بيانات أفضل.
Sysinternals قوية، والقوة تحتاج ضوابط:
باستخدام هذه القواعد، تصبح أدوات Sysinternals منهجًا منضبطًا: راقب ما هو مخفي، وازن الحقيقة، وأجرِ تغييرات مبررة لا متمنّيات.
إذا احتفظت بأدوات Sysinternals اثنتين فقط في مجموعة أدوات المسؤول، فلتكن Process Explorer وProcess Monitor. معًا تجيبان عن أكثر الأسئلة شيوعًا "ما الذي يفعله ويندوز الآن؟" دون الحاجة لوكيل أو إعادة تشغيل أو إعداد ثقيل.
Process Explorer هو مدير المهام بعين إشعاعية. عندما تكون الآلة بطيئة أو غير مستقرة، يساعدك على تحديد أية عملية مسؤولة وما الذي ترتبط به.
مفيد خصوصًا لـ:
النقطة الأخيرة قوة موثوقية: "لماذا لا أستطيع حذف هذا الملف؟" غالبًا تصبح "هذه الخدمة تحمل مقبضًا مفتوحًا إليه."
Process Monitor (Procmon) يلتقط أحداثًا مفصلة عبر نظام الملفات، السجل، ونشاط العملية/الخيط. هو الأداة للأسئلة مثل: "ما الذي تغير عندما تجمّد التطبيق؟" أو "ما الذي يضرب القرص كل 10 دقائق؟"
قبل أن تضغط Capture، ضع السؤال في إطار:
Procmon قد يطغى عليك ما لم فلترته بعنف. ابدأ بـ:
نتائج شائعة عملية: تحديد خدمة تتصرف بشكل سيئ وتستعلم عن مفتاح سجل مفقود تكرارًا، اكتشاف ماسح لحظي يلمس آلاف الملفات، أو العثور على محاولة تحميل DLL مفقود ("NAME NOT FOUND") يشرح لماذا لا يبدأ التطبيق على جهاز واحد بينما يعمل على آخر.
عندما "يشعر" جهاز ويندوز بأنه غير سليم، غالبًا لا تحتاج إلى كومة مراقبة كاملة للحصول على تقدم. مجموعة صغيرة من أدوات Sysinternals تجيب بسرعة على ثلاثة أسئلة عملية: ما الذي يبدأ تلقائيًا؟ من يتحدث على الشبكة؟ أين ذهبت الذاكرة؟
Autoruns أسرع طريقة لفهم كل شيء يمكن أن يُشغّل دون تشغيل صريح من المستخدم: خدمات، مهام مجدولة، ملحقات شل، برامج تشغيل، والمزيد.
لماذا يهم للموثوقية: عناصر بدء التشغيل مصدر شائع للإقلاعات البطيئة، التعليقات المتقطعة، وقفزات CPU التي تظهر فقط بعد تسجيل الدخول. محدث واحد غير مستقر، أو برنامج تشغيل مساعد قديم، أو ملحق شل تالف يمكن أن يضر النظام بأكمله.
نصيحة عملية: ركز على الإدخالات غير الموقعة، المضافة حديثًا، أو الفاشلة في التحميل. إذا أدى تعطيل عنصر إلى استقرار الجهاز، فقد حولت عرضًا غامضًا إلى مكوّن محدد يمكن تحديثه أو إزالته أو استبداله.
TCPView يعطيك خريطة فورية للاتصالات والمستمعين النشطين، مرتبطة بأسماء العمليات وPIDs. مثالي لفحوصات الصحة السريعة:
حتى في التحقيقات غير الأمنية، هذا يكشف عوامل مثل عملاء خارجة عن السيطرة، بروكسيات خاطئة الإعداد، أو "عواصف إعادة المحاولة" حيث التطبيق يبدو بطيئًا لكن السبب في الشبكة.
RAMMap يساعدك على تفسير ضغط الذاكرة عبر إظهار أين تُخصص الذاكرة فعليًا.
تمييز قاعدة مفيد:
إذا أبلغ المستخدمون عن "ذاكرة منخفضة" بينما يبدو Task Manager مربكًا، RAMMap يمكنه التأكيد ما إذا كان لديك نمو حقيقي في العمليات، أو ذاكرة مخبأ كثيفة، أو برنامج تشغيل يستهلك الذاكرة غير القابلة للترحيل.
إذا تباطأ التطبيق خلال أيام، Handle قد يكشف أعداد مقابض متزايدة بلا حدود (نمط تسريب كلاسيكي). VMMap مفيد عندما يكون استخدام الذاكرة غريبًا—تجزؤ، مناطق محجوزة كبيرة، أو تخصيصات لا تظهر كـ "private bytes" بسيطة.
تشغيل ويندوز غالبًا يبدأ بما يسهل التقاطه: Event Viewer وبعض لقطات Task Manager. هذا جيد لبقايا الأدلة، لكن استجابة الحوادث الموثوقة تحتاج ثلاثة أنواع مكملة من الإشارات: سجلات (ما حدث)، مقاييس (مدى سوءه)، وتتبعات (ما كان النظام يفعله لحظة بلحظة).
سجلات ويندوز ممتازة للهوية، دورة حياة الخدمات، تغييرات السياسات، والأخطاء على مستوى التطبيق. لكنها متفاوتة: بعض المكونات تسجل بغزارة، وبعضها نادر، ونص الرسالة قد يكون غامضًا ("التطبيق توقف عن الاستجابة")، فاعتبرها مرساة زمنية، لا القصة كاملة.
الانتصارات الشائعة:
عدادات الأداء (وما شابه) تجيب "هل الآلة صحية؟" أثناء الانقطاع، ابدأ بـ:
المقاييس لن تخبرك لماذا حدث ارتفاع، لكنها ستخبرك متى بدأ وما إذا كان يتحسّن.
Event Tracing for Windows (ETW) هو مسجل الرحلة المدمج. بدلًا من رسائل نصية ارتجالية، يصدر ETW أحداثًا مُهيكلة من النواة، وبرامج التشغيل، والخدمات بمعدلات عالية—نشاط العمليات/الخيوط، I/O للملفات، وصول للسجل، TCP/IP، الجدولة، والمزيد. عند هذا المستوى تُصبح كثير من "التوقفات الغامضة" قابلة للتفسير.
قاعدة عملية:
تجنّب "تشغيل كل شيء إلى الأبد." احتفظ بخط قواعد أصغر دائم التشغيل (السجلات الأساسية + المقاييس الأساسية) واستخدم ETW قصير المدى أثناء الحوادث.
أسرع التشخيصات تأتي من محاذاة ثلاث ساعات: تقارير المستخدم ("تجمد عند 10:42"), انعطافات المقاييس (قفزة CPU/القرص), وأحداث السجل/ETW عند نفس الطابع الزمني. عندما تشترك بياناتك في قاعدة زمنية متسقة، تتوقف التخمينات وتبدأ القصص التي يمكنك التحقق منها.
سجلات ويندوز الافتراضية مفيدة لكنها غالبًا تفترض تفاصيل "لماذا الآن؟" التي يحتاجها المشغلون عند تغير شيء مفاجئ. Sysmon (System Monitor) يملأ هذه الفجوة بتسجيل نشاط العملية والنظام بدقة أعلى—خاصة حول الإطلاقات والاستمرارية وسلوك برامج التشغيل.
قوة Sysmon في السياق. بدلًا من "خدمة بدأت فقط"، يمكنك غالبًا رؤية أي عملية أطلقتها مع سطر الأوامر الكامل، عملية الوالد، الهاشات، حساب المستخدم، والطوابع الزمنية النظيفة للمطابقة.
هذا مفيد للموثوقية لأن كثيرًا من الحوادث تبدأ كتغييرات صغيرة: مهمة مجدولة جديدة، محدث صامت، سكربت طائش، أو برنامج تشغيل يتصرف بشكل سيئ.
تكوين Sysmon الذي "يسجل كل شيء" نادرًا ما يكون خيارًا جيدًا كبداية. ابدأ بمجموعة حد أدنى تركز على الموثوقية ووسّع فقط عندما تكون لديك أسئلة واضحة.
مرشحات مبكرة جيدة:
نقّح بقواعد include المستهدفة (مسارات حرجة، حسابات خدمة معروفة، خوادم رئيسية) وقواعد exclude مُختارة (محدثون صاخبون، عملاء إدارة موثوق بهم) حتى تظل الإشارة قابلة للقراءة.
Sysmon غالبًا يساعد في تأكيد أو استبعاد سيناريوهات "تغيير غامض" شائعة:
اختبر التأثير على آلات ممثلة أولًا. Sysmon قد يزيد I/O للقرص وحجم الأحداث، وجمعها مركزيًا قد يصبح مكلفًا بسرعة.
تعامل أيضًا مع حقول مثل سطور الأوامر وأسماء المستخدمين والمسارات كبيانات حسّاسة. ضع ضوابط وصول وحدود احتفاظ وتصفية قبل الانتشار الشامل.
Sysmon أفضل كفتات قيمة عالية. استخدمه مع ETW لأسئلة الأداء العميقة، والمقاييس للكشف عن الاتجاهات، وملاحظات الحوادث المنظمة لربط ما تغير بما تعطل وكيف أصلحت ذلك.
عندما "يتعطل شيء"، الأثر الأكثر قيمة غالبًا هو ملف دراما: لقطة للذاكرة مع حالة تنفيذ كافية لإعادة بناء ما كان يفعله العملية (أو نظام التشغيل) لحظة الفشل. على عكس السجلات، الدرامات لا تتطلب منك توقع الرسالة الصحيحة مسبقًا—إنها تلتقط الدليل بعد الحدث.
الدرامات قد تشير إلى وحدة محددة، مسار استدعاء، ونوع الفشل (انتهاك وصول، تلف heap، قفل ميت، عطل برنامج تشغيل)، وهو ما يصعب استنتاجه من الأعراض فقط.
WinDbg يحول الدرامة إلى قصة. الأساسيات:
سير العمل النموذجي: افتح الدرامة → حمّل الرموز → شغّل تحليل آلي → تحقّق بالاطلاع على السلالم العليا والوحدات المعنية.
"جمّد" عرض، ليس تشخيصًا. لالتقاط تعليق، التقط درامة أثناء عدم الاستجابة وافحص:
غالبًا ما يمكنك تشخيص مشكلات واضحة بنفسك (تعطل متكرر في وحدة واحدة، أقفال ميتة واضحة، ترابط قوي إلى DLL/برنامج تشغيل محدد). اصعد عندما تشير الدرامات إلى برامج تشغيل طرف ثالث/أدوات أمنية، مكونات النواة، أو عندما تكون الرموز/الوصول للمصدر مفقودين—حينها قد يحتاج الأمر لبائع أو Microsoft لتفسير السلسلة كاملة.
كثير من "مشكلات ويندوز الغامضة" تكرر نفس الأنماط. الفرق بين التخمين والإصلاح هو فهم ما يفعله النظام—ونموذج ذهني Internals/Sysinternals يساعدك على رؤيته.
عندما يقول الناس "التطبيق يتسرب ذاكرة" غالبًا يقصدون أحد شيئين.
Working set هي الذاكرة الفيزيائية الحالية المدعومة للعملية. يمكن أن ترتفع وتنخفض عندما يقتطعها ويندوز تحت الضغط.
Commit هي كمية الذاكرة الافتراضية التي وعد النظام بتوفيرها إما برام أو ملف الصفحة. إذا استمر commit في الصعود، لديك خطر تسريب حقيقي: في النهاية تصل لحد الالتزام وتفشل عمليات التخصيص أو يصبح المضيف غير مستقر.
عرض شائع: يعرض Task Manager "RAM متاحة"، لكن الجهاز يتباطأ—لأن الالتزام، وليس الذاكرة الحرة، هو القيد.
المقبض (handle) هو مرجع لكائن نظام (ملف، مفتاح سجل، حدث، قسم، إلخ). إذا تسربت المقابض في خدمة، قد تعمل لساعات أو أيام، ثم تبدأ بالفشل بأخطاء غريبة (لا تستطيع فتح ملفات، لا تستطيع إنشاء خيوط، لا تستطيع قبول اتصالات) مع تزايد عدد المقابض لكل عملية.
في Process Explorer، راقب اتجاهات عدد المقابض مع الزمن. ارتفاع مستمر دليل قوي أن الخدمة "تنسى أن تغلق" شيئًا.
مشكلات التخزين لا تظهر دائمًا كمعدل نقل مرتفع؛ غالبًا تظهر كـ كمون مرتفع وإعادات. في Process Monitor، ابحث عن:
وانتبه إلى مرشحات برامج التشغيل (AV، نسخ احتياطي، DLP). يمكن أن تدخل في مسار I/O وتضيف تأخيرًا أو فشلاً دون أي خطأ من التطبيق.
عملية ساخنة واحدة سهلة: تنفيذ واحد يحرق CPU.
الاحتقان على مستوى النظام أكثر تعقيدًا: CPU عالٍ لأن العديد من الخيوط قابلة للتشغيل وتتصارع على أقفال أو قرص أو ذاكرة. التفكير الداخلي يدفعك للسؤال: "هل المعالج يقوم بعمل مفيد، أم يدور في حلقة أثناء انتظار شيء آخر؟"
عند حدوث مهلات، مَجِّد عملية → اتصال باستخدام TCPView أو Process Explorer. إذا كانت العملية الخاطئة تملك المقبس، فقد وجدت المذنب. إذا كانت العملية الصحيحة تملكه، ابحث عن أنماط: محاولات SYN متكررة، اتصالات قديمة عالقة خامدة، أو انفجار من محاولات الصادرة القصيرة الذي يشير إلى DNS/جدار ناري/بروكسي خاطئ بدلًا من "التطبيق معطل".
تسهل أعمال الموثوقية عندما يتبع كل حادث نفس المسار. الهدف ليس "تشغيل المزيد من الأدوات"—إنما اتخاذ قرارات أفضل بأدلة ثابتة.
اكتب ما يبدو "سيئًا" في جملة واحدة: "التطبيق يتجمد 30–60 ثانية عند حفظ ملف كبير" أو "CPU يقفز إلى 100% كل 10 دقائق." إذا كان بالإمكان إعادة الإنتاج، افعل ذلك عند الطلب؛ إذا لم يكن، حدّد المشغّل (نافذة زمنية، حمل عمل، إجراء مستخدم).
قبل جمع بيانات كثيفة، أكد العرض والنطاق:
هنا تساعد الفحوصات السريعة (Task Manager، Process Explorer، عدادات أساسية) في اختيار ما ستلتقطه بعد ذلك.
التقط الأدلة كما لو كنت ستحيلها لزميل لم يكن حاضرًا. ملف الحالة الجيد عادة يتضمن:
اجعل اللقطات قصيرة ومحددة. تتبّع لمدة 60 ثانية يغطي نافذة الفشل يفوق تتبُّعًا لست ساعات لا يستطيع أحد فتحه.
حوّل ما جمعت إلى سرد بسيط:
إذا لم تستطع شرحه ببساطة، ربما تحتاج لالتقاط أنظف أو فرضية أضيق.
طبق أصغر تصحيح آمن، ثم أكد باستخدام نفس خطوات إعادة الإنتاج والتقاط "قبل مقابل بعد".
لتقليل MTTR، قيِّم الإجراءات وجمّع المهام الروتينية:
بعد الحل، واسأل: "أي إشارة كانت ستجعل هذا واضحًا مبكرًا؟" أضِف تلك الإشارة—حدث Sysmon، مقدم ETW، عداد أداء، أو فحص صحة خفيف—حتى تكون المرة القادمة أقصر وأكثر هدوءًا.
هدف عمل الداخليات ليس "الفوز" بجلسة تتبع—بل تحويل ما رأيته إلى تغييرات تمنع عودة الحادث.
أدوات الداخليات عادة تضيق المشكلة إلى مجموعة صغيرة من الرافعات. احتفظ بالترجمة صريحة:
اكتب جملة "بسبب": «غيّرنا X لأننا رصدنا Y في Process Monitor / ETW / الدرامات.» هذه الجملة تمنع تآكل المعرفة القبلية.
اجعل عملية التغيير تتناسب مع نصف القنبلة:
حتى إن كان السبب الجذري خاصًا، غالبًا ما تأتي الديمومة من أنماط قابلة لإعادة الاستخدام:
احتفظ بما تحتاجه، واحمِ ما لا ينبغي جمعه.
قَصّر فلاتر Procmon على العمليات المشتبه بها، ازل مسارات/أسماء مستخدمين عند المشاركة، عيّن احتفاظًا لتتبعات ETW/Sysmon، وتجنّب الالتقاط الثقيل للشبكة إلا للضرورة.
عندما تمتلك سير عمل قابل للتكرار، الخطوة التالية هي تغليفه ليتمكن الآخرون من تشغيله باستمرار. هنا قد تكون منصة مثل Koder.ai مفيدة: تحوّل قائمة فحص الحادث إلى تطبيق داخلي صغير (واجهة React، خلفية Go مع PostgreSQL) يوجّه المستجيبين خلال "راقب → التقط → اشرح"، يخزن الطوابع الزمنية والوثائق، ويطبق تسمية ومخططات منظمة.
بما أن Koder.ai يبني تطبيقات عبر دردشة باستخدام بنية عوامل، يمكن للفرق التكرار بسرعة—إضافة زر "ابدأ جلسة ETW"، مكتبة قوالب فلاتر Procmon، لقطات/تراجع للتغييرات، أو مولد runbook قابل للتصدير—دون إعادة بناء كاملة في خط أنابيب تطوير تقليدي. إذا تشارك ممارسات داخلية للموثوقية، Koder.ai يدعم تصدير الشيفرة ومقاييس مستويات متعددة (مجاني إلى مؤسسي)، لذا يمكنك البدء صغيرًا وتوسيع الحوكمة لاحقًا.
مرة في الأسبوع، اختر أداة واحدة وتمرين 15 دقيقة: تتبّع بدء تطبيق بطيء مع Procmon، فحص شجرة خدمة في Process Explorer، مراجعة حجم أحداث Sysmon، أو أخذ دراما تعطل واحدة وتحديد الوحدة الفاشلة. التكرار الصغير يبني ذاكرة عضلية تجعل الحوادث الحقيقية أسرع—and أكثر أمانًا.
مارك روسينوفيتش شاع منهجية «الأدلة أولاً» لحل مشكلات ويندوز وقدم (وأثر في) أدوات تجعل النظام قابلاً للرصد عمليًا.
حتى لو لم تقرأ كتاب Windows Internals، فربما تعتمد يوميًا على طرق عمل تشكلت بفضل Sysinternals وETW وتحليل الدرامات لتقصير مدة الحوادث وجعل التصحيحات قابلة للتكرار.
المراقبة هي قدرتك على الإجابة عن «ما الذي يحدث الآن؟» من خلال إشارات النظام.
على ويندوز، يعني ذلك عادة الجمع بين:
معرفة داخليات النظام تساعدك على تحويل أعراض غامضة إلى فرضيات قابلة للاختبار.
مثال: «الخادم بطيء» يمكن تضييقها إلى مجموعة محدودة من الآليات: ت contention للمعالج مقابل ضغط الترحيل إلى القرص مقابل تأخرات I/O مقابل تأثير مرشحات/أدوات الأمان. هذا يسرع عملية التثليث ويساعدك على التقاط الأدلة الصحيحة قبل اختفاء الموقف.
استخدم Process Explorer عندما تريد معرفة من المسؤول.
هو مفيد للحصول على إجابات سريعة مثل:
استعمل Process Monitor عندما تحتاج إلى مسار النشاط عبر نظام الملفات والسجل والعمليات/الخيوط.
أمثلة عملية:
قَلِّل الضجيج واحتفظ بالتقاط نافذة الفشل فقط.
سير عمل جيد كبداية:
أثرٌ أصغر يمكنك تحليله أفضل من أثر هائل لا يستطيع أحد فتحه.
Autoruns يجيب على سؤال «ما الذي يبدأ تلقائيًا؟»—خدمات، مهام مجدولة، ملحقات الشل، برامج تشغيل وغيرها.
مفيد بشكل خاص لـ:
ركز أولًا على الإدخالات غير الموقعة، المضافة حديثًا، أو وعطّل عنصرًا مثيرًا واحدًا في كل مرة مع تدوين السبب.
ETW (Event Tracing for Windows) هو مسجل الرحلة المدمج في ويندوز.
استعمل ETW عندما تخبرك السجلات والمقاييس أن هناك مشكلة لكنها لا تخبرك لماذا—مثل حالات التوقف الناتجة عن تأخيرات I/O أو تأجيلات الجدولة أو سلوك برنامج تشغيل.
احفظ التسجيلات قصيرة وموجهة ووقتيًا مع عرض المستخدم.
Sysmon يضيف سياقًا عالي القيمة (عملية الوالد/الابن، سطور الأوامر، هاشات الملفات، عمليات تحميل برامج التشغيل) الذي يساعد على الإجابة عن «ما الذي تغير؟»
للموثوقية، مفيد لتأكيد:
ابدأ بتكوين محدود ودرِّج قواعد include/exclude للتحكم في حجم الأحداث والتكلفة.
الدرامات (dumps) غالبًا ما تكون أثرًا ذا قيمة عند وقوع التعطل لأنها تلتقط حالة التنفيذ في لحظة الفشل.
WinDbg يحول الدراما إلى إجابات، لكن الرموز الصحيحة ضرورية لسلاسل ومطابقة الوحدات.