شركة كومورا سوفت ذ.م.م.
تواصل معنا
القائمة

عندما يُعامَل تطبيق Windows الذي طوّرته شركتك بوصفه فيروساً ── التعامل مع الكشف الخاطئ في Microsoft Defender والتعايش مع أثره على الأداء

· آخر تحديث: · · Microsoft Defender, مكافحة الفيروسات, الكشف الخاطئ, توقيع الشيفرة, SmartScreen, توزيع التطبيقات, الأمان, C#, .NET, تطوير Windows, الاستشارات التقنية

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

هذه ليست حادثة نادرة. فبرامج مكافحة الفيروسات الحديثة لا تكتفي بـ«مطابقة برمجيّات خبيثة معروفة»، بل تُقدِّر «درجة الاشتباه» عبر التعلّم الآليّ والسلوك والسمعة (reputation) السحابيّة، لذا يستحيل بحكم الآليّة نفسها تجنّب الاشتباه بملفّ ثنائيّ شرعيّ بلا سجلّ سابق. والتعامل مع الكشف الخاطئ ينقسم بوضوح إلى ما يجوز فعله (الإبلاغ عن الكشف الخاطئ لِـ Microsoft، الاستثناء المحدود) وما لا يجوز فعله (تعطيل مكافحة الفيروسات، الاستثناء الواسع).

في هذا المقال، نرتّب من منظور المطوّر آليّة حدوث الكشف الخاطئ، والوقاية الممكنة قبل التوزيع، والمسار الرسميّ للتعامل عند الكشف، وإعدادات الاستثناء بوصفها إجراءً إسعافيّاً في بيئة العميل ومخاطرها، وأخيراً كيفيّة التعامل مع الاستشارة الشائعة الأخرى: «Defender (MsMpEng.exe) بطيء/ثقيل».

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

  • قد يحدث الكشف الخاطئ حتّى للتطبيقات الشرعيّة. فمنذ عام 2015، انتقل Defender من محرّك يعتمد أساساً على التوقيعات الثابتة (static signatures) إلى نموذج تنبّئيّ يستخدم التعلّم الآليّ والحماية السحابيّة، بحيث يُحكَم على الملفّات المجهولة بناءً على «درجة الاشتباه» حتّى لو لم تطابق برمجيّة خبيثة معروفة.12
  • المسار الرسميّ للحلّ الدائم هو تقديم الملفّ إلى Microsoft (الإبلاغ عن الكشف الخاطئ). قدِّمه بصفتك مطوّراً عبر بوّابة تقديم العيّنات الخاصّة بـ Microsoft Security Intelligence وتابع نتيجة الفحص. وإذا لم تقتنع بالنتيجة، يمكنك طلب إعادة التحقيق عبر نموذج الاتّصال الخاصّ بالمطوّرين.34
  • يمكن استعادة الملفّات المحجورة. أعِدها من «سجلّ الحماية» في أمان Windows، أو عبر سطر الأوامر باستخدام MpCmdRun.exe -Restore.5
  • إعداد الاستثناء «إجراء مؤقّت حتّى تظهر نتيجة الإبلاغ». الاستثناء ثغرة في الحماية (protection gap)، وتذكر Microsoft صراحةً وجوب استخدامه «باعتدال، وفي مشكلة محدّدة فقط، مع مراجعته دوريّاً». إن أُضيف، فليكن بأضيق نطاق عبر تحديد المسار الكامل، مع ترك سجلّ به.6
  • ركيزة الوقاية هي التوقيع الثابت للشيفرة (code signing). لا تملك Microsoft برنامج تسجيل مسبَق لمنع الكشف الخاطئ، والطريقة الرسميّة الموصى بها هي الاستمرار في التوقيع بثبات عبر شهادة من مرجع تصديق جذر موثوق، ما يُسرِّع تحديد المصدر والإدراج في قائمة معروفة.4
  • الفحص الذاتيّ والتقديم المسبَق قبل الإصدار يقلِّلان من «انعدام السجلّ». يمكن فحص مخرجات التوزيع بفحص مخصّص عبر MpCmdRun.exe، وتوضّح Microsoft نفسها أنّ تقديم الملفّات المجهولة كعيّنة وسيلة للبدء في بناء سمعة (reputation).78
  • «Defender بطيء» يبدأ دائماً بالقياس. حدِّد الملفّ/العمليّة التي تمثّل مركز حمل الفحص عبر أداة Performance analyzer (New-MpPerformanceRecording / Get-MpPerformanceReport) قبل التفكير في أيّ معالجة. والاستثناء هنا أيضاً هو الملاذ الأخير.910

2. لماذا تُعامَل التطبيقات الشرعيّة بوصفها فيروسات

إذا بقي فهمك أنّ «برنامج مكافحة الفيروسات = مطابقة أنماط (توقيعات) فيروسات معروفة»، فسيبدو الكشف الخاطئ أمراً غير مفهوم. لكنّ Defender الحديث مختلف. صرّحت Microsoft في عام 2015 بأنّها انتقلت من محرّك يعتمد على التوقيعات الثابتة إلى نموذج يستخدم تقنيّات تنبّؤيّة كالتعلّم الآليّ والعلوم التطبيقيّة والذكاء الاصطناعيّ.1

يجري الكشف عبر طبقات متعدّدة. تعمل على الجهاز نماذج تعلّم آليّ خفيفة، وتحليل سلوكيّ، وأساليب استدلاليّة (heuristics)، والملفّات التي لا يمكن الحسم فيها على الجهاز وحده تُرسَل بياناتها الوصفيّة (metadata) إلى خدمة الحماية السحابيّة، وغالباً ما يعود القرار خلال أجزاء من الثانية (ميلي ثانية). وإن تعذّر الحسم حتّى بعد ذلك، تُطلَب عيّنة من الملفّ ويُخضَع للفحص وللتفجير (detonation، أي التشغيل في بيئة معزولة) وتحليل البيانات الضخمة على الجانب السحابيّ. وفي البيئات التي تفعَّل فيها ميزة «block at first sight (الحظر عند أوّل رصد)»، قد يُعلَّق فتح الملفّ مؤقّتاً حتّى يصدر قرار السحابة.211

