小村软件有限公司
联系我们
菜单

当自研 Windows 应用被 Microsoft Defender 判定为病毒 ── 误报处理与性能影响应对指南

· 更新日期: · · Microsoft Defender, 杀毒软件, 误报, 代码签名, SmartScreen, 应用分发, 安全, C#, .NET, Windows开发, 技术咨询

「客户那边说，我们的应用被当成病毒删掉了。」── 只要在分发自研或承接开发的 Windows 应用，迟早会接到这样的联系。前一天还运行正常的业务应用，会因为 Defender 的定义更新而突然被隔离。开发机上什么都没发生，却唯独在客户环境中被检测出来。明明从未写过任何恶意代码。

这并不是罕见的事故。现代杀毒软件不仅通过「是否与已知恶意软件一致」来判断，还会结合机器学习、行为分析、云端信誉（reputation）来推测「可疑程度」，因此没有任何使用记录的正规二进制文件被怀疑，是这套机制在设计上就无法避免的结果。而在应对误报时，可以做的事（向 Microsoft 报告误报、设置有限范围的排除）与绝不能做的事（禁用杀毒软件、设置大范围排除）之间有着明确的界限。

本文将从开发者的视角，梳理误报产生的机制、分发前可以做的预防措施、被检测到时的正规处理路径、作为客户环境应急处理手段的排除设置及其风险，以及另一个常见问题 ──「Defender（MsMpEng.exe）占用过高」的应对方式。

1. 先说结论

  • 即便是正规应用，也可能发生误报。Defender 自 2015 年起，已从以静态特征码为中心的引擎，转向使用机器学习与云端保护的预测型模型，因此即便未知文件与已知恶意软件不一致，也会依据「可疑程度」被判定。12
  • 永久性对策的正规途径，是向 Microsoft 提交文件申请（误报报告）。通过 Microsoft Security Intelligence 的样本提交门户，以开发者身份提交文件并跟踪判定结果。如果对判定结果有异议，可以通过开发者联系表单申请复查。34
  • 被隔离的文件可以恢复。可以从 Windows 安全中心的「保护历史记录」中恢复，也可以在命令行使用 MpCmdRun.exe -Restore 恢复。5
  • 排除设置是「在报告结果出来之前的临时对策」。排除会造成保护上的漏洞（protection gap），Microsoft 明确要求「谨慎使用」「仅用于特定问题」「定期复查」。如果确实需要设置，应限定为完整路径指定的最小范围，并留下记录。6
  • 预防的核心是保持一致的代码签名。Microsoft 并没有提供用于防止误报的预先登记程序；持续使用可信根证书颁发机构签发的证书进行一致的签名，才是官方推荐的加快查明来源、进入已知名单的方法。4
  • 发布前自行扫描，并提前提交样本，可以减少「零使用记录」的问题。可以用 MpCmdRun.exe 的自定义扫描来检查分发物，Microsoft 官方也说明，提前提交未知文件是开始建立信誉（reputation）的一种手段。78
  • 「Defender 占用过高」首先要做的是测量。使用 Performance analyzer（New-MpPerformanceRecording / Get-MpPerformanceReport）先确定是哪些文件、哪些进程构成了扫描负载的核心，再考虑对策。排除设置在这里同样是最后手段。910

2. 为什么正规应用会被当作病毒

如果仍然停留在「杀毒软件=与已知病毒模式（特征码）进行比对」这种理解上，误报现象会显得难以理解。但现代的 Defender 已经不是这样运作的了。Microsoft 明确表示，2015 年已经从基于静态特征码的引擎，转向使用机器学习、应用科学、AI 等预测技术的模型。1

检测是分多层进行的。在终端本地会运行轻量级机器学习模型、行为分析与启发式检测；终端自身无法判定黑白的文件，其元数据会被发送到云端保护服务，多数情况下能在毫秒级返回判定结果。若仍无法判定，则会请求提交文件样本，在云端进行扫描、引爆（在隔离环境中执行）与大数据分析。在启用了「首次检测即拦截（block at first sight）」的环境中，甚至会在云端判定返回之前，暂时阻止文件被打开。211

