Solution Unable to open the script file...?

[VKZOD]

After compiling the .au3 on Win 7 64-bit get the "Auto it error : Unable to open the script file" on executing the exe.

searched the forum tried solutions like disabling Trend Micro etc.

Is there any better solution...? Need help.. 

[JohnOne]

Need to post code, including any compile options.

[TheDcoder]

Disable Anti-Virus & Re-Compile it.

TD

Edited March 31, 2015 by TheDcoder

[Dana]

I'm having the same problem.  The strange thing is that it's intermittent; I can compile it one time and I get the "Unable to open the script file" when I try to run the exe, and another time it works fine.  Computer has Trend antivirus which I'm not able to disable.

It does seem related to the compiler options.  At first I thought it was the compiler not liking the file version I was using (e.g. 1.1 vs. 1.1.0.0) but I couldn't repeat it.  I most recently got it (actually two similar programs, both of which had the same problem) to compile by removing the compiler directives that the previous run had created and making only one change (target file name) in the compiler dialog.

What does that error mean?  What script file is it looking for that it can't find at runtime?

[ViciousXUSMC]

I have since the very beginning always had issues compiling, it sometimes works first shot, sometimes I may have to do it 10 times before it works.

I was able to track down the problem to explorer holding open the file in some sort of cache making the compile fail.  I worked around it by making a compile script that would close the explorer process, compile, and then re-launch explorer again.

I eventually just gave up on that and compile it as many times as needed until it works and I keep an eye on the file size as thats the giveaway for me if it worked properly or not. 

As far as I can tell this problem follows me around on multiple computers with multiple setups of OS and AV so it was not an AV issue in my case, probably very similar to the "read only" bug with Office files where the Preview Pane causes that issue.

Edited September 21, 2015 by ViciousXUSMC

[TheDcoder]

The antivirus scans the RCDATA before the compiler attaches it to AutoIt3.exe to complie your program... This will lead to a missing RCDATA resource in the compiled executable, So AutoIt throws a "Script not found error

 

@Dana How to Disable Trend Antivirus

Edited September 21, 2015 by TheDcoder
@Dana

[JohnOne]

Seriously, disabling antivirus is not an answer.

[TheDcoder]

@JohnOne What made you think that?

[Dana]

The antivirus scans the RCDATA before the compiler attaches it to AutoIt3.exe to complie your program... This will lead to a missing RCDATA resource in the compiled executable, So AutoIt throws a "Script not found error

@Dana How to Disable Trend Antivirus

I know how to disable the antivirus, it was the first thing I tried, but the corporate policy where I work won't allow me to (it's password protected at the corporate level).  I'm sure if I asked I could get it temporarily disabled, but the fact that the issue is intermittent as I described above makes me believe it's not an antivirus issue.  At any rate I was able to get it compiled but it does seem to be a bug...

[TheDcoder]

@Dana Oh , Then we should wait for the experts to look at this problem

 

TD

[Dana]

New script won't compile successfully no matter how many times I try, unless I check the "x64" box, when compiling, in which case I get a larger .exe file and it works.

Edited November 13, 2015 by Dana

[JohnOne]

AutoIt version, scite version, OS version OS ARCH version, script.

[Dana]

Sorry... AutoIt 3.3.14.1, SciTe 3.5.4, Win7Pro.  I can sort of see what's happening... compiling the x86 version, it instantly blows through "creating resource file", whereas when it's compiling the 64 bit version, it pauses on the "creating resource file" and whatever it is gets included, hence the larger file size.  With the other program which compiled intermittently, I could tell whether it would work by how long it took to compile.

[Dana]

Update:  It is related to the antivirus... I got our IT guy to temporarily disable Trend Officescan, and I was able to successfully compile the program... turned it back on and I couldn't compile again.  The intermittent nature of the problem with the older script makes me think it's a timing thing as to when the AV releases the resource file?  But as JohnOne said, disabling the AV is not a proper answer.

 

[water]

Today I noticed the same problem here. We moved to TM and now only compiling as 64 always works but compiling for 32 bit most of the time gives the "unable to open" message.
Any solution?

[TwoBeSeen]

Hi, I am having the same problem, even stated it as a bug here in the bug tracker

https://www.autoitscript.com/trac/autoit/ticket/3183

As you can see, the bug (it IS a bug) was closed shortly after creation.

Why it is a bug: Trust me I am a pro in computers. If something doesn't function in a normal environment (and having anti virus software in W7 is quite normal) it is a bug. It doesn't matter wether the problem lies in Windows (MS won't care much) or in the anti virus software (they won't care either) is not relevant. Because the x64 compiler works perfectly is another hint that it IS a bug.

