Windows-Defender and Visual-C++ development: Exclude Executables/Processes xor data folders?
Asked Answered
E

0

2

This may be specific to Windows Defender, or it may be more generally applicable to more AV products on Windows.

What it definitely is specific to is "compiled" Application development, hence I'm asking here, there should be a pretty clear technical explanation to this.

It would appear to be "obvious" (1 2) that Antivirus Software on Windows put the spanner in the works of esp. C++ compilation -- what is much less obvious to me is what is needed to be excluded from Real-Time Scanning.

You get told from different resources on the Web, that you should exclude you project folders and your devenv.exe, cl.exe, node.exe ... what-have-you.

However, these instructions seem a bit contradictory to me, at least as far as directory excludes vs. process excludes go:

Q: If I tell my AV to not scan stuff used by process devenv.exe|cl.exe|..., then why on earth would I need to also exclude my, e.g. C:\mystuff\cpp-project\** project folders?

Q: Shouldn't a process exclusion of an AV product, that greps all relevant development tools be more than sufficient to speed up build times?

Q: Why would additional do-not-scan-directory exclusions be necessary? Are they necessary?


Disclaimer: I would just blanket exclude "the world" on my dev machine and be done with it. This, however, does not sit well with IT and the security team. They want to control the excludes, and they are -- somewhat justifiably -- reluctant to blanket exclude any folder where a non-admin user has write rights, like would be the case for a project folder or the user's TEMP folder.

Eruptive answered 23/12, 2020 at 11:44 Comment(3)
imo the exlclude for procesess (devenv.exe / cl.exe / ..) is probably not enough to circumvent additional slowdowns b/c AV will still try to 'hook' each fopen/whatever syscall in a particular folder, even if it backs up later b/c the accessing process is 'trusted', excluding folders gives you the option to save the time it takes to match the process accessing the FS with a given whitelist .. probablyRemark
@Remark - but but but but: the FS hook of the AV needs to run anyway. Shouldn't matter whether it needs to compare path or process name, now should it?Eruptive
that probably depends on the implementation -> if the FS hook automagically knows which process is doing the syscall, then yes, there should be no difference. but but but but if a process-lookup is required in addition to that ... well, that'd be 'sub-optimal'Remark

© 2022 - 2024 — McMap. All rights reserved.