Symantec antivirus causing high CPU usage

[JR-BE]

Looking for recommendations regarding adding exclusions to Symantec 14 to prevent high CPU usage from antivirus scanning when using LabVIEW development on a windows 2016 server environment.  

[billko]

Why does it need to un on a Win2016 Server PC?  These PCs are usually used for... well... servers, and the AV has every right to complain.  I would just go elsewhere to do my development.

[yea_likethecity]

Hi JR-BE,

LabVIEW has some history of strange interactions with Symantec antivirus. I found one case in our service request history with similar symptoms where they were using a timed loop on a Windows machine with Symantec. Because the timed loop modifies thread priorities and does some other stuff on the backend, Symantec AV really didn't like it and it caused CPU spikes. The issue was somewhat resolved by replacing the timed loops with regular while loops. If you have timed loops, this may be something to consider. 

Otherwise, I agree with Billko. The easiest solution will be using a different computer, if possible.

[JR-BE]

Sorry, In rereading my post I realize my wording implied I was developing on the server, but actually the development is on a workstation and we are just saving files to a new server running server 2016, The server is new, old server was running server 2003, but we were also saving all our labview code locally (for the past 10 years), and then just making periodic backups (sometimes). The idea is to save everything to the new server to insure periodic backups, as it was not happening consistently when things were being saved on the workstation.

The Symantec antivirus does seem to be slowing everything down and I thought it was the source of some labview save issues, but those have now seemed to have resolved with repair of some dependency files being relinked. But it still is taking up to 50% CPU, so I think there is some tweaking of the virus program, perhaps some exclusions,  that will need to be done. Just wondering if anyone else had run into similiar issues and had recomendations.  Thanks for taking time to reply. 

[JR-BE]

Thanks for the input, I don't think we are using any timed loops in our application, but is good to know for reference. Because we don't have control over what antivirus software is installed our deployed systems by customers at their sites, we'll have to just watch for any problems to develop with running the built applications. 

[billko]

replied to the wrong msg

[billko]

---

@JR-BE wrote:

Sorry, In rereading my post I realize my wording implied I was developing on the server, but actually the development is on a workstation and we are just saving files to a new server running server 2016, The server is new, old server was running server 2003, but we were also saving all our labview code locally (for the past 10 years), and then just making periodic backups (sometimes). The idea is to save everything to the new server to insure periodic backups, as it was not happening consistently when things were being saved on the workstation.

The Symantec antivirus does seem to be slowing everything down and I thought it was the source of some labview save issues, but those have now seemed to have resolved with repair of some dependency files being relinked. But it still is taking up to 50% CPU, so I think there is some tweaking of the virus program, perhaps some exclusions,  that will need to be done. Just wondering if anyone else had run into similiar issues and had recomendations.  Thanks for taking time to reply. 

---

Oh - whew!  That makes much more sense.  I know that many AV will scan incoming files from the network automatically.  Maybe because LabVIEW files are binary files, AV thinks they may be executable and scans every file as it comes into the server?  Maybe there is some kind of white list you can add LabVIEW file types to?

edit:

Sheesh, i have to read more carefully.  Sorry that I just echoed your thoughts back at you.  😕

[Bob_Schor]

It's good to have a Server to do, well, "server" things for you.  One such thing you should try to do is to set up a Version Control System with a Server running, say, Subversion Server, and have all of your LabVIEW Workstations run Subversion Client.  Now the Server contains your Code Repository, keeping careful track of all of the versions of your code (so you don't need to say "Code Version 1.1.01.a.test.vi") and provides a method for everyone working on this code to always have the "latest" version and to provide a way to update the code on the Repository when you make changes.

If you search the Forums (and the Web), you can find numerous discussions of Why and How for LabVIEW and Version Control.

Bob Schor