دلالة هذه الآليّة واضحة: مادّة الحكم لا تقتصر على «مطابقة خبيثة»، بل تشمل أيضاً «سجلّ حسن النيّة». وتنصّ معايير تصنيف Microsoft صراحةً على فئة «Unknown (برمجيّة غير معروفة)»، ويُوصَف التحذير من البرامج المجهولة أو قليلة سجلّ التنزيل بأنّه «نظام إنذار مبكِّر لبرمجيّات خبيثة لم تُكتشَف بعد». والتصنيف الرسميّ يقول إنّه ليس كلّ برنامج نادر خبيثاً، لكنّ خطورة الفئة المجهولة عالية بالنسبة للمستخدم العاديّ.8

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

  • بنية تُخفي جوهر الشيفرة. يتضمّن تصنيف Microsoft للبرمجيّات الخبيثة نوعاً يُسمّى «Obfuscator (التعتيم)» يُخفي الشيفرة والغرض منها ليصعِّب الكشف، وتُعدّ البرمجيّات التي تحاول بفعاليّة تفادي كشف منتجات الأمان أحد تصنيفات التطبيقات غير المرغوب فيها (PUA). وأدوات التعتيم، وصيغ الاستخراج الذاتيّ (self-extracting)، والتحزيم الذي يضمّ بيئة التشغيل (runtime) في ملفّ exe واحد، بنى يصعب تمييزها ظاهريّاً عن البنى التي تُكثِر البرمجيّات الخبيثة استخدامها، فيسهل الاشتباه بها حتّى في التطبيقات الشرعيّة.8
  • عدم وجود توقيع، وانعدام دليل لتتبّع المصدر. كما سيرد في الفصل التالي، يمثّل التوقيع الثابت الدليل الرئيسيّ الذي يعتمد عليه فريق التحقيق لتحديد المصدر.4
  • تضمين المثبِّت برمجيّات أخرى معه. فالمثبِّت الذي يقترح تثبيت برمجيّات من جهة تطوير مختلفة أو غير ضروريّة للتشغيل يقع ضمن تصنيف PUA باسم «Bundling software».8

وتجدر الإشارة إلى أنّ التحذير الأزرق «قام Windows بحماية جهاز الكمبيوتر الخاص بك» الذي يظهر فور التنزيل هو آليّة مختلفة (Microsoft Defender SmartScreen) عن كشف مكافحة الفيروسات في Defender. وتنصّ الأسئلة الشائعة الخاصّة بالمطوّرين من Microsoft صراحةً على أنّ SmartScreen لا علاقة له بمكافحة الفيروسات في Defender.4 وقد رتّبنا موضوع SmartScreen والسمعة بالتفصيل في «لماذا يظهر تحذير «قام Windows بحماية جهاز الكمبيوتر الخاص بك» في Windows»، فتأكّد أوّلاً من نوع التحذير الذي تواجهه.

3. الوقاية الممكنة قبل التوزيع

3.1. توقيع الشيفرة الثابت ── لا يوجد برنامج تسجيل مسبَق

فكرة «ألا يمكن التسجيل مسبقاً في القائمة البيضاء لدى Microsoft لتفادي الكشف الخاطئ؟» فكرة طبيعيّة، لكنّ الجواب هو لا. لا تستقبل Microsoft من المطوّرين طلبات التسجيل في قائمة معروفة أو الانضمام إلى برنامج لمنع الكشف الخاطئ. وبدلاً من ذلك، توجِّه الأسئلة الشائعة الرسميّة إلى الاستمرار في توقيع مجموعة ملفّات البرنامج بثبات عبر شهادة صادرة من مرجع تصديق جذر موثوق. فوجود توقيع ثابت يتيح لفريق التحقيق تحديد مصدر البرنامج بسرعة وتطبيق معرفة سابقة عليه، ما قد يُسرِّع إضافة البرنامج إلى قائمة معروفة، بل وقد تُدرَج الشهادة نفسها، وإن كان ذلك أقلّ تكراراً، في قائمة الجهات المُصدِرة الموثوقة.4

وبالمقابل، فإنّ أثر التوقيع يكمن في تجميع «السجلّ على مستوى الملفّ» إلى «سجلّ على مستوى الجهة المُصدِرة». فالملفّ التنفيذيّ الذي يتغيّر رمزه التجزيئيّ (hash) في كلّ بناء (build) يكون «ملفّاً يُرى للمرّة الأولى» في كلّ مرّة إذا نُظِر إليه على مستوى الملفّ، لكن إذا وُقِّع بالشهادة نفسها يبقى المصدر متّصلاً. راجع مقال SmartScreen أعلاه و«قائمة التحقّق الأدنى لأمان تطوير تطبيقات Windows» بخصوص الممارسة العمليّة للتوقيع (أنواع الشهادات، Azure Artifact Signing، الطابع الزمنيّ).

3.2. الفحص الذاتيّ قبل الإصدار

فحص مخرجات البناء الخاصّة بك كجزء من قرار الإصدار أرخص بكثير من اكتشاف الكشف لاحقاً في بيئة العميل بعد التوزيع. يمتلك Defender أداة سطر أوامر باسم MpCmdRun.exe، يمكن استخدامها في الأتمتة من السكربتات أو المهامّ المجدولة. وبما أنّها غير مدرَجة في PATH افتراضيّاً، انتقل إلى %ProgramData%\Microsoft\Windows Defender\Platform\<الإصدار> (أو %ProgramFiles%\Windows Defender إن لم يوجد) قبل تنفيذها.7

rem نفِّذ عبر موجّه أوامر بصلاحيّات المدير
cd /d "C:\ProgramData\Microsoft\Windows Defender\Platform\<مجلّد أحدث إصدار>"

rem فحص مخصّص لمجلّد الإصدار (-ScanType 3)
rem -DisableRemediation: حتّى مع الكشف، لا تُتَّخذ إجراءات كالحجر، وتُعرَض النتيجة في مخرجات الأمر
MpCmdRun.exe -Scan -ScanType 3 -File "C:\Release\MyApp" -DisableRemediation