这套机制的含意很明确：判定所依据的材料不仅包括「与恶意软件的一致性」，还包括「无害的使用记录」。Microsoft 的分类标准中明确列出了「Unknown（未识别的软件）」这一类别，针对未知、下载记录较少的程序发出的警告，被定位为「尚未被检测到的恶意软件的早期预警系统」。并非所有罕见的程序都是恶意的，但对普通用户而言，未知类别本身的风险较高 ── 这是官方给出的整理。8

也就是说，刚刚发布的自研应用，在 Windows 安全机制看来，就是「全世界还没有任何人运行过、零使用记录的二进制文件」。在此基础上，如果再叠加以下特征，嫌疑就会进一步加深。

  • 隐藏代码实体的结构。Microsoft 的恶意软件分类中有一类叫做「Obfuscator（混淆器）」，指隐藏代码与意图、使检测变得困难的软件；而积极规避安全产品检测的软件，也被归类为潜在有害应用程序（PUA）的一种。混淆工具、自解压格式，以及把运行时打包进单一 exe 的打包方式，在外形上很难与恶意软件常用的结构区分开来，是即便是正规应用也容易招致警惕的领域。8
  • 没有签名，缺乏追溯来源的线索。如下一章所述，一致的签名是调查方用来确定来源的主要线索。4
  • 安装程序捆绑了其他软件。安装非同一开发商的软件，或安装运行本不需要的软件的行为，会被归为 PUA 分类中的「Bundling software（捆绑软件）」。8

另外，下载完成后立即出现的蓝色警告「Windows 已保护你的电脑」，与 Defender 杀毒检测是不同的机制（Microsoft Defender SmartScreen）。Microsoft 面向开发者的官方 FAQ 中也明确指出，SmartScreen 与 Defender 杀毒软件无关。4 关于 SmartScreen 与信誉的话题，我们在《为什么 Windows 会显示”Windows 已保护你的电脑”》一文中有详细整理，请先分清自己遇到的究竟是哪一种警告。

3. 分发前可以做的预防

3.1. 保持一致的代码签名 ── 不存在预先登记程序

「为了不被误报，能不能提前在 Microsoft 的白名单上登记」── 这是很自然的想法，但答案是不能。Microsoft 不接受开发者提出的已知名单登记或误报防止程序的申请。取而代之的是，官方 FAQ 建议：持续使用可信根证书颁发机构签发的证书，对程序的所有文件保持一致的签名。一致的签名能让调查团队迅速确定程序的来源，并应用以往积累的认知，从而有可能让程序更快被加入已知名单；虽然频率较低，但证书本身有时也会被加入受信任发布者名单。4

反过来说，签名的效果在于把「按文件计算的使用记录」汇聚成「按发行者计算的使用记录」。每次构建哈希值都会变化的可执行文件，单从文件层面看，每次都是「第一次出现的文件」；但只要用同一份证书签名，来源就能保持连续。签名的具体实践（证书类型、Azure Artifact Signing、时间戳）请参考上述 SmartScreen 文章，以及《Windows 应用开发安全最低限度检查清单》。

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，但作为门禁使用时容易被忽视的一点是，0 不仅代表「未检测到」，也包括「检测到但已成功修复」。如果只用原始的 -Scan，可能出现最糟糕的组合：Defender 检测到了发布产物并已完成隔离，但返回值仍然是 0，以「干净」的状态通过了流水线。在自定义扫描中应加上 -DisableRemediation，使检测时不进行处置（检测结果会显示在命令输出中），并且门禁判定不能只依赖「返回值为 2 就停止发布并排查」，还要包含检查命令输出中是否有检测记录、以及确认产物文件是否完整这两项。7

3.3. 提前提交未知文件

Microsoft 明确表示，提交未知或可疑软件的样本「有助于让其接受系统扫描，并开始建立信誉」。8 也就是说，样本提交门户不仅是被检测到之后才会用到的救急手段，同时也是一种预防手段 ── 为零使用记录的新二进制文件积累最初的使用记录。在重大发布（主版本升级、打包方式变更、引入混淆工具等外部形态发生较大变化的时机）之前提前提交样本，是值得投入的做法。

4. 被误报时的正规处理路径

4.1. 首先确认事实 ── 保护历史记录与事件日志

