GEOFS
asked on
Are there updates to McAfee antivirus software that prevent VFP from accessing DBF files on Windows 7?
A VFP9SP2 program that had been running fine on several Window 7 workstations has suddenly stopped working after the workstations' McAfee antivirus software was updated. Right after starting up, the program checks for the existence of two files, a DBF and its associated FTP. The FILE() function returns false, even though the files are still right where they are supposed to be on the server, and the program still runs fine on some XP machines that were not included the update.
The issue was resolved on one machine by restoring the system to a point before the update was applied. The attached screenshot shows the McAfee files that were removed during the restore. While this is valuable as evidence that McAfee is the culprit, it is not an acceptable long-term solution; we need to be able to update the antivirus software.
Does anyone know what the McAfee update might be doing that would prevent the program from "seeing" those files?SystemRestoreList.rtf
The issue was resolved on one machine by restoring the system to a point before the update was applied. The attached screenshot shows the McAfee files that were removed during the restore. While this is valuable as evidence that McAfee is the culprit, it is not an acceptable long-term solution; we need to be able to update the antivirus software.
Does anyone know what the McAfee update might be doing that would prevent the program from "seeing" those files?SystemRestoreList.rtf
ASKER
Thank you for the tips. It was interesting to find out that FILE() actually tries to open the file rather than just looking for its presence. Does this mean that if one program has a file open exclusively, a FILE() issued by a second program would fail?
No, not at all. The FILE() opens the file with desired access "ReadAttributes" and this opening cannot be blocked by other users/processes. (ReadAttributes also has its own security context. You may see it as one of the rights in file properties.)
Possible explanation:
McAfee may (newly) evaluate this kind of opening as a possible threat (I cannot say why) so it behaves same way as if it was the standard file opening. Windows timeouts do not expect the delay caused by McAfee and the result is "File does not exist".
Possible explanation:
McAfee may (newly) evaluate this kind of opening as a possible threat (I cannot say why) so it behaves same way as if it was the standard file opening. Windows timeouts do not expect the delay caused by McAfee and the result is "File does not exist".
Any file access (including exclusive access) will also be forwarded to Minifilters by the OS, so any AV change can interfere with VFP, DBFs or any file.
I once studied Windows Filesystems and the Minifilter concept. Any antivirus software hooks quite low level into the file system and can watch and interfere with any file access.
The order in which Minifilters are notified of file operations and can inspect and influence them is organized in altitudes, which you can register from MS. Antivirus vendors can be found in the list of registered altitudes, see: http://msdn.microsoft.com/en-us/library/windows/hardware/dn265170%28v=vs.85%29.aspx
I'll not dive into the Minifilter principles, you might google that, if you're interested, The best way to keep antivirus from interfering with DBFs is to exclude either the file extension or a folder with your data from antivirus intervention. You'd surely not be able to convince any vendor of antivirus software to exclude a file type by default, as any file can be used or prepared to contain a virus, so that's no solution. It's also the reason, I'd recommend to rather exclude a folder than a file extension. While only executables can be used for viruses to be active, the virus definitiion to be spread by copies can also be stored to any file and just a stub of loading that part will then be injected into executables, Also viruses might write unsuspicious files called readme.txt, so no file extension should be made a virus scanning exception.
The configuration of AV scanning exceptions is kept very confidential from AV software, so viruses can't (easily) find out which folders or file extensions are not scanned. If a virus has enough permissions to get that info, he can already do more harm, eg administrative things. Yet, to exclude a folder does invite less risc about viruses hiding there than to generally exclude a file extension.
Also you don't have to be afraid of not catching a virus in your DBFs, as this will break the file structure, eg you'd see garbage in some records, also you can do full system scans despite of any scanning exceptions anyway.
Bye, Olaf.
I once studied Windows Filesystems and the Minifilter concept. Any antivirus software hooks quite low level into the file system and can watch and interfere with any file access.
The order in which Minifilters are notified of file operations and can inspect and influence them is organized in altitudes, which you can register from MS. Antivirus vendors can be found in the list of registered altitudes, see: http://msdn.microsoft.com/en-us/library/windows/hardware/dn265170%28v=vs.85%29.aspx
I'll not dive into the Minifilter principles, you might google that, if you're interested, The best way to keep antivirus from interfering with DBFs is to exclude either the file extension or a folder with your data from antivirus intervention. You'd surely not be able to convince any vendor of antivirus software to exclude a file type by default, as any file can be used or prepared to contain a virus, so that's no solution. It's also the reason, I'd recommend to rather exclude a folder than a file extension. While only executables can be used for viruses to be active, the virus definitiion to be spread by copies can also be stored to any file and just a stub of loading that part will then be injected into executables, Also viruses might write unsuspicious files called readme.txt, so no file extension should be made a virus scanning exception.
The configuration of AV scanning exceptions is kept very confidential from AV software, so viruses can't (easily) find out which folders or file extensions are not scanned. If a virus has enough permissions to get that info, he can already do more harm, eg administrative things. Yet, to exclude a folder does invite less risc about viruses hiding there than to generally exclude a file extension.
Also you don't have to be afraid of not catching a virus in your DBFs, as this will break the file structure, eg you'd see garbage in some records, also you can do full system scans despite of any scanning exceptions anyway.
Bye, Olaf.
Depending on the version of McAfee you have, it may have the ability the deny access to files based on a set of on access protection rules. These rules can be pretty strigent if whoever installed McAfee selected "Maximum Protection". You will need to look at the logfile produced to see if McAfee is preventing access. And if the logfile says it is blocking access, then you will need to look at the Virsuscan console to see and to change the settings that are preventing access. You can probably disable the on-accesss protection altogether, temporarily of course, to see if that is causing your issue. However I recommend looking at the log file and relaxing the rule that is causing the access failure, rather than disabling the on access scan altogether.
You should be able to find the logfile and the viruscan console both by right-clicking on the McAfee icon in your system tray.
You should be able to find the logfile and the viruscan console both by right-clicking on the McAfee icon in your system tray.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thank you for the info on McAfee. This situation is actually being handled by a group at my client's site who are responsible for supporting the network infrastructure. I passed along to them the suggestions about excluding the application folder or selected file types from McAfee's machinations, but I haven't had any feedback yet.
Thanks again for your comments.
Thanks again for your comments.
A customer decided for a folder, of course the data folder, if that is identical to the application folder, that's ok. You might also want to add both, as there is foxuser.dbf in the app folder, if you don't prevent it by RESOURCE=OFF. In that case I was creating a database as datawarehouse creating about 15GB of files overall and that daily failed at different steps. It's hard to debug and also caused costs, of course, as it wasn't a warranty case for us.
Also another developer just yesterday reported McAfee intercepted PACKs in a german MSDN forum. Such operations look suspicious to heuristic virus scans, but also dbf creation, index creation, etc etc.
Bye, Olaf.
Also another developer just yesterday reported McAfee intercepted PACKs in a german MSDN forum. Such operations look suspicious to heuristic virus scans, but also dbf creation, index creation, etc etc.
Bye, Olaf.
ASKER
Thanks, Olaf.
My customer has done system restores on his workstations to get them back to the state they were in before the McAfee update. That resolves the problem but leaves me wondering what they will do to keep their antivirus software up to date.
My customer has done system restores on his workstations to get them back to the state they were in before the McAfee update. That resolves the problem but leaves me wondering what they will do to keep their antivirus software up to date.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've been told that McAfee provided a special version of the software for this site, but wasn't told any details about what makes it 'special'. They are satisfied, so I am, too. Thank you all for your comments and suggestions.
I've requested that this question be deleted for the following reason:
Not enough information to confirm an answer.
Not enough information to confirm an answer.
If the author says: "Thank you all for your comments and suggestions." then the deletion is recommended... What should the author say for different "cleanup" decision?
:-)
:-)
Better than deletion is to select the last author's post (ID: 40181263) as the answer... It is good to know about VFP - McAfee problems.
If you want to distribute some points then split them among the three contributing experts.
If you want to distribute some points then split them among the three contributing experts.
ASKER
I agree with Pavel.
GEOFS, if you agree, why don't you simply close the question awarding points?
Olaf.
Olaf.
ASKER
Olaf, I was just trying to get this cleaned up as simply as possible. I appreciate the time all of you put into this, even though the user essentially solved his own problem.
Since points are split all is well, but you are the user asking, aren't you?
ASKER
Yes, I am the one who asked the question.
What you may do now is to use ADIR() or SYS(2000) instead of FILE(). Whereas FILE() attempts to open the file, ADIR() just lists the folder. Some Win32 API should also work, see http://www.news2news.com/vfp/?function=144 (unfortunately this API function works the same way as the FILE() function) or http://www.news2news.com/vfp/?group=27&function=378 which works like the ADIR() or SYS(2000).
You should include all non executable files (DBF, FPT, CDX, etc.) or the whole data folder to the antivirus exclusion list. It avoids the most of the problems obviously.
To test different antivirus could also help but who knows for how long...