قيمتا الإرجاع المعرَّفتان هما 0 و2، لكن ما يسهل إغفاله عند استخدامها كبوّابة تحقّق (gate) هو أنّ القيمة 0 لا تعني «لا يوجد كشف» فقط، بل تشمل أيضاً «حدث كشف لكن نجح الإصلاح». فإذا استُخدِم -Scan وحده دون خيارات، قد يحدث أسوأ توليفة ممكنة: يكشف Defender مخرجات الإصدار ويصل الأمر إلى حجرها، ومع ذلك تكون قيمة الإرجاع 0 فتمرّ خطّ الأنابيب (pipeline) باعتبارها «نظيفة». في الفحص المخصّص، أضِف -DisableRemediation لمنع اتّخاذ أيّ إجراء عند الكشف (تظهر نتيجة الكشف في مخرجات الأمر)، وأضِف إلى بوّابة التحقّق — بالإضافة إلى قاعدة «إذا عادت القيمة 2 أوقف الشحن وابدأ التحقيق» — التحقّق من وجود كشف في مخرجات الأمر ومن عدم فقدان أيّ ملفّ من ملفّات المخرجات.7

3.3. تقديم الملفّات المجهولة مسبقاً كعيّنة

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

4. المسار الرسميّ للتعامل عند الكشف الخاطئ

4.1. تأكيد الوقائع أوّلاً ── سجلّ الحماية وسجلّ الأحداث

تحقّق أوّلاً ممّا إذا كان تقرير «اختفى» أو «توقّف عن العمل» ناتجاً فعلاً عن كشف Defender. عبر واجهة رسوميّة، يبقى سجلّ الكشف والحجر في «الحماية من الفيروسات والتهديدات» ← «سجلّ الحماية» في أمان Windows، ويمكن أيضاً تصفية عرض العناصر المحجورة.5

إذا أردت الاحتفاظ بها كسجلّ أو التحقّق عن بُعد، فسجلّ الأحداث هو الخيار. تُسجَّل أحداث Defender في «سجلّات التطبيقات والخدمات ← Microsoft ← Windows ← Windows Defender ← Operational»، ويمكن الحصول عليها أيضاً عبر Get-WinEvent في PowerShell.12 ويُسجَّل الكشف نفسه بمعرِّف الحدث 1116 (اكتشاف برمجيّة خبيثة أو غير مرغوب فيها)، بينما يُسجَّل الإجراء المتّخَذ حياله كالحجر بمعرِّف 1117.13

# تحقّق من أحداث كشف Defender (1116) وإجراءاته (1117) من الأحدث إلى الأقدم
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' |
    Where-Object { $_.Id -in 1116, 1117 } |
    Select-Object TimeCreated, Id, Message -First 10

هنا، سجِّل اسم التهديد (كاسم كشف مثل Trojan:Win32/Wacatac.B!ml) ومسار الملفّ المكتشَف وإصداره. فهاتان المعلومتان نقطة الانطلاق سواء في التقديم إلى Microsoft أو في الشرح للعميل. وبنية اسم الكشف (النوع/المنصّة/اسم العائلة) تتبع قاعدة تسمية البرمجيّات الخبيثة CARO، ويمكن أحياناً استنتاج مصدر الكشف من لاحقة مثل !ml في نهاية الاسم.14

4.2. الإبلاغ عن الكشف الخاطئ لِـ Microsoft

هذا هو الحلّ الدائم. قدِّم الملفّ الذي جرى كشفه خطأً عبر بوّابة تقديم العيّنات الخاصّة بـ Microsoft Security Intelligence (microsoft.com/wdsi/filesubmission). يتطلّب التقديم تسجيل الدخول، وإذا سجّلت الدخول يمكنك متابعة حالة الفحص. ولا تُقبَل العيّنات عبر البريد الإلكترونيّ.3

إذا كنتَ مطوّراً، قدِّم الملفّ بصفتك software developer (مطوّر برمجيّات) عند التقديم. انتظر حتّى يُحسَم القرار، وإذا لم تقتنع بالنتيجة يمكنك التواصل مع Microsoft عبر نموذج الاتّصال الخاصّ بالمطوّرين المرفَق بنتيجة التقديم لطلب إعادة التحقيق.4 تُفحَص الملفّات المقدَّمة أوّلاً فحصاً فوريّاً بواسطة نظام آليّ، وإذا كان الملفّ قد عولِج مسبقاً يصدر القرار سريعاً. أمّا الطلبات غير المعالَجة، فتُحلَّل مع إعطاء أولويّة للملفّات ذات النطاق الواسع من التأثير، وللطلبات المقدَّمة من عملاء المؤسّسات الحائزين على Software Assurance ID.15

إذا حدَّثت Microsoft التعريفات معتبرةً الأمر كشفاً خاطئاً، فلن يُكتشَف ذلك الملفّ بعد ذلك. وبالعكس، ما لم تُبلِغ، سيستمرّ الكشف في بيئات عملاء آخرين حتّى لو تجاوزت المشكلة بإعداد استثناء. وحتّى في حالة الكشف السلوكيّ الذي لا يترك ملفّاً باقياً، يوجد مسار لتقديم ملفّ تشخيصيّ (MpSupportFiles.cab) يمكن توليده عبر MpCmdRun.exe -GetFiles وطلب تحليله.157

إذا كان العميل مؤسّسة اعتمدت Microsoft Defender for Endpoint (EDR)، فهناك أيضاً مسار إداريّ يقدِّم فيه مسؤول الأمان لدى العميل الملفّ عبر صفحة التقديمات (Submissions) في بوّابة Microsoft Defender، مع كبح الكشف الخاطئ داخل المؤسّسة عبر مؤشِّر «السماح».15 وفي هذه الحالة، لا تُنجِز الأمر بمفردك، بل نسِّق مع إدارة تقنية المعلومات لدى العميل.

4.3. استعادة الملفّات المحجورة

الملفّات التي تتأكّد أنّها كُشِفت خطأً يمكن استعادتها من الحجر. عبر الواجهة الرسوميّة، اختر الملفّ المستهدَف من سجلّ الحماية واضغط «استعادة». وفي سطر الأوامر، استخدم MpCmdRun.exe.5

rem قائمة العناصر المحجورة
MpCmdRun.exe -Restore -ListAll

