How do antivirus softwares conflict with each other?
Plain antivirus scanners can coexist without any issues. It's the live protection that can cause AVs to interfere.
AV software with live protection features deeply integrates itself into operating system. It patches some of OS code so that it can observe whatever programs attempt to do and prevent them from doing so, if necessary. Operating systems don't provide such capabilities out-of-the-box, so AVs use less conventional methods to achieve this effect.
For example, it can replace the "write file" function that OS provides with its custom one. When a program attempts to write to a file, it will call the "write file" function. But the function was patched by AV and program's request will be redirected to AV instead. AV will inspect it and decide if it looks OK. If it does, it will call actual "write file" function. Otherwise, it will take appropriate action to prevent malicious software from doing any damage.
Unfortunately, patching of OS code is not only necessary for AVs, but also suspicious. If you were creating a virus, wouldn't you also like to be able to intercept system operations, for example to prevent AV from scanning virus files?
So AVs have guards that watch if their code hooks are still in place and reinstalls them if necessary. At this point you should see where this is going...
Two AVs with live protection can start to protect you from each other's suspicious behavior. This can cause anything from minor performance hiccups to system crashes.
In some cases, even AV scanners without live protection can interfere. How do AVs detect viruses? Well, they have their virus signatures, ie. databases of distinctive features of known viruses. And so it happens that such database can also appear suspicious, because, well, they have distinctive features of viruses. So one AV could hypothetically detect other AV's signatures as malicious code.
There are also AV engines designed to coexist with other AVs, for example Hitman Pro. ClamWin (which is free and open-source) should also be relatively issue-free when coexisting because it contains only a scanner without any live protection.
Programs conflict when they both attempt to use the same resource. When multiple programs attempt to operate on a resource at the same time, there is a risk of Concurrency Problems. Concurrency problems occur when one process performs a change on the resource, and the other program (which was in the middle its own modification to the resource) is unaware of it, and thus unable to accommodate.
Here are a few examples of text book concurrency issues.
Last-in-Wins Problem
Imagine you are using an FTP directory to share a document where you and a colleague are collaborating on a document. you download the document, edit it, and post it again, as does your colleague.
- You download the document, and start a set of changes that takes 1 hour.
- Your colleague downloads the document at the same time you did, but only takes half an hour to complete and reupload their changes.
Result: when you upload your document, you overwrite their changes and they are lost.
Stale Data
In the same scenario, your colleague makes some changes that you need, without telling you. your copy of the file doesn't have the changes,
Result: You write the same changes in slightly different words yourself, or worse, fire off a nasty email about how its missing.
This seems like a simple scenario, but in advanced cases like multi-access databases if you select records at the same millisecond someone is updating them, you can experience serious issues.
Bad computation
A married couple have a shared bank account and ATM cards. They have 1000USD in their account. In their daily life, they are on opposite sides of town, and both access the ATM at the same instant. They both withdraw 1000USD. The ATMs both know that the balance is 1000, so they allow the withdrawl, and then write back to the central database that the new balance is 0.
Result: the bank is now out 1000USD, and doesn't even know it.
In all these examples there were multiple parties that were performing actions on a shared resource at or at about the same time. Hence the terms "concurrency" or "Synchronicity".
Solutions
There are a few ways to deal with these kinds of issues. One is to use software that arbitrates between the multiple parties accessing the resource. These arbiter programs have two options, depending on the scope and predictability of the operations:
- Merge the operations intelligently
- Block/lock one of the two operations until the first that is noticed is complete.
It is also possible to block/lock, provided that both programs are designed to check a shared flag indicating the state of the resource. this generally requires custom development.
Your Answer
In your specific case, The resources are the files on your disk. The Synchronicity comes from events like file Read/Write, which trigger on-access scans in both AV programs.
Windows acts as an arbiter to resolve filesystem concurrency issues by locking files when programs open them for specific operations.
This means that both programs are racing to access the file, and whoever gets there first gets the lock. At a low level, this results in some disk thrashing as both programs begin their own I/O activities, forcing the hardware to do both tasks separately, yet interleaving the IO instructions, making both much less efficient, and in the end, only one of them will win. the other will spin and wait to be able to establish their own lock.
Both inspection processes compete with each other to examine drive and network I/O.
It bogs the CPU and no advantage is gleaned since most AV manufacturers collectively share signatures so neither will detect malware before the other is updated to do so.
A single, well known and industry accepted AV will adequately guard your system even if you have reckless habits prone to infection and just as effectively as simultaneously using 10 AV products.