首先要确认「消失了」「无法启动了」这类反馈，是否真的是由 Defender 检测所致。在图形界面中，Windows 安全中心的「病毒和威胁防护」→「保护历史记录」中会保留检测和隔离的记录，也可以按被隔离的项目进行筛选查看。5

如果想留存为日志，或需要远程确认，可以查看事件日志。Defender 的事件记录在「应用程序和服务日志 → Microsoft → Windows → Windows Defender → Operational」中，也可以用 PowerShell 的 Get-WinEvent 获取。12 检测本身会记录为事件 ID 1116（检测到恶意软件或潜在有害软件），针对它采取的隔离等处置则记录为 ID 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 因误报而更新定义，该文件此后就不会再被检测到。反过来说，只要不报告，即使用排除设置勉强应付过去，在其他客户环境中依然会持续被检测。另外，即使是不留下文件的行为检测，也有相应的提交渠道：可以提交由 MpCmdRun.exe -GetFiles 生成的诊断文件（MpSupportFiles.cab），请求分析。157

如果客户所在的组织部署了 Microsoft Defender for Endpoint（EDR），还有一条管理员路径：由客户方的安全管理员从 Microsoft Defender 门户的提交（Submissions）页面提交，同时使用「允许」指示器在组织内部抑制该误报。15 这种情况下不要只靠自己一方处理，应与客户的 IT 部门协作。

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. 被其他厂商杀毒软件检测到时

如果不是被 Defender，而是被 EDR 或其他厂商的杀毒产品检测到，向 Microsoft 报告是无法解决的。需要针对检测到该情况的产品，分别向对应厂商的误报提交（false positive submission）渠道单独申请。多数厂商都提供专门的表单，可以用「厂商名 + false positive submission」搜索找到对应入口，并与 Defender 的情况一样，附上检测名称、文件与签名信息进行申请。如果多款产品同时检测到，也可以作为怀疑构建侧存在问题（混淆、打包器、捆绑内容）的依据。

5. 客户环境中的应急处理 ── 排除设置及其风险

5.1. 排除设置的定位 ── 并非永久对策

在等待误报报告判定结果期间，如果客户的业务因此停滞，Defender 的排除（exclusion）设置就会成为应急处置手段。但绝不能弄错它的定位。正如 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 或组策略（计算机配置 → 管理模板 → Windows 组件 → Microsoft Defender 杀毒软件 → 排除项）进行集中管理，而不是逐台终端手动设置。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）。同名的恶意软件无论放在哪里都会被一并排除，因此务必使用完整路径指定。

总结来说，排除设置应做到「使用完整路径、最小范围、留有记录、设定期限」。设置排除的事实和原因，应与客户方的 IT 管理员共享，一旦确认误报报告已有判定结果、且不再被检测，就应立即撤除。

6. 与性能影响相处 ──「MsMpEng.exe 占用过高」

与误报并列的另一个常见问题是性能。症状表现为：任务管理器中 MsMpEng.exe（Antimalware Service Executable）占用大量 CPU，应用的文件输出或构建速度变慢。MsMpEng.exe 是 Defender 杀毒软件的服务本体，实时保护的默认行为是「文件被打开的那一刻同步进行扫描（open now, scan now）」。19 大量频繁打开和关闭小文件的工作负载 ── 构建过程、细碎的日志写入、大量使用临时文件 ── 扫描次数会随之增加，其结构决定了它更容易受到影响。

6.1. 首先测量 ── Performance analyzer

在从「太卡了，直接排除」跳过去之前，应先测量究竟哪些内容构成了扫描负载的核心。Defender 提供专门的 Performance analyzer，可以用 PowerShell 的 New-MpPerformanceRecording 采集扫描性能记录（ETL），再用 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，以下这类设计调整可以直接减少扫描次数本身。

  • 将打开和关闭数千个小型中间文件的处理，整合为对少数文件的追加写入，或改为内存内处理
  • 减少反复「写入临时文件后重命名、删除」的模式
  • 不再逐行打开关闭日志文件，而是保持流处于打开状态进行写入

要实际测量哪个进程以何种频率访问了哪些文件，Process Monitor 可以直接派上用场。具体步骤请参考《Process Monitor（ProcMon）实战指南》。

