LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Symantec antivirus & LabVIEW 7.1 exe's

Anyone know of any conflicts with LV 7.1 exe's & Symantec AntiVirus Corporate 10.1.4.4000 on Win2k (and possibly XP)?

Soon after we installed the antivirus update, LV7.1. executables began locking up the system when they tried to access a file.  Some of the system is still responsive (you can view the system processes, for example), but when you give a command nothing happens (restart, for instance, doesn't work).  The processor monitor shows 99% idle... almost like both the AV and LV are waiting for something.  The computer must be hard booted to restore it.

While I'll be working on downgrading the antivirus, any ideas would be appreciated.

Thanks,

Joe Z.
0 Kudos
Message 1 of 8
(3,369 Views)

Hi Joe,

Check the security setting for the Symantec Anti-virus to allow file access.  Meanwhile do you have LabVIEW 7.1 development environment or are you just running an executable created in LabVIEW 7.1 on the machine with the runtime engine?. Need more information on the LabVIEW executable you are running.

Tunde.

 

0 Kudos
Message 2 of 8
(3,336 Views)
Hey Tunde, thanks for the reply.

The problem doesn't occur in the dev environment (professional).

The problem doesn't occur in every executable, just in some of the more complicated ones.

The problem does occur repeatably in the executables where it occurs.

Disabling scanning does not remove the problem, but disabling the rtvscan process in services does.  Disabling other Symantec services does nothing noticeable.

The problem occurs most frequently on the file dialog button on a front panel file control, but I've seen it occasionally occur on an ini file lookup on program start as well.

Joe Z.
0 Kudos
Message 3 of 8
(3,329 Views)

Hi Joe,

Try to run the executable on another computer with Symantec. I will also need more information on the executable especially the file operations to further troubleshoot this issue.

Tunde. 

0 Kudos
Message 4 of 8
(3,298 Views)
Further details on this one:

-The lockup is repeatable when the executable is running *from* a mapped network location and makes a file access *to* a different mapped network location.  Running to or from a local system or directly addressed network location (\\servername\...) does not cause the lockup.  Any file access will do, my favorite is the "Browse" buttons on file controls that have a mapped network location set in the file control.

-The lockup occurs in LV6.0.2, 7.1, & 8.0 (no access to 6.1 or 8.20 atm) executables, but never in the dev environments.  Different versions lock the system up with different characteristics (6.0.2 locks before fully running when a mapped file path is set as default, 7.1 & 8.0 lock on the file access).

-The lockup has been tested on 10+ machines.  Only on one very old machine does it not occur (my first development machine, actually).  Perhaps there is a timing issue.

This one has just been loads of fun to track down...

Joe Z.
Message 5 of 8
(3,267 Views)
"This one has just been loads of fun to track down..."
 
Stars to you Joe for "stick-to-it-tivness" and keeping us informed.
 
I wish I could help,
 
Ben
Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 8
(3,260 Views)

Hi Joe,

This might be a network issue. Can you access this file location through Start->Run in windows ?  Are you using a "Relative file path" function in the VI?

I will suggest you post the LabVIEW program.

Tunde A.

Applications Engineer, National Instruments.

0 Kudos
Message 7 of 8
(3,215 Views)
Thanks Ben, I wish you could too!  Given my druthers, I'd be working on a tree class structure in 8.20... maybe someday 🙂

Tunde, check the attachments.  No relative file pathing functions, or really much of anything else.

A quick test shows that running from the Start>>Run>>H:\bugcheck71.exe (for instance) exhibits the same behavior as any other method.  Once, it even locked up before rendering the front panel.

It may very well be my (relatively standard) Windows network.  It has many of the hallmarks of a deadlock timing issue.

To reproduce the behavior in the executable, you may have to rebuild it to suit your particular network mappings.

1.  Open the bugcheck71.vi file.
2.  Set the file control path to a mapped network location.  (It's currently set to select a directory.)
3.  Set the file control path to default to that location, save, and exit the vi.
4.  Build the VI into an executable.
5.  Copy the vi to a mapped drive location.
6.  (The hard part) Run the vi on a machine with the Symantec 10.1.4.4000 antivirus client, scan engine 61.2.1.10.
7.  Click the browse button.

As I've said, I don't see it on every machine, just most of them.

Symantec shows that earlier antivirus clients could cause tcp/ip issues through the antivirus mail client snap in, which our IS is likely to have included.  Does the exe make any tcp/ip connections that the dev environment does not, or in a different way?
0 Kudos
Message 8 of 8
(3,192 Views)