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

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

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

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

المقال طويل، لذلك نعرض أوّلاً مداخل بحسب الوضع. إن كنت من تقنية المعلومات أو الدعم وتحتاج إجراءً فوريّاً أثناء التعامل مع عميل، فابدأ من الفصل 4 (المسار الرسميّ) والفصل 5 (طريقة إضافة الاستثناء ومخاطره). وإن كنت مطوّراً تريد الوقاية من الكشف الخاطئ لتطبيق ستوزّعه، فابدأ من الفصل 3. وإن وصلتك استشارة «Defender بطيء»، فابدأ من الفصل 6. وجدول الأعراض السريع في الفصل 7.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 أوقف الشحن وابدأ التحقيق» — التحقّق من وجود كشف في مخرجات الأمر ومن عدم فقدان أيّ ملفّ من ملفّات المخرجات.⁷

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

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

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

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

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

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

# Defenderの検知(1116)と処置(1117)のイベントを新しい順に確認
# 絞り込みはイベントログ側で行う(-FilterHashtable)。パイプの後ろのWhere-Objectより速い
Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-Windows Defender/Operational'
    ID      = 1116, 1117
} -MaxEvents 10 |
    Select-Object TimeCreated, Id, Message

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

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

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

لأنّ أوّل استخدام يسهل فيه التيه، نرتّب هيكل الخطوات في حدود ما تذكره الوثائق الرسميّة.³⁴¹⁵

1. سجِّل الدخول. لا يمكن التقديم عبر بوّابة العيّنات دون تسجيل دخول. ومن 20 مايو 2024 انتقل تسجيل الدخول في هذه البوّابة إلى Microsoft Entra ID. إذا كان مستأجر المؤسّسة مضبوطاً بحيث يحتاج موافقة المسؤول، فاطلب من مسؤول تقنية المعلومات منح إذن الوصول إلى التطبيق المعنيّ.
2. ارفع الملفّ الذي كُشِف خطأً. واكتب بالتفصيل المنتج الذي كنت تستخدمه (مثل Microsoft Defender Antivirus) والظروف التي وصلت فيها إلى ذلك الملفّ. فالمعلومات التي تكتبها هنا تصبح مادّة التحليل كما هي، لذلك أرفق اسم الكشف ومسار الملفّ وإصداره كما ثبّتها في 4.1.
3. اجعل صفة المقدِّم software developer (مطوّر برمجيّات). التقديم بهذه الصفة يُرفِق بنتيجة الطلب نموذج اتّصال موجَّهاً للمطوّرين إن لم تقتنع بالنتيجة.
4. إن كان لديك Software Assurance ID (SAID) فأدخله. تقبل البوّابة SAID، ويحصل العملاء ذوو SAID صالح على أولويّة أعلى. وإذا كانت شركة العميل هي الحائزة عليه، فقد يكون التقديم من طرف العميل أسرع.
5. بعد التقديم تابع الحالة من صفحة سجلّ الطلبات (microsoft.com/wdsi/submissionhistory). الحالات ثلاث: Submitted (استُلم) / In progress (بدأ محلِّل المراجعة) / Closed (صدر الحكم النهائيّ). وإذا أردت التحقّق ممّا إذا كان الحكم قد تحدّث، فاختر إعادة الفحص (rescan) من صفحة تفاصيل الطلب.
6. انتظر الحكم النهائيّ، واطلب إعادة التحقيق إن لم تقتنع. انتظر حتّى يُحسَم القرار، وإذا لم تقتنع بالنتيجة فتواصل مع Microsoft عبر نموذج الاتّصال الخاصّ بالمطوّرين المرفَق بنتيجة التقديم.

أسماء عناصر الشاشة وترتيبها قد تتغيّر، فإن تِهْتَ فارجع إلى إرشاد الوثائق الرسميّة. وتُفحَص الملفّات المقدَّمة أوّلاً فحصاً فوريّاً بواسطة نظام آليّ، وإذا كان الملفّ قد عولِج مسبقاً يصدر القرار سريعاً. أمّا الطلبات غير المعالَجة، فتُحلَّل مع إعطاء أولويّة للملفّات ذات النطاق الواسع من التأثير، وللطلبات المقدَّمة من عملاء المؤسّسات الحائزين على Software Assurance ID.¹⁵

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

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

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

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

rem 隔離されている項目の一覧
MpCmdRun.exe -Restore -ListAll