6.3. 开发机可使用 Dev Drive 的性能模式

在「开发机构建速度慢」这一场景下，Windows 11 的 Dev Drive + 性能模式 是首选方案。在 Dev Drive（基于 ReFS 的开发专用卷）上，Defender 的实时保护会以异步的「性能模式」运行。它不再在文件打开时同步扫描，而是采用「先打开，稍后扫描（open now, scan later）」的方式，在文件打开完成后延迟进行扫描；官方将其定位为：相比彻底停止扫描的文件夹排除等手段，能在保持大幅更高保护水平的同时改善性能。19 将源代码树、包缓存、构建输出迁移到 Dev Drive 上，是常规做法。20

不过，性能模式只在 Dev Drive 上运行，并且要求实时保护处于启用状态。此外，「MsMpEng.exe 的 CPU / 内存占用过高」这类症状并不属于性能模式的应对范围，遇到这种情况，官方建议使用前述的 Performance analyzer 来锁定占用高的进程与路径。19

另外，如果按需扫描（定期全盘扫描等）在业务时段造成负担较大，MpCmdRun.exe -Scan 还有一个 -CpuThrottling 开关值得了解。启用后，会对扫描的 CPU 使用率设置上限（默认 50%）。7 但它并不是可以通过给开关传递数值来指定任意百分比的形式。上限值本身是通过策略设置（ScanAvgCPULoadFactor）来配置的，这个值并非硬性限制，而是给扫描引擎的一个目标：「平均不超过这个比例」。21

7. 判断表 ── 按症状分类的应对措施

情况 首先要做的 永久性对策
自研构建刚完成后，在开发机或 CI 上被检测到 通过保护历史记录、事件日志（1116/1117）确认检测名称与路径13。检查构建的变化点（混淆、打包器、捆绑内容） 以开发者身份提交至样本提交门户3。重新审视签名体制。将发布前扫描纳入 CI
在客户环境中被检测、隔离 确认检测名称、文件、是 Defender 还是其他厂商产品。提交误报报告；若业务停滞情况严重，应在与客户 IT 部门达成一致后设置完整路径排除并恢复文件5 确认判定结果确定且定义已更新后撤除排除。部署 EDR 的客户可同时使用管理员路径（门户提交、允许指示器）15
被其他厂商杀毒软件检测到 向客户获取检测到的产品名称、版本、检测名称 向该厂商的误报报告渠道提交申请。若多家厂商同时检测到，应怀疑构建侧存在问题
出现「Windows 已保护你的电脑」（SmartScreen） 确认这不是病毒检测（与 Defender 的检测是不同的机制）4 完善代码签名与分发渠道（参见SmartScreen 相关文章）
Defender（MsMpEng.exe）占用过高、I/O 变慢 使用 Performance analyzer 测量，锁定占用高的文件与进程9 改善应用的写入模式。开发机使用 Dev Drive + 性能模式19。排除设置作为最后手段，限定最小范围6

无论哪种情况，共通点都是三点：「首先确定事实（检测名称、对象、检测产品）」「务必启动报告这一永久性对策」「排除与恢复作为临时对策，限定最小范围」。

8. 总结

  • 现代的 Defender 并非依靠特征码比对，而是通过机器学习、云端保护、使用记录（信誉）进行判定。零使用记录的新二进制文件被怀疑，是这套机制在设计上的必然结果；混淆、自解压这类「隐藏实体」的结构，更容易招致怀疑。
  • 预防的核心是使用可信证书颁发机构签发的证书进行一致的代码签名。不存在通过预先登记来防止误报的程序。发布前用 MpCmdRun.exe 自行扫描，以及在外部形态发生较大变化的发布中提前提交样本，同样有效。
  • 一旦被检测到，应通过保护历史记录与事件日志（ID 1116/1117）确定检测名称与对象，并以开发者身份提交至 Microsoft Security Intelligence 的样本提交门户。被隔离的文件可以从保护历史记录中恢复，或使用 MpCmdRun.exe -Restore 恢复。
  • 排除设置是在报告判定结果出来之前的临时对策。应使用完整路径、最小范围，留有记录，解决后予以撤除。排除临时文件夹、扩展名或通用进程都是严格禁止的，因为这会为恶意软件创造藏身之所。
  • 性能问题应首先用 Performance analyzer 测量，考虑改善应用侧的写入模式，以及使用 Dev Drive 的性能模式，只有在这些手段仍不够时，才考虑有限范围的排除设置。要求客户禁用实时保护是绝对不能考虑的选项。

