Many, many reports are made about various issues with the functionality of MO that can be attributed to an overly zealous AV package, or some other software that operates on a file without your consent.
- Whenever you see errors about missing files, or support functions not working, or "failed to spawn '[program name]': failed to start process (Access is denied. )" check to see that your AV package hasn't been messing with those before you ask here.
- Functions that seem to stall or hang entirely are usually because your AV package is stopping the system from operating on those files/folders by either interrupting the copy process or removing the copied file afterward.
- The running of tools used inside MO, or called from it (e.g. FNIS), have been hindered by these AV packages. Even seemingly unrelated errors about files that contain no executable code can be traced to AV behaviour.
As a matter of course, one of the first things to check when you experience problems is your AV package.
That is not to say these tools are broken or useless, though many are in fact next to useless, but rather the algorithms they use to determine "malicious" behaviour isn't clever enough to distinguish between what is and isn't "bad".
Most AV packages have the ability to set aside certain programmes or folders from the process so that they can operate unhindered, whichever package you use it is strongly urged that you examine how to do so with MO.
File backup software is also known to make file access errors with MO as the files that are being accessed, or tried to, are being actively checked by that sort of software. This will interfere with the 'hooking' code of MO.
All the code used by MO is freely available on the GitHub so there is no chance of malicious code being introduced into it. You are of course encouraged to check for yourself if you so desire.