rem 隔離時のファイルパスを指定して元の場所へ復元
MpCmdRun.exe -Restore -FilePath "C:\Program Files\Contoso\ContosoApp\ContosoApp.exe"

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

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) مراجعته دوريّاً مع الاحتفاظ بسجلّ يوضّح لماذا كان هذا الاستثناء ضروريّاً.⁶ ويُشار إلى أنّ الاستثناء الذي نشرحه هنا هو استثناء من فحص مكافحة الفيروسات في Defender (المجدوَل/عند الطلب/الحماية في الوقت الفعليّ). وفي البيئات التي اعتُمِد فيها Microsoft Defender for Endpoint، قد تستمرّ تنبيهات EDR أو أنواع كشف أخرى في الظهور حتّى للملفّات المستثناة.¹⁶ وظهور «تنبيه رغم إضافة الاستثناء» ناتج عن هذه الخاصيّة، وليس خللاً.

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

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

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

# 管理者権限の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 على مستوى الملفّ أو المجلّد، لكن تحديد مجلّد يجعل المجلّدات الفرعيّة بأكملها مشمولة أيضاً، لذا فكِّر أوّلاً بمستوى الملفّ.¹⁶ أمّا -ExclusionProcess فهو خيار يسهل سوء فهمه من اسمه، إذ لا يستثني العمليّة المحدَّدة نفسها، بل يستبعد الملفّات التي تفتحها تلك العمليّة من نطاق الفحص. والتصنيف الرسميّ هو أنّه إذا أردتَ استثناء الملفّ التنفيذيّ للعمليّة نفسه فاستخدم -ExclusionPath.¹⁷ ففي الحالات التي يحدث فيها الكشف أو مشكلة الأداء بسبب فتح التطبيق كمّيّة كبيرة من ملفّات البيانات، استخدم -ExclusionProcess، وفي الحالات التي يُكشَف فيها الملفّ التنفيذيّ نفسه خطأً، استخدم -ExclusionPath.

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

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

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

• استثناء مجلّدات عامّة مثل 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)».¹⁹ بمعنى أنّه بنية يزداد فيها عدد مرّات الفحص، وتتأثّر بسهولة، كلّما زاد حِمل العمل الذي يفتح ويغلق كمّيّة كبيرة من الملفّات الصغيرة — كالبناء، والكتابة التفصيليّة للسجلّات، والاستخدام الكثيف للملفّات المؤقّتة.

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

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

# 管理者権限のPowerShellで実行

# 記録を開始し、重い操作(ビルド、バッチ処理など)を再現してからEnterで停止
New-MpPerformanceRecording -RecordTo .\Defender-scans.etl

# スキャン時間の上位ファイルと、そのファイルへのスキャン内訳を表示
Get-MpPerformanceReport -Path .\Defender-scans.etl -TopFiles 3 -TopScansPerFile 10

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

محتوى المخرجات يختلف كثيراً بحسب البيئة، لذلك نرتّب هنا ماذا يظهر وأين تنظر. وفقاً للوثائق الرسميّة، يتضمّن التقرير المعلومات التالية.⁹

تُرتَّب كلّ التقارير تنازليّاً حسب الزمن المستغرَق. ترتيب القراءة هو أن تبدأ بـ -TopFiles أو -TopProcesses لتنظر إلى المراتب العليا، فإذا ظهر مرشّح فتحت الفحوصات الفرديّة لذلك الملفّ عبر -TopScansPerFile. وإذا كثرت العناصر وصعب النظر، يمكن خفض الضوضاء بحدّ أدنى مثل -MinDuration 100ms.¹⁰ وإذا أردت معالجة السجلّ بأداة أخرى، يمكن إخراجه إلى CSV كالتالي.⁹

# スキャン単位の生データを上位1000件までCSVに出す
(Get-MpPerformanceReport -Path .\Defender-scans.etl -TopScans 1000).TopScans |
    Export-Csv -Path .\Defender-scans.csv -Encoding UTF8 -NoTypeInformation