相关文章

相关咨询领域

合同会社小村软件（合同会社小村ソフト）承接以下相关咨询：梳理已分发应用的误报、SmartScreen 警告应对方针，设计包含代码签名在内的分发与更新体制，以及对杀毒软件导致的性能问题进行测量与排查。

参考链接

</content>

  1. Microsoft Learn, Microsoft Defender Antivirus in Windows Overview. 关于 2015 年从基于静态特征码的引擎转向使用机器学习、应用科学、AI 的预测型模型，以及异常检测与基于行为的保护。 ↩ ↩2

  2. Microsoft Learn, Cloud protection and sample submission at Microsoft Defender Antivirus. 关于终端本地的机器学习模型、行为分析与启发式检测，向云端保护发送元数据（多数情况下毫秒级返回判定），以及样本提交、引爆与大数据分析的多层结构。 ↩ ↩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 使检测时不进行处置并在命令输出中显示结果、-CpuThrottling 默认值为 50）；-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 事件日志的位置（应用程序和服务日志 → Microsoft → Windows → Windows Defender → Operational）以及使用 Get-WinEvent 获取的方法。 ↩

  13. Microsoft Learn, Review event logs and error codes to troubleshoot issues with Microsoft Defender Antivirus. 关于事件 ID 1116（检测）与 1117（隔离、删除等处置）等 Defender 事件 ID 一览。 ↩ ↩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）的高 CPU / 高内存问题。 ↩ ↩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. 关于扫描的 CPU 上限（ScanAvgCPULoadFactor）并非硬性限制，而是给扫描引擎的一个「平均不超过该比例」的目标值，以及默认应用于计划扫描（也可选应用于自定义扫描）。 ↩

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

我自己开发的应用被 Microsoft Defender 判定为病毒，应该怎么办？
首先请不要慌张地直接设置排除项或禁用 Defender。永久性对策的正规途径，是通过 Microsoft Security Intelligence 的文件申请门户（样本提交），以开发者（software developer）身份提交文件。登录账号后即可跟踪申请的判定状态；一旦被判定为误报，通过定义更新，该文件此后就不会再被检测到。已被隔离的文件，可以从 Windows 安全中心的「保护历史记录」中恢复，也可以使用 MpCmdRun.exe 的 -Restore 恢复。
应该如何向 Microsoft 报告误报？
可以通过 Microsoft Security Intelligence 的样本提交门户（microsoft.com/wdsi/filesubmission）提交文件。提交需要登录账号，提交后可以在门户上跟踪判定状态。提交的文件首先会由自动系统立即扫描，必要时会有分析师进一步分析。以开发者身份提交，如果对判定结果有异议，可以通过申请结果中附带的开发者联系表单申请复查。
在客户环境中设置排除项是否合适？
作为在误报报告结果反映出来之前的临时对策，可以作为一种选择，但绝不能将其作为永久性对策。排除是一种会在 Defender 保护上开出漏洞的设置，Microsoft 官方明确要求「谨慎使用」「仅用于特定问题」「定期复查」。如果确实要设置，应限定为可执行文件的完整路径等最小范围，并留下谁、为何、截止到何时的记录，误报解决后应予以撤除。像整个文件夹、C:\Temp，或 .exe 这样的扩展名等大范围排除，等同于为恶意软件制造藏身之所。
进行代码签名就能消除误报吗？
不能保证完全消除，但效果显著。Microsoft 并未提供类似预先登记到已知名单这样的误报防止程序，而是推荐「持续使用可信根证书颁发机构签发的证书进行一致的签名」。有了一致的签名，调查团队就能迅速确定程序的来源，有时可以加快加入已知名单的速度。反之，没有签名、每次构建都缺乏来源线索的二进制文件，每一次都会被当作没有使用记录的未知文件从零开始被怀疑。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。

联系我们
返回博客列表