Because I work with AutoiT in my companies W7 environment I am not able to disable anti virus. So what.... If it is a race condition: Make a wait/sleep optional parameter in the aut2exe compile process as a workaround or just fix the BUG.

So pretty pretty please: Reopen the bug in the bug tracker ;-)

 

[BrewManNH]

Actually where the error condition comes from is 100% relevant. If the AV software is preventing the exe to be compiled, then it's the AV software causing the problem. If it's a bug in Windows causing it, then the problem is in Windows.

I can compile x86 and x64 exes in AutoIt without a problem, so to me it's probably not a bug in Aut2Exe because it's not happening for everyone or even in similar situations.

There are plenty of AV programs out there that suck and no one can write software to get around every POS AV software program to make it work.

I used to run into compiling problems when I had my scripts in a Dropbox synced folder, every time I updated it, dropbox would try to send it up to my online storage, locking the file and preventing the compilation. I had to disable Dropbox when I was testing scripts. That's not something Aut2Exe should be made to handle, that was a Dropbox issue, and an issue on my computer, and had nothing to do with AutoIt or Aut2Exe.

[Jos]

Hi, I am having the same problem, even stated it as a bug here in the bug tracker

https://www.autoitscript.com/trac/autoit/ticket/3183

As you can see, the bug (it IS a bug) was closed shortly after creation.

Why it is a bug: Trust me I am a pro in computers. If something doesn't function in a normal environment (and having anti virus software in W7 is quite normal) it is a bug. It doesn't matter wether the problem lies in Windows (MS won't care much) or in the anti virus software (they won't care either) is not relevant. Because the x64 compiler works perfectly is another hint that it IS a bug.

Because I work with AutoiT in my companies W7 environment I am not able to disable anti virus. So what.... If it is a race condition: Make a wait/sleep optional parameter in the aut2exe compile process as a workaround or just fix the BUG.

Honestly initially though "Fuck It, I am not going to answer this guy when he is incapable of asking a question and is telling us what to do", but hey, it is Christmas time.

I closed the Bug report as it is NOT an AUT2EXE bug and actually has NOTHING to do with AUT2EXE.
The problem likely lies in the fact that when a script program is started and the runtime module wants to read the packed script source, it isn't able to do so due to your AV activities.

So, I am not going to re-open it unless you do what is being asked and prove to us it is AutoIT3 having the issue and not your AntiVirus software. 
Your other option obviously is ask the supplier of your payed software to fix their sofware..... right?

Merry Christmas,
Jos

Edited December 23, 2015 by Jos

[Dana]

Actually where the error condition comes from is 100% relevant. If the AV software is preventing the exe to be compiled, then it's the AV software causing the problem. If it's a bug in Windows causing it, then the problem is in Windows.

I can compile x86 and x64 exes in AutoIt without a problem, so to me it's probably not a bug in Aut2Exe because it's not happening for everyone or even in similar situations.

There are plenty of AV programs out there that suck and no one can write software to get around every POS AV software program to make it work...

If it's happening for lots of people with different AV software packages, then while technically it's not an AutoIt bug per se, it is, as ToBeSeen says, an inability of AutoIt to work in a common environment.  If it was an obscure AV freeware it'd be one thing, but Trend is one of the more common packages used at the corporate level, and the guys like us running into the problem aren't at the corporate level where the AV is administered.  And it's not even just AV software; as mentioned above Dropbox synced folders can do it as well (assuming it's the same error mechanism), so probably there are still more situations where this will be an issue.

If it could be fixed by adjusting the timing (either overall or as a compile option) that would be "the right thing to do".  But there should at least be an error message when the compile fails (Aut2Exe creates an invalid executable), and that certainly IS a bug.

[BrewManNH]

I'm pretty sure that there is an error message that it can't be created, although creating it isn't the problem because the exe is created before the error occurs, the error is that it doesn't delete the exe after it fails to add the resources. This is the only bug that I can see here.

Whether it's possible to add a delay in between creating the exe and attempting to add the resources I can't say, but it's probably possible. I'd request that it be optional and maybe configurable, because I don't want the process to have a built-in delay if I'm not having the issue, it just makes the process needlessly take longer.

A locked file isn't AutoIt's problem, whether because of AV software or in my case Dropbox, it's a problem on that computer. There are hundreds of AV software programs out there, and not all of them cause the issue, and I don't think that a developer of AutoIt can account for every contingency. You aim for the lowest common denominator and rely on the users to figure out the AV issues on their end.