الحكم بعد هذا النظر هو «هل ما في المراتب العليا من مخرجات تطبيق شركتك؟». إذا شغلت الملفّات المؤقّتة أو السجلّات الخاصّة بتطبيقك المراتب العليا، فانظر أوّلاً كما في 6.2 هل يمكن تقليلها من جانب التطبيق. وإذا كانت مخرجات البناء أو ذاكرة الحزم المؤقّتة على جهاز التطوير هي العليا، فإنّ Dev Drive في 6.3 ينفع. ولا يُنظَر في الاستثناء إلّا إذا تعذّر الحلّ بأيّ من الطريقين. وانتبه إلى أنّ الوثائق الرسميّة نفسها تنبّه إلى أنّ هذه الأداة لاكتساب رؤية حول الملفّات المشكِلة، وليست لاقتراح استثناءات.¹⁰

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

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

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

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

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

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

معرفة طريقة الإنشاء أيضاً تسهّل الحركة. تذكر الوثائق الرسميّة المتطلّبات والخطوات كالتالي.²⁰

• المتطلّبات: Windows 11 (الإصدار 10.0.22621.2338 فما بعده)، مساحة حرّة 50GB فما فوق (الحدّ الأدنى لحجم Dev Drive هو 50GB)، وذاكرة 8GB فما فوق و16GB مستحسَنة، وصلاحيّات مدير محلّيّ. وفي بيئة الشركات قد يلزم إعداد نهج مجموعة من مسؤول الأمان.
• الإنشاء عبر الواجهة: الإعدادات > النظام > التخزين > إعدادات التخزين المتقدّمة > الأقراص ووحدات التخزين، ثمّ اختر «إنشاء Dev Drive». يمكنك الاختيار من ثلاثة مسارات: إنشاء VHD جديد / تقليص وحدة موجودة / استخدام مساحة غير مخصّصة.
• الإنشاء عبر سطر الأوامر: بصلاحيّات مدير نفِّذ Format D: /DevDrv /Q (موجّه الأوامر/PowerShell) أو Format-Volume -DriveLetter D -DevDrive (PowerShell). وهذا أسهل عند النشر على عدّة أجهزة.
• تنبيه: لا يمكن تحويل وحدة تخزين قائمة إلى Dev Drive. تعيين Dev Drive لا يتمّ إلّا عند التهيئة، وإعادة تهيئة وحدة قائمة تمحو محتواها. كذلك لا يمكن جعل محرّك C: وحدة Dev Drive. الافتراض الرسميّ هو إبقاء أدوات التطوير وSDK على C:، ووضع شيفرة المصدر وذاكرة الحزم المؤقّتة ومخرجات البناء على Dev Drive.
• جعله موثوقاً: وضع الأداء لا يعمل إلّا على Dev Drive «موثوق (trusted)». عادة يصبح موثوقاً تلقائيّاً عند الإنشاء، وللتحقّق أو إعادة الضبط استخدم fsutil devdrv query D: وfsutil devdrv trust D: (عند نقل VHD إلى جهاز آخر مثلاً يلزم إعادة تعيين الثقة).

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

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

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

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

8. الخلاصة

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

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

• لماذا يظهر تحذير «قام Windows بحماية جهاز الكمبيوتر الخاص بك» في Windows
• تصميم أمان التحديث التلقائيّ - لماذا لا يكفي HTTPS وحده
• قائمة التحقّق الأدنى لأمان تطوير تطبيقات Windows
• كيفيّة اختيار طريقة توزيع تطبيقات Windows - MSI/MSIX/ClickOnce/xcopy/محدِّث خاصّ
• دليل عمليّ لـ Process Monitor (ProcMon) ── تحديد «الإعدادات لا تُقرأ» و«ACCESS DENIED» خلال 10 دقائق

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

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

• تطوير تطبيقات Windows
• الاستشارات التقنية ومراجعة التصميم
• التواصل معنا

روابط مرجعية

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

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

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

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

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

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

قرّر 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 برنامجاً للتسجيل المسبَق في قائمة معروفة يمنع الكشف الخاطئ، بل توصي بدلاً من ذلك بـ«الاستمرار في التوقيع بشكل ثابت عبر شهادة من مرجع تصديق جذر موثوق». فوجود توقيع ثابت يتيح لفريق التحقيق تحديد مصدر البرنامج بسرعة، وقد يُسرِّع إضافته إلى قائمة معروفة. وبالمقابل، فإنّ الملفّات الثنائيّة غير الموقَّعة أو التي لا يوجد فيها أثر ثابت للمصدر بين إصدار وآخر تُشتبَه بها من الصفر في كلّ مرّة بوصفها ملفّات مجهولة بلا سجلّ سابق.

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

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

غو كومورا

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

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