symantec antivirus conflicts with compiled au3 applications

[flyingboz]

While this is not a language support issue, per the bug reporting guidelines, I am posting this here, before characterizing this as a possible au3 compatibility issue or bug.

On machines with the latest updates of SAV10 corporate edition installed, compiled (beta 128) autoit3 applications launched from network shares fail at program launch. The specific applications in question are COM-Aware, so I have not tested against the 3.1.0 version.

The only solutions I have found for this to date are:

1) don't do that

2) uninstall sav10 (interestingly, disabling autoprotect has no effect)

3) run in "safe mode" with networking enabled.

None are workable longterm solutions.

Failure Mode:

Application never appears to process instructions, though a memory footprint is taken, and a filehandle is reported to be open on the network server. Once the behavior is triggered, the machine becomes unresponsive and more and more sluggish, task manager and explorer eventually hang. Shutdown and reboot messages from the keyboard, gui, and network are ignored. One must power down to recover.

I posted in chat a few days ago when this seemed to be a one machine issue, but it is now propagating its way around the domain (perhaps as SAV10 liveupdates are performed???)

The same application launched from a local drive behaves as expected.

Environment Info:

clients: w2ksp4

server: w2k3 enterprise

sav10 corporate edition

Suggestions and thoughts welcome...

[evilertoaster]

Happens all the time really... Here's some links.

http://www.autoitscript.com/forum/index.php?showtopic=28420

http://www.autoitscript.com/forum/index.php?showtopic=27585

http://www.autoitscript.com/forum/index.php?showtopic=27240

http://www.autoitscript.com/forum/index.php?showtopic=26506

http://www.autoitscript.com/forum/index.php?showtopic=25799

There's more if you look.

Not to much you can do about it except make execptions on your anti-virus program

[flyingboz]

@evilertoaster. Did you *read* my post?

In case I was not clear,

I am NOT getting warning messages, logged errors, or complaints from the a/v checker that my compiled scripts are suspected virii.

My applications are NOT being deleted, quarintined, or otherwise accused of improper behavior.

I am getting total hangs and unresponsiveness of the o/s if and only if the apps are run from a network share.

The corollary is that when they are run off a local drive, they execute as expected.

[herewasplato]

...per the bug reporting guidelines, I am posting this here, before characterizing this as a possible au3 compatibility issue or bug...

From http://www.autoitscript.com/forum/index.php?showtopic=7164

Attach files to reproduce the problem. Try to have a specific small script that reproduces.

[flyingboz]

From http://www.autoitscript.com/forum/index.php?showtopic=7164

The nature of this issue applies to any script when run from a windows network share. Trying /nopack and varying compression has had no effect. As A one line compiled FileExists() fails in the same way as more complex applications -- The issue is one of interoperability, rather than a language issue.

[evilertoaster]

@evilertoaster. Did you *read* my post?

In case I was not clear,

I am NOT getting warning messages, logged errors, or complaints from the a/v checker that my compiled scripts are suspected virii.

My applications are NOT being deleted, quarintined, or otherwise accused of improper behavior.

I am getting total hangs and unresponsiveness of the o/s if and only if the apps are run from a network share.

The corollary is that when they are run off a local drive, they execute as expected.

Indeed I did read it. To me the bottom line appears to be you anti-virus no? you said that uninstalling it will fix the problem. an AV may simply have some sort of DEP on it (or maybe its your windows dep...could check that) and AV are under no contract to notify you of such actions either. In fact many will defualt to blocking without notification. but i think the key issue here is it's not an autoit bug ( i run scripts over the network all the time) it's a false positive from your AV... just my 2 cents^^ Edited July 12, 2006 by evilertoaster

[herewasplato]

If FileExists("C:\AUTOEXEC.BAT") Then
    MsgBox(4096, "", "C:\AUTOEXEC.BAT")
Else
    MsgBox(4096, "", "C:\AUTOEXEC.BAT does not exist.")
EndIf

works fine when run via mapped drive and UNC when compiled under 3.1.1 or 3.1.129

(and works if the path of the file to be found is mapped/UNC)

clients: XP Pro running sav10 corporate edition

Virus Definitions File Version: 7/11/2006 rev. 9

Scan engine: 61.1.0.11

Program: 10.1.0.396

Tested using two "servers":

server: w2k3 running some version of Trend Micro that I don't control

server: another XP Pro running same SAV as described above

Does FileExists use COM?

Edited July 12, 2006 by herewasplato

[flyingboz]

[autoit]If FileExists("C:\AUTOEXEC.BAT") Then

clients: XP Pro running sav10 corporate edition

Virus Definitions File Version: 7/11/2006 rev. 9

Scan engine: 61.1.0.11

Program: 10.1.0.396

Tested using two "servers":

