为什么Windows Defender会延迟我们的软件启动？

Question

我正在尝试帮助SuperCollider社区理解如何防止最新的Windows 10上Windows Defender延迟一个可执行文件的执行。 原始github问题可以在github上找到。

以下是测试案例：

1. 下载Windows x64版的最新版本SuperCollider（3.10.3）

2. 安装它

3. 重启计算机

4. 打开"cmd"并启动scsynth.exe

cd "\Program Files\SuperCollider-3.10.3"
scsynth.exe -u 57110

你需要等待50到60秒才能看到scsynth的输出，其应该以某种形式开头。

Device options:
  - MME : Mappeur de sons Microsoft - Input   (device #0 with 2 ins 0 outs)
[...]
SuperCollider 3 server ready.

5. 请注意，如果您退出 scsynth.exe 并再次运行该命令，则 scsynth.exe 将立即启动，无需延迟。

6. 现在将 scsynth.exe 进程加入 Windows Defender 排除列表中（有关如何访问此排除列表的信息，请参见 this article）。

7. 重新启动计算机。

8. 打开“cmd”并启动 scsynth.exe。

cd "\Program Files\SuperCollider-3.10.3"
scsynth.exe -u 57110

现在scsynth.exe可以立即启动。

这种行为是在添加Windows Defender block at first sight功能时开始的。

这给SuperCollider Windows用户带来了很多问题。

有人能帮助我们解决这个问题吗？

- geoffroy

---

我曾经使用像Process Monitor（来自Sysinternals/Microsoft）这样的工具来调查类似的问题。它可以记录进程执行的所有I/O、注册表和进程/线程操作。比较两种情况的日志可以让你很好地了解其他程序可能会如何干扰。现在，我使用UIforETW通过ETW（Windows事件跟踪）来记录跟踪信息，然后使用Windows性能分析器进行分析。同样的交易，有更多细节可以深入挖掘。 - Adrian McCarthy

谢谢Adrian，我会尽力弄清楚这些工具发生了什么。 - geoffroy

不完全是这样。这是Windows Defender的一个众所周知的问题。在最近的SC版本中，他们已经添加了一个警告。它只会在第一次库类编译时发生。在我的机器上需要20秒，而重新编译只需要1-2秒。索引帮助文件也是如此。Windows Defender有一些特殊技巧，可以避免像这样的商业软件减速（即地狱白名单）。请参见关于Rust的讨论https://youtu.be/qbKGw8MQ0i8?t=2326。基本上，微软需要被温柔地请求将SC列入白名单。 - Fizz

感谢@fizz！我在最近的SC版本中添加了警告:)如果有人知道请求MS将SC添加到白名单的程序，我会加入！ - geoffroy

有一个有趣的发现，也许你可以确认一下...如果你下载了（64位）ZIP分发包（而不是EXE安装程序），并将其提取到非默认位置（即不是Program Files）和非系统驱动器上...那么Defender会愉快地忽略SC的编译操作，包括帮助文件和类，即使没有添加任何显式的排除项。 - Fizz

Answer 1

我猜你是希望从微软这里得到一个真正的答案，但这可能会在评论中被忽略，对于SC用户来说，这可能是有用的信息，因此：

经过更多的实践经验，当你从一个非系统位置运行SC时（即不要安装到Program Files，也许也不要安装到系统驱动程序），情况会稍微复杂一些。对于非系统位置，你仍然需要通过Defender进行扫描，启动速度会变得非常缓慢，但是每台机器只需要扫描一次。而如果将SC安装到Program Files中，则会在每个SClang进程启动时进行扫描（但不会在同一sclang进程运行时重新编译classlib），除非手动添加Defender例外路径。

根据我所知，上述情况仍然启用了“首次阻止”功能，因为微软表示：“要禁用首次阻止，请关闭云交付保护或自动样本提交。” 而我仍然启用了这两个功能。

因此，如果你不经常重启电脑，只是使用挂起/恢复，那么如果将SC安装到非系统位置，这并不是一个大问题...对于常规使用来说。它仍然为新的SC用户提供了一个不好的开箱体验，毫无疑问。

---

实际上，微软今天证明了上述理论有一些错误。我刚刚进行了一个Windows更新，使我的机器重新启动，所以我完全预计下一个SC启动会再次变慢......但它没有！因此，看来Defender保留了最近使用和扫描位置的持久缓存，这意味着它保存在磁盘上。那么，下一个问题是什么可能会使这个缓存失效。最后一次重新启动只是为了进行Windows月度更新，但它并没有包括Defender引擎或定义更新，因此我认为Defender缓存可能会在某些更具体的事件上失效，而不是任何重新启动。也许有一些直接基于时间或LRU条目到期的过期，但很难测试，因为Defender经常更新自己，从而创建了混淆因素。是的，在对后一个问题进行快速搜索后，Defender确实在磁盘上保留了与其先前扫描相关的一些信息的持久缓存。

当实时保护开启后，大约20-30分钟后，会在以下位置创建数百/数千个文件：C:\ProgramData\Microsoft\Windows Defender\Scans\History\Store。这些文件中大部分为1KB或2KB大小。在24小时内，我们最终得到了大约950,000个文件，占用了30GB的空间。 顺便说一下，那个Defender历史文件过多的问题已经解决了（2021年5月）。

“这个问题目前是一个已知的问题，修复将在本周四发布所有版本。造成这个文件夹中有大量文件的原因是MsMpEng.dll工程师存在一些问题。受影响的引擎版本是18100.5。”

但是某些扫描历史信息仍然保存在磁盘上，这在常规使用中可以很好地缓解重新扫描程序（如SC）的问题，尽管在刚安装SC时未进行任何操作时可能不适用。

---

附注：有点好笑，但是似乎Defender扫描减速有时会影响微软自己的产品。

在编程解决方案领域：

据我所知，只要 Windows Defender（和可能其他杀毒软件扫描器）正在运行，就无法使 Windows I/O APIs 保持一致的快速性。您可以禁用 A/V 扫描（自担风险）。但是，Mercurial 使用的技巧（后来被 rustup 和其他工具模仿）是使用线程池调用 CloseHandle()。即使您在单个线程上执行所有文件打开和写入 I/O，并仅在后台线程池中调用 CloseHandle()，您也可以看到将近3倍的加速时间来写入文件。任何在 Windows 上创建或更改少量文件的软件都应该理想地采用这种优化。这包括版本控制工具、安装程序和归档提取工具。有趣的事实是：由于采用了这种技巧以及其他技巧，rustup 可以在 Windows 上比开源和商业快速提取/复制工具更快地提取 tar 文件。我相信在 Windows 上，rustup 提取 tar 存档文件的速度实际上比在 Linux 上还要快！同时，rustup 的开发人员也有相关的 YouTube 演讲，例如 this one。

- Fizz