rem استعادة إلى الموقع الأصليّ بتحديد مسار الملفّ وقت الحجر
MpCmdRun.exe -Restore -FilePath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

يمكن أيضاً تحديد مجلّد استعادة مختلف عبر خيار -Path (يبقى العنصر في هذه الحالة في الحجر أيضاً).7 لكن إذا جرت الاستعادة قبل تحديث التعريفات، فمن الطبيعيّ أن يُكتشَف مجدَّداً، لذا الأسلم عمليّاً هو السير وفق الترتيب: «الإبلاغ عن الكشف الخاطئ ← استثناء مؤقّت إن لزم ← الاستعادة».

4.4. حالة الكشف بواسطة برنامج مكافحة فيروسات من شركة أخرى

الكشف بواسطة EDR أو منتج مكافحة فيروسات من شركة أخرى غير Defender لا يُحَلّ بالإبلاغ لِـ Microsoft. يجب التقديم بشكل منفصل إلى نافذة الإبلاغ عن الكشف الخاطئ (false positive submission) الخاصّة بمزوِّد المنتج الذي قام بالكشف. توفِّر معظم الجهات المزوِّدة نموذجاً مخصّصاً، فابحث عن النافذة بكتابة «اسم المزوِّد + false positive submission»، وقدِّم الطلب مرفَقاً باسم الكشف والملفّ ومعلومات التوقيع كما في حالة Defender. وإذا حدث الكشف من عدّة منتجات في آنٍ واحد، فذلك مادّة إضافيّة للاشتباه بعوامل من جانب البناء (build) نفسه، كالتعتيم أو أدوات الحزم (packer) أو الملفّات المرفَقة.

5. الإجراء الإسعافيّ في بيئة العميل ── إعداد الاستثناء ومخاطره

5.1. موقع الاستثناء ── ليس حلّاً دائماً

في حالة توقّف عمل العميل حتّى صدور نتيجة الإبلاغ عن الكشف الخاطئ، يصبح الاستثناء (exclusion) في Defender إجراءً إسعافيّاً. لكن يجب عدم الخطأ في موقعه. فكما تحذِّر Microsoft نفسها مراراً، الاستثناء من الناحية التقنيّة ثغرة في الحماية (protection gap)، والمبادئ الرسميّة هي: (1) استخدامه باعتدال، (2) استخدامه فقط لمشكلة محدّدة كمشكلة أداء أو توافق تطبيق، (3) مراجعته دوريّاً مع الاحتفاظ بسجلّ يوضّح لماذا كان هذا الاستثناء ضروريّاً.6 ويُشار إلى أنّ الاستثناء الذي نشرحه هنا هو استثناء من فحص مكافحة الفيروسات في Defender (المجدوَل/عند الطلب/الحماية في الوقت الفعليّ). وفي البيئات التي اعتُمِد فيها Microsoft Defender for Endpoint، قد تستمرّ تنبيهات EDR أو أنواع كشف أخرى في الظهور حتّى للملفّات المستثناة.16 وظهور «تنبيه رغم إضافة الاستثناء» ناتج عن هذه الخاصيّة، وليس خللاً.

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

5.2. الطريقة الصحيحة للإضافة ── المسار الكامل بأضيق نطاق

يمكن إضافة الاستثناء أيضاً عبر الواجهة الرسوميّة لأمان Windows (إعدادات الحماية من الفيروسات والتهديدات ← الاستثناءات)، لكن إذا كنتَ تصيغ ذلك في دليل إجراءات، فـ PowerShell أضمن. لإدارة قائمة الاستثناءات استخدم Add-MpPreference (إضافة)، وRemove-MpPreference (حذف)، وSet-MpPreference (استبدال القائمة بأكملها). وبما أنّ Set-MpPreference يستبدل قائمة الاستثناءات القائمة، احرص دوماً على استخدام Add-MpPreference للإضافة كي لا تمحو استثناءات موجودة مسبقاً في بيئة العميل.16

# نفِّذ عبر PowerShell بصلاحيّات المدير

# استثناء على مستوى الملفّ (أضيق نطاق. المسار الكامل للملفّ التنفيذيّ لا للمجلّد)
Add-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

# تحقّق من إعدادات الاستثناء الحاليّة
Get-MpPreference | Select-Object ExclusionPath, ExclusionProcess, ExclusionExtension

# أزِله عند حلّ الكشف الخاطئ
Remove-MpPreference -ExclusionPath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

يمكن تحديد -ExclusionPath على مستوى الملفّ أو المجلّد، لكن تحديد مجلّد يجعل المجلّدات الفرعيّة بأكملها مشمولة أيضاً، لذا فكِّر أوّلاً بمستوى الملفّ.16 أمّا -ExclusionProcess فهو خيار يسهل سوء فهمه من اسمه، إذ لا يستثني العمليّة المحدَّدة نفسها، بل يستبعد الملفّات التي تفتحها تلك العمليّة من نطاق الفحص. والتصنيف الرسميّ هو أنّه إذا أردتَ استثناء الملفّ التنفيذيّ للعمليّة نفسه فاستخدم -ExclusionPath.17 ففي الحالات التي يحدث فيها الكشف أو مشكلة الأداء بسبب فتح التطبيق كمّيّة كبيرة من ملفّات البيانات، استخدم -ExclusionProcess، وفي الحالات التي يُكشَف فيها الملفّ التنفيذيّ نفسه خطأً، استخدم -ExclusionPath.

يمكن التحقّق من نجاح الاستثناء كما هو مقصود عبر MpCmdRun.exe -CheckExclusion -Path <المسار>.7 كذلك، في البيئات المُدارة، الأساس هو الإدارة المركزيّة عبر Intune أو نهج المجموعة (Computer Configuration ← Administrative Templates ← Windows Components ← Microsoft Defender Antivirus ← Exclusions) بدل الإضافة اليدويّة لكلّ نقطة نهاية على حدة. وتوصي Microsoft باستخدام Intune لتعريف الاستثناءات وتحريرها.1615

5.3. استثناءات لا يجوز إضافتها

