Odd Aut2Exe errors.

[Mat]

When running Aut2Exe (either through the UI OR using AutoIt3Wrapper and SciTE) I get errors 9 times out of 10. Mostly the following: "Error: Error opening the destination file.", but that is less frequent without SciTE open, but also errors with various other messages - "Unable to set console subsystem." and "unable to create compiled archive".

None of this was happening last week.

Running au3's is fine. Running the exe's that do succeed work fine. To avoid a list, everything except Aut2exe is working as it always has been.

I have done the following:

• Reinstalled AutoIt opting to uninstall the previous version
• tried putting files in a different directory. (it is usually "C:\Programming\AutoIt" but I tried the users directory and desktop and root etc.
• Editing UAC settings (I am running vista Home premium sp2)

Any ideas? I have reached the conclusion that the 'destination' file refers to the .au3, as it creates an exe, which when run says that it is "Unable to open the script file".

Mat

[Jos]

Did you check your AV and maybe try excluding the script directory to test if that is the root cause?

Jos

[Mat]

  On 5/7/2010 at 4:38 PM, 'Jos said:

Did you check your AV and maybe try excluding the script directory to test if that is the root cause?

Jos

Completely disabling av had no effect. That includes windows security or whatever it is they ship with it by default.

This is probably more helpful... Trying to use AutoitWrapper gave this error.

Error: EndUpdateResource: Returncode = 0 - LastError:5:Access is denied.

hmm... I will try starting aut2exe as admin.

[Mat]

  On 5/7/2010 at 4:43 PM, 'Mat said:

hmm... I will try starting aut2exe as admin.

Still there.

[Jos]

  On 5/7/2010 at 4:43 PM, 'Mat said:

Completely disabling av had no effect. That includes windows security or whatever it is they ship with it by default.

This is probably more helpful... Trying to use AutoitWrapper gave this error.

Error: EndUpdateResource: Returncode = 0 - LastError:5:Access is denied.

hmm... I will try starting aut2exe as admin.

That error will only be possible when you use AutoIt3Wrapper since this is the resource update portion.

You stated that AUT2EXE also has errors so there has to be another issue why the compiler can get access to the file anymore.

Any other antispam software running or something like that?

[Mat]

  On 5/7/2010 at 4:47 PM, 'Jos said:

That error will only be possible when you use AutoIt3Wrapper since this is the resource update portion.

You stated that AUT2EXE also has errors so there has to be another issue why the compiler can get access to the file anymore.

Any other antispam software running or something like that?

Nope.

[eltorro]

Check the folder permissions.

[Mat]

  On 5/7/2010 at 4:56 PM, 'eltorro said:

Check the folder permissions.

Full except for 'special' permissions which I seem to be unable to set.

[eltorro]

  On 5/7/2010 at 5:00 PM, 'Mat said:

Full except for 'special' permissions which I seem to be unable to set.

Is that for the AutoIt folder or you script folder?

Check the script folder.

[Mat]

  On 5/7/2010 at 5:25 PM, 'eltorro said:

Is that for the AutoIt folder or you script folder?

Check the script folder.

both.

[ripdad]

Hi Mat,

Backup your scripts on a flash drive.

Then right-click on C:\ >> Choose Properties >> Tools Tab >> Error Checking >>

Check Now >> Check All >> Start >> Click Yes and Reboot

It will check your hard drive for bad sectors and file errors.

Not that you have any .. but at least you can rule that out.

[jaberwacky]

Are you using a virtual machine?

[BinaryBrother]

DropBox is known to cause permission issues during the compile process, if you compile in a DropBox synced DIR.

Do you have any application that might be locking the file handles periodically? Sync apps, etc.

[Mat]

Sorry I haven't been here... slightly hectic night last night. Errors are same as always.

  On 5/8/2010 at 1:03 AM, 'ripdad said:

Hi Mat,

Backup your scripts on a flash drive.

Then right-click on C:\ >> Choose Properties >> Tools Tab >> Error Checking >>

Check Now >> Check All >> Start >> Click Yes and Reboot

It will check your hard drive for bad sectors and file errors.

Not that you have any .. but at least you can rule that out.

All my scripts ended up being 106mb next time the computer starts it will run it. I doubt that's the problem.

  On 5/8/2010 at 1:06 AM, 'jaberwocky6669 said:

Are you using a virtual machine?

Nope.

  On 5/8/2010 at 1:19 AM, 'BinaryBrother said:

DropBox is known to cause permission issues during the compile process, if you compile in a DropBox synced DIR.

Do you have any application that might be locking the file handles periodically? Sync apps, etc.

Nope.

[BinaryBrother]

A full report of installed apps, running Services, and currently running processes might help. I can't pretend I'll know what's wrong, but I think it would certainly help the developers.

[Mat]

  On 5/8/2010 at 9:54 PM, 'BinaryBrother said:

A full report of installed apps, running Services, and currently running processes might help. I can't pretend I'll know what's wrong, but I think it would certainly help the developers.

I'll see what I can do.

[Shafayat]

I used to get the errors on windows 7 about thrice in 10 tries.

Just to test it, I installed windows7 separately on a new, never before used, harddisk. Then I installed Autoit and tried compiling. Oddly, I got errors on the first try. Then I tried with some other script. Sometimes they compile just fine. Sometimes they give errors without any (visible) reason. What might be causing that. If you want I can post a video of the whole process.

[Jos]

Also try testing without the Windows Explorer being open on the directory your script is created in.

Jos

[Shafayat]

It works like magic when explorer is closed. No Errors at all. But what's causing this?

[Jos]

  On 5/9/2010 at 10:01 AM, 'Shafayat said:

It works like magic when explorer is closed. No Errors at all. But what's causing this?

We haven't figured out what the exact root-cause is but it looks like the explorer reads the new EXE file's properties while the process isn't finished yet and still need to update the EXE's resources.