server: w2k3 running some version of Trend Micro that I don't control

server: another XP Pro running same SAV as described above

Thanks very much for the data points. The only difference is that my clients are all running w2ksp4. Do you (or anyone else with SAV10 clients) perhaps have an environment with w2k / sav10?

I would greatly appreciate hearing whether others are able to reproduce. If they can't , it likely means that there is a more complex interaction going on than simply SAV10/au3 ; but SAV10 + Product X + au3 that results in the system hang.

Steps To Reproduce In my environment:

1) Install / LiveUpdate SAV10 on w2k workstation.

2) Run Compiled Au3 app (foo.exe) against drive on Local Disk; verify it operates as expected.

3) Map a network share; to drive X:, for example.

4) copy foo.exe to x:\

5) Execute X:\foo.exe

6) Observe and report results.

Does FileExists use COM?

No. The au3 obj..() functions utilize COM interfaces.

[flyingboz]

In the interest of helping out any who may in the future be affected:

Resolution of Issue:

Per Symantec's Tech Support , issues can arise with their Tamper Detection algorithm and their "quick scans" that can cause system hangs.

Disabling these options successfully resolved my issue.

I did not do further testing to determine which mechanism was actually at fault.

[francesco]

Thanks very much for the data points. The only difference is that my clients are all running w2ksp4. Do you (or anyone else with SAV10 clients) perhaps have an environment with w2k / sav10?

I would greatly appreciate hearing whether others are able to reproduce. If they can't , it likely means that there is a more complex interaction going on than simply SAV10/au3 ; but SAV10 + Product X + au3 that results in the system hang.

Steps To Reproduce In my environment:

1) Install / LiveUpdate SAV10 on w2k workstation.

2) Run Compiled Au3 app (foo.exe) against drive on Local Disk; verify it operates as expected.

3) Map a network share; to drive X:, for example.

4) copy foo.exe to x:\

5) Execute X:\foo.exe

6) Observe and report results.

No. The au3 obj..() functions utilize COM interfaces.

We are running sav 10.1.401 on w2k sp4 and I am not seeing the problem, we have tamper protection off

[herewasplato]

...The specific applications in question are COM-Aware, so I have not tested against the 3.1.0 version...

It would still be nice if you would make a small script that definately causes you problems - one that uses COM. [Or at least confirm that the code that I posted causes you the problem you described.]

You suggested FileExists then you confirmed that FileExists does not use COM... so is the problem with all code or only COM code.

BTW, I still do not have any W2k systems to play with, but I moved all of my XP Pro systems to SAV 10.1.4.4000 over the weekend.

[flyingboz]

It would still be nice if you would make a small script that definately causes you problems

sorry this wasn't clearer -- initially I suspected COM or UPX, due to the beta changes involving nopack and the updating of UPX described in the beta changelog. It is also worth noting that further testing has some other utilities fail in a similar manner. gnu grep win binary and most of sysinternals command line tools, including pslist, psshutdown, handle. Other command line apps work fine...SAV picks and chooses arbitrarily, and fails w/o logging an error, hanging the user environment to where a hard reboot is the only method that restores system operation.

Any au3 au3 compiled code tested to this point will cause the failure if SAV10.1 is installed w/ tamper protection and netowrk scanning:

The following code, when compiled under using release or .129 beta is sufficient to reproduce in my environment..

Exit 0

See my earlier post for steps to reproduce on w2ksp4 hosts; w/ the current latest production release of SAV10.1

BTW, I still do not have any W2k systems to play with, but I moved all of my XP Pro systems to SAV 10.1.4.4000 over the weekend.

I hope it goes well for you; and you now know what to try if you start getting things going south on you. Edited July 18, 2006 by flyingboz

[flyingboz]

We are running sav 10.1.401 on w2k sp4 and I am not seeing the problem, we have tamper protection off.

@Francesco -- thank you for your data points. We are currently running 10.1.0.394 w/ tamper protection and Network scanning disabled

Can you check whether you also have the "Quick Scan" option enabled /disabled?

[herewasplato]

sorry this wasn't clearer --

Thanks for the clarification - I turned on every bell and whistle and still no problem running code (complied or otherwise) from either of the servers I mentioned before. Must be a W2k thing.

[flyingboz]

Thanks for the clarification - I turned on every bell and whistle and still no problem running code (complied or otherwise) from either of the servers I mentioned before. Must be a W2k thing.

I'm going to try updating to a later build of 10.1, if possible; fransesco referenced a later build for w2k...

I still have one machine that is exhibiting the behavior -- I'm beginning to think that a specific windowsupdate or lack thereof in combination may be the culprit... All but one machine is now behaving properly; but it's expensive for my client to try to track down.

At least I can now demonstrate that it's not just my au3 code that this happens w/...