يستغلّ المهاجمون أيضاً مجلّد الاستثناء بوصفه «مكاناً لا يراه Defender». وتسرد Microsoft بشكل ملموس عناصر «لا ينبغي استثناؤها حتّى لو كنت واثقاً بأنّها غير ضارّة».18

  • استثناء مجلّدات عامّة مثل C:\، أو C:\Temp، أو C:\Users\، أو %Windir%\Temp. فاستثناء مجلّد مؤقّت بأكمله من أجل تطبيق شركتك هو بمثابة توفير منطقة آمنة لكلّ البرمجيّات الخبيثة.
  • الاستثناء على مستوى الامتداد مثل .exe، أو .dll، أو .tmp، أو .zip.
  • استثناء عمليّات عامّة مثل cmd.exe، أو powershell.exe، أو msbuild.exe، أو java.exe.
  • استثناء اسم ملفّ بلا مسار (مثل ContosoApp.exe). فأيّ برمجيّة خبيثة تحمل الاسم نفسه ستُستثنى أينما وُضِعت، لذا حدِّد المسار الكامل دائماً.

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

6. التعايش مع الأثر على الأداء ── «MsMpEng.exe بطيء»

استشارة معتادة أخرى إلى جانب الكشف الخاطئ هي الأداء. أعراض مثل استحواذ MsMpEng.exe (Antimalware Service Executable) على المعالج (CPU) في مدير المهامّ، وبطء إخراج ملفّات التطبيق أو عمليّة البناء (build). MsMpEng.exe هو جوهر خدمة مكافحة الفيروسات في Defender، والسلوك الافتراضيّ للحماية في الوقت الفعليّ هو «الفحص المتزامن عند فتح الملفّ (open now, scan now)».19 بمعنى أنّه بنية يزداد فيها عدد مرّات الفحص، وتتأثّر بسهولة، كلّما زاد حِمل العمل الذي يفتح ويغلق كمّيّة كبيرة من الملفّات الصغيرة — كالبناء، والكتابة التفصيليّة للسجلّات، والاستخدام الكثيف للملفّات المؤقّتة.

6.1. القياس أوّلاً ── Performance analyzer

قبل الانتقال مباشرةً إلى «الاستثناء لأنّه بطيء»، قِس ما الذي يمثّل مركز حِمل الفحص. يمتلك Defender أداة Performance analyzer مخصّصة، حيث يمكن التقاط سجلّ أداء الفحص (ETL) عبر New-MpPerformanceRecording في PowerShell، وتجميعه عبر Get-MpPerformanceReport.9

# نفِّذ عبر PowerShell بصلاحيّات المدير

# ابدأ التسجيل، وأعِد إنتاج العمليّة الثقيلة (كالبناء أو المعالجة الدفعيّة)، ثمّ أوقفه بالضغط على Enter
New-MpPerformanceRecording -RecordTo .\Defender-scans.etl

# اعرض أعلى الملفّات من حيث زمن الفحص، وتفصيل الفحص لكلّ ملفّ منها
Get-MpPerformanceReport -Path .\Defender-scans.etl -TopFiles 3 -TopScansPerFile 10

بالإضافة إلى -TopFiles / -TopScansPerFile، يمكن أيضاً الحصول على تجميع حسب العمليّة وحسب الامتداد، ما يتيح تحديداً ملموساً لـ«أيّ وصول لملفّات تطبيق شركتك يستحثّ الفحص». وتنبِّه الوثائق الرسميّة نفسها إلى نقطة مهمّة: هذه الأداة لاكتساب رؤية حول الملفّات المشكِلة، وليست لاقتراح استثناءات.10

6.2. ما يمكن فعله من جانب التطبيق قبل الاستثناء

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

  • تجميع معالجة تفتح وتغلق آلاف الملفّات الوسيطة الصغيرة في إضافة إلى عدد قليل من الملفّات أو معالجة داخل الذاكرة
  • تقليل النمط المتكرِّر «كتابة ملفّ مؤقّت ثمّ إعادة تسميته أو حذفه»
  • التخلّي عن تنفيذ يفتح السجلّ ويغلقه لكلّ سطر، والكتابة مع إبقاء الدفق (stream) مفتوحاً

لقياس أيّ عمليّة تلمس أيّ ملفّ وبأيّ تواتر فعليّاً، يمكن استخدام Process Monitor مباشرةً. راجع «دليل عمليّ لـ Process Monitor (ProcMon)» للاطّلاع على الخطوات.

6.3. وضع الأداء الخاصّ بِـ Dev Drive على جهاز التطوير

في سياق بطء البناء على جهاز التطوير، فإنّ Dev Drive + وضع الأداء في Windows 11 هو الخيار الأوّل. فعلى Dev Drive (وحدة تخزين مخصّصة للتطوير قائمة على ReFS)، تعمل الحماية في الوقت الفعليّ الخاصّة بـ Defender بـ«وضع الأداء» غير المتزامن. وبدل الفحص المتزامن عند فتح الملفّ، يُستخدَم أسلوب «open now, scan later» الذي يؤجِّل الفحص إلى ما بعد اكتمال الفتح، ويصفه المصدر الرسميّ بأنّه يحسِّن الأداء مع الحفاظ على حماية أعلى بكثير من أسلوب إيقاف الفحص كلّيّاً كاستثناء المجلّد.19 والأسلوب المتعارف عليه هو نقل شجرة المصدر، وذاكرة تخزين الحزم المؤقّتة، ومخرجات البناء إلى Dev Drive.20

لكنّ وضع الأداء يعمل فقط على Dev Drive، ويفترض أن تكون الحماية في الوقت الفعليّ مفعَّلة. كما أنّ التعامل مع عرَض «ارتفاع استخدام MsMpEng.exe للمعالج/الذاكرة» ليس ضمن نطاق وضع الأداء، والإرشاد الرسميّ في تلك الحالة هو تضييق نطاق العمليّات والمسارات الساخنة عبر Performance analyzer المذكور سابقاً.19

وفضلاً عن ذلك، إذا كان الفحص عند الطلب (كالفحص الكامل الدوريّ مثلاً) بطيئاً خلال ساعات العمل، فمن المفيد أن تتذكّر وجود مفتاح -CpuThrottling في MpCmdRun.exe -Scan. وعند إضافته يُطبَّق حدّ أقصى (50% افتراضيّاً) على استخدام الفحص للمعالج.7 لكنّه ليس بصيغة تُمرَّر فيها نسبة اختياريّة كقيمة إلى المفتاح. فالحدّ الأقصى نفسه يُضبَط عبر إعداد على مستوى السياسة (ScanAvgCPULoadFactor)، وهذه القيمة ليست حدّاً صارماً بل مؤشِّر توجيهيّ لمحرّك الفحص بمعنى «لا تتجاوز هذه النسبة في المتوسّط».21

7. جدول القرار ── الإجراء الواجب حسب العرَض

الحالة ما تفعله أوّلاً الحلّ الدائم
اكتُشِف فور بناء ذاتيّ، على جهاز التطوير أو في CI تحقّق من اسم الكشف والمسار عبر سجلّ الحماية وسجلّ الأحداث (1116/1117)13. تحقّق من تغييرات البناء (تعتيم، أداة حزم، ملفّات مرفَقة) التقديم عبر بوّابة تقديم العيّنات بصفتك مطوّراً3. إعادة النظر في نظام التوقيع. دمج الفحص قبل الإصدار في CI
اكتُشِف وحُجِز في بيئة العميل تحقّق من اسم الكشف والملفّ وما إذا كان Defender أو منتجاً من شركة أخرى. قدِّم بلاغ الكشف الخاطئ، وإذا كان توقّف العمل خطيراً فاستثناء بالمسار الكامل + استعادة بالاتّفاق مع إدارة تقنية المعلومات لدى العميل5 أزِل الاستثناء بعد التأكّد من صدور القرار وتحديث التعريفات. العملاء المعتمدون لِـ EDR يستخدمون أيضاً المسار الإداريّ (تقديم عبر البوّابة، مؤشِّر السماح)15
اكتُشِف بواسطة برنامج مكافحة فيروسات من شركة أخرى احصل من العميل على اسم المنتج الذي كشفه وإصداره واسم الكشف قدِّم إلى نافذة الإبلاغ عن الكشف الخاطئ الخاصّة بذلك المزوِّد. إذا اكتُشِف من عدّة شركات فاشتبه بعوامل من جانب البناء
ظهور «قام Windows بحماية جهاز الكمبيوتر الخاص بك» (SmartScreen) تأكّد من أنّه ليس كشف فيروس (آليّة مختلفة عن كشف Defender)4 تجهيز توقيع الشيفرة ومسار التوزيع (راجع مقال SmartScreen)
Defender (MsMpEng.exe) بطيء أو الإدخال/الإخراج بطيء القياس عبر Performance analyzer وتحديد الملفّات والعمليّات الساخنة9 تحسين نمط كتابة التطبيق. جهاز التطوير: Dev Drive + وضع الأداء19. الاستثناء كملاذ أخير بأضيق نطاق6

المشترك بين جميع الحالات ثلاث نقاط: «تحديد الوقائع أوّلاً (اسم الكشف، الهدف، المنتج الذي كشفه)»، و«تشغيل الحلّ الدائم المتمثِّل بالإبلاغ دائماً»، و«الاستثناء والاستعادة كإجراء مؤقّت بأضيق نطاق».

8. الخلاصة

  • Defender الحديث لا يحكم عبر مطابقة التوقيعات، بل عبر التعلّم الآليّ والحماية السحابيّة والسجلّ (السمعة). واشتباه ملفّ ثنائيّ جديد بلا سجلّ أمر حتميّ بحكم الآليّة نفسها، وتزداد فرصة الاشتباه أكثر مع بنى «تخفي الجوهر» كالتعتيم والاستخراج الذاتيّ.
  • ركيزة الوقاية هي التوقيع الثابت للشيفرة بشهادة من مرجع تصديق موثوق. لا يوجد برنامج تسجيل مسبَق لمنع الكشف الخاطئ. كما يفيد الفحص الذاتيّ عبر MpCmdRun.exe قبل الإصدار، وتقديم عيّنة مسبَقاً في الإصدارات التي يتغيّر فيها الشكل الظاهريّ بشكل كبير.
  • عند حدوث الكشف، حدِّد اسم الكشف والهدف عبر سجلّ الحماية وسجلّ الأحداث (المعرِّف 1116/1117)، وقدِّمه بصفتك مطوّراً إلى بوّابة تقديم العيّنات الخاصّة بـ Microsoft Security Intelligence. ويمكن استعادة الملفّات المحجورة من سجلّ الحماية أو عبر MpCmdRun.exe -Restore.
  • إعداد الاستثناء إجراء مؤقّت حتّى صدور نتيجة الإبلاغ. بالمسار الكامل وبأضيق نطاق، مع ترك سجلّ، وإزالته عند الحلّ. ويُمنَع منعاً باتّاً استثناء المجلّدات المؤقّتة أو الامتدادات أو العمليّات العامّة لأنّها تخلق مخبأً للبرمجيّات الخبيثة.
  • بالنسبة لمشكلات الأداء، قِس أوّلاً عبر Performance analyzer، وادرس تحسين نمط كتابة التطبيق ووضع الأداء الخاصّ بـ Dev Drive، ولا تفكِّر في استثناء محدود إلّا إذا ظلّت الحاجة قائمة رغم ذلك. أمّا طلب تعطيل الحماية في الوقت الفعليّ من العميل فأمر غير وارد أصلاً.

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

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

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

المراجع

  1. Microsoft Learn, Microsoft Defender Antivirus in Windows Overview. حول الانتقال في عام 2015 من محرّك يعتمد على التوقيعات الثابتة إلى نموذج تنبّئيّ يستخدم التعلّم الآليّ والعلوم التطبيقيّة والذكاء الاصطناعيّ، وحول كشف الشذوذ والحماية القائمة على السلوك. ↩ ↩2

  2. Microsoft Learn, Cloud protection and sample submission at Microsoft Defender Antivirus. حول نماذج التعلّم الآليّ والتحليل السلوكيّ والأساليب الاستدلاليّة (heuristics) على الجهاز، وإرسال البيانات الوصفيّة إلى الحماية السحابيّة (يُحسَم القرار في أجزاء من الثانية غالباً)، والبنية متعدّدة الطبقات لإرسال العيّنات والتفجير (detonation) وتحليل البيانات الضخمة. ↩ ↩2

  3. Microsoft Learn, Submit files for analysis. حول إمكانيّة تقديم الملفّات المكتشَفة خطأً عبر بوّابة تقديم العيّنات (microsoft.com/wdsi/filesubmission)، وضرورة تسجيل الدخول لمتابعة الطلب، وعدم قبول العيّنات عبر البريد الإلكترونيّ. ↩ ↩2 ↩3

  4. Microsoft Learn, Software developer FAQ. حول عدم وجود برنامج تسجيل مسبَق أو برنامج لمنع الكشف الخاطئ، وأنّ التوقيع الثابت بشهادة من مرجع تصديق جذر موثوق يُسرِّع تحديد المصدر والإدراج في قائمة معروفة، والتقديم بصفة مطوّر والاعتراض على القرار (نموذج الاتّصال الخاصّ بالمطوّرين)، وكون SmartScreen آليّة مختلفة عن مكافحة الفيروسات في Defender. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. Microsoft Learn, Restore quarantined files in Microsoft Defender Antivirus. حول التحقّق من العناصر المحجورة واستعادتها عبر «سجلّ الحماية» في أمان Windows، وإجراءات عرض قائمة الحجر واستعادتها عبر MpCmdRun. ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Configure custom exclusions for Microsoft Defender Antivirus. حول كون الاستثناء ثغرة في الحماية (protection gap) تخفض الحماية ويجب استخدامها باعتدال، واستخدامها فقط لمشكلة محدّدة دون إضافتها لغرض وقائيّ مستقبليّ، ووجوب مراجعتها دوريّاً مع الاحتفاظ بسجلّ للسبب. ↩ ↩2 ↩3

  7. Microsoft Learn, Configure and manage Microsoft Defender Antivirus with the MpCmdRun command-line tool. حول مكان وجود MpCmdRun.exe ومتطلّبات صلاحيّات المدير، والخيار -Scan (الفحص المخصّص عبر -ScanType 3، وتحديد -File، وكون قيمة الإرجاع 0 تشمل كلّاً من «لا كشف» و«حدث كشف لكن نجح الإصلاح» بينما تعني 2 «حدث كشف دون إصلاح/يلزم إجراء من المستخدم/خطأ فحص»، و-DisableRemediation لعدم اتّخاذ إجراء عند الكشف مع عرض النتيجة في مخرجات الأمر، والقيمة الافتراضيّة 50 لـ -CpuThrottling)، والخيار -Restore (-ListAll/-Name/-FilePath/-Path)، والخيار -CheckExclusion، والخيار -GetFiles. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  8. Microsoft Learn, How Microsoft identifies malware and potentially unwanted applications. حول وصف التحذير من فئة «Unknown (برمجيّة غير معروفة)» بأنّه نظام إنذار مبكِّر لبرمجيّات خبيثة لم تُكتشَف بعد، وفائدة تقديم العيّنات في بدء بناء السمعة (reputation)، وتصنيفات Obfuscator وEvasion software وBundling software. ↩ ↩2 ↩3 ↩4 ↩5

  9. Microsoft Learn, Performance analyzer for Microsoft Defender Antivirus. حول التقاط السجلّ عبر New-MpPerformanceRecording، وإعادة إنتاج العمليّة، وإجراءات التحليل عبر Get-MpPerformanceReport بخيارات مثل -TopFiles/-TopScansPerFile. ↩ ↩2 ↩3

  10. Microsoft Learn, Microsoft Defender Antivirus Performance Analyzer reference. حول كون Performance analyzer أداة لاكتساب رؤية حول الملفّات المشكِلة وليست لاقتراح استثناءات، ووجوب تعريف الاستثناءات بحذر لأنّها تخفض الحماية، والحاجة إلى صلاحيّات المدير. ↩ ↩2

  11. Microsoft Learn, Turn on block at first sight. حول آليّة قيام الواجهة الخلفيّة السحابيّة بالحكم على الملفّات المجهولة المشبوهة عبر الأساليب الاستدلاليّة والتعلّم الآليّ والتحليل الآليّ وحظرها خلال ثوانٍ، وإمكانيّة تعليق فتح الملفّ حتّى صدور القرار. ↩

  12. Microsoft Learn, Troubleshoot Microsoft Defender Antivirus scan issues. حول مكان سجلّ أحداث Defender (Applications and Services Logs ← Microsoft ← Windows ← Windows Defender ← Operational)، وطريقة الحصول عليه عبر Get-WinEvent. ↩

  13. Microsoft Learn, Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus. حول قائمة معرِّفات أحداث Defender، ومنها المعرِّف 1116 (الكشف) والمعرِّف 1117 (إجراء كالحجر أو الحذف). ↩ ↩2

  14. Microsoft Learn, Malware names. حول اتّباع اسم الكشف لقاعدة تسمية CARO (النوع/المنصّة/اسم العائلة وغيرها). ↩

  15. Microsoft Learn, Address false positives/negatives in Microsoft Defender for Endpoint. حول فحص الملفّات المقدَّمة أوّلاً فحصاً فوريّاً بواسطة نظام آليّ، وإعطاء الأولويّة للملفّات ذات النطاق الواسع من التأثير وللطلبات المقدَّمة من حائزي Software Assurance ID، وتقديم MpSupportFiles.cab في حالة الكشف السلوكيّ، والتقديم الإداريّ ومؤشِّر «السماح»، والتوصية باستخدام Intune لتعريف الاستثناءات. ↩ ↩2 ↩3 ↩4 ↩5

  16. Microsoft Learn, Configure and validate exclusions based on file extension and folder location. حول الفرق بين استخدام Set-MpPreference (استبدال القائمة) وAdd-MpPreference (إضافة) وRemove-MpPreference (حذف)، وإمكانيّة تحديد ExclusionPath على مستوى الملفّ أو المجلّد (شاملاً المجلّدات الفرعيّة)، والتكوين عبر نهج المجموعة أو Intune وغيرهما، والتحقّق من الاستثناء عبر MpCmdRun، وإمكانيّة استمرار تنبيهات EDR أو أنواع كشف أخرى حتّى للملفّات التي أُضيف لها استثناء من مكافحة الفيروسات. ↩ ↩2 ↩3 ↩4

  17. Microsoft Learn, Configure exclusions for files opened by processes. حول كون ExclusionProcess يستثني «الملفّات التي تفتحها العمليّة المحدَّدة»، وأنّ استثناء العمليّة نفسها يتطلّب استخدام استثناء الملفّ (ExclusionPath). ↩

  18. Microsoft Learn, Common mistakes to avoid when defining exclusions. حول عدم جواز استثناء C:\ أو المجلّدات من نوع Temp، أو الامتدادات مثل .exe/.dll/.tmp، أو العمليّات العامّة مثل cmd.exe/powershell.exe/msbuild.exe، أو اسم ملفّ بلا مسار، وإمكانيّة أن يصبح عنصر الاستثناء مخبأً للتهديدات. ↩

  19. Microsoft Learn, Protect Dev Drive using performance mode. حول كون الافتراضيّ للحماية في الوقت الفعليّ هو الفحص المتزامن «open now, scan now»، وأنّ وضع الأداء يوفِّر فحصاً غير متزامن «open now, scan later» بحماية أعلى بكثير من استثناء المجلّد، وأنّه يعمل فقط على Dev Drive وفقط عند تفعيل الحماية في الوقت الفعليّ، ووجوب استخدام Performance Analyzer لاستكشاف أخطاء ارتفاع استخدام MsMpEng.exe (WinDefend، Antimalware Service Executable) للمعالج والذاكرة وإصلاحها. ↩ ↩2 ↩3 ↩4 ↩5

  20. Microsoft Learn, Set up a Dev Drive on Windows 11. حول كون Dev Drive وحدة تخزين للتطوير قائمة على ReFS، والتوصية بنقل شيفرة المشروع وذاكرة تخزين الحزم المؤقّتة ومخرجات البناء إليها، وكون وضع الأداء افتراضيّاً على Dev Drive الموثوق. ↩

  21. Microsoft Learn, Microsoft Defender Antivirus full scan considerations and best practices. حول كون الحدّ الأقصى لاستخدام الفحص للمعالج (ScanAvgCPULoadFactor) ليس حدّاً صارماً بل مؤشِّراً توجيهيّاً لمحرّك الفحص بألّا يتجاوز هذه القيمة في المتوسّط، وتطبيقه افتراضيّاً على الفحص المجدوَل (واختياريّاً على الفحص المخصّص أيضاً). ↩

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

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

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

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

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

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

قرّر Microsoft Defender أنّ التطبيق الذي طوّرته شركتنا فيروس. ماذا ينبغي أن أفعل؟
لا تندفع أوّلاً إلى إضافة استثناء أو تعطيل Defender. المسار الرسميّ للحلّ الدائم هو تقديم الملفّ عبر بوّابة تقديم عيّنات Microsoft Security Intelligence (ملف submission) بصفتك مطوّر برمجيّات (software developer). وإذا سجّلت الدخول يمكنك متابعة حالة الفحص، وإذا تقرَّر أنّه كشف خاطئ فسيتوقّف الكشف بعد تحديث التعريفات. أمّا الملفّات التي جرى حجرها فيمكن استعادتها من «سجلّ الحماية» في أمان Windows أو عبر الخيار `-Restore` في `MpCmdRun.exe`.
كيف أبلغ Microsoft عن كشف خاطئ؟
قدِّم الملفّ عبر بوّابة تقديم العيّنات الخاصّة بـ Microsoft Security Intelligence (microsoft.com/wdsi/filesubmission). يتطلّب التقديم تسجيل الدخول، ويمكن بعد التقديم متابعة حالة الفحص عبر البوّابة. تُفحَص الملفّات المقدَّمة أوّلاً فحصاً فوريّاً بواسطة نظام آليّ، ثمّ يحلّلها محلِّلون بشريّون عند الحاجة. قدِّمها بصفتك مطوّراً، وإذا لم تقتنع بالنتيجة يمكنك طلب إعادة التحقيق عبر نموذج الاتّصال الخاصّ بالمطوّرين المرفَق بنتيجة التقديم.
هل من المناسب أن نطلب من العميل إضافة استثناء في بيئته؟
هذا خيار وارد كإجراء مؤقّت حتّى تظهر نتيجة الإبلاغ عن الكشف الخاطئ، لكن لا يجوز جعله حلّاً دائماً. الاستثناء إعداد يفتح ثغرة في حماية Defender، وتذكر Microsoft نفسها صراحةً وجوب «استخدامه باعتدال»، و«قصره على مشكلة محدّدة»، و«مراجعته دوريّاً». وإن أُضيف، فحصره في أضيق نطاق كالمسار الكامل للملفّ التنفيذيّ، مع ترك سجلّ بمن أضافه ولماذا وحتّى متى، وإزالته بمجرّد حلّ الكشف الخاطئ. أمّا الاستثناءات الواسعة كمجلّد كامل، أو `C:\Temp`، أو امتداد `.exe`، فهي أشبه بتوفير مخبأ للبرمجيّات الخبيثة.
هل يزول الكشف الخاطئ إذا وقّعتُ الشيفرة (code signing)؟
لا ضمان لذلك، لكنّه يُحدِث أثراً كبيراً. لا تقدّم Microsoft برنامجاً للتسجيل المسبَق في قائمة معروفة يمنع الكشف الخاطئ، بل توصي بدلاً من ذلك بـ«الاستمرار في التوقيع بشكل ثابت عبر شهادة من مرجع تصديق جذر موثوق». فوجود توقيع ثابت يتيح لفريق التحقيق تحديد مصدر البرنامج بسرعة، وقد يُسرِّع إضافته إلى قائمة معروفة. وبالمقابل، فإنّ الملفّات الثنائيّة غير الموقَّعة أو التي لا يوجد فيها أثر ثابت للمصدر بين إصدار وآخر تُشتبَه بها من الصفر في كلّ مرّة بوصفها ملفّات مجهولة بلا سجلّ سابق.

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

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

غو كومورا

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

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

تواصل معنا

روابط عامة

GitHub LinkedIn X COM_BLAS COM_BigDecimal
العودة إلى المدونة