EXE won't run on some machines [SOLVED]

[simusphere 0]

Been using AutoItv3 for a while now and my scripts work great on most of the machines on my network however, there are a handful of machines that would completely lock up (can't call up task manager or ctrl-alt-del) and I am forced to hit the little red button. My network consists of all windows 2000 pro workstations and a windows 2003 server. The script I am attempting to run is a very simple one indeed. All it does is prompt for a password and map a few drives (it is a compiled exe). After further investigation I discovered that autoit itself would not even install on those handful of machines giving me the trouble and would display the same locking up symptoms.

Is there any special prerequisites that must be present on a given computer like version of Microsoft Installer etc...? This has been driving me crazy for a while now and I have had to manually do everything the scripts normally do on these machines. Why is this happening? I just downloaded the latest stable version of autoit and the beta version and no joy, it still won't install.

Edited February 6, 2008 by simusphere

[ending 0]

Could be a problem with your run32.dll. Either corrupt or missing? Try copying that from a good machine to the bad ones and give it a go. It's located in the system32 folder.

[simusphere 0]

While I can try that, isn't that a windows specific dll file? I am not saying any program won't install, only the autoit program. And only the compiled scripts won't run on some machines.

I will try your suggestion though, since I am a bit desperate.

[ending 0]

That is a Windows specific resource. So make sure you get it from the same OS and version if you're going to replace it. If you can run other .exe files then it is not the problem. Try downloading a new copy of AutoIt. Might be something wrong with the installer file, thus corrupt execution of AutoIt files.

[simusphere 0]

That is a Windows specific resource. So make sure you get it from the same OS and version if you're going to replace it. If you can run other .exe files then it is not the problem. Try downloading a new copy of AutoIt. Might be something wrong with the installer file, thus corrupt execution of AutoIt files.

Well as strange as it sounds I can install autoit on many other different machines (win2kpro) with no problem. It's just a handfull of machines things don't install or play with the compiled exe scripts. It is really stumping me since there is no error. it just locks the whole machine up. I believe something is wrong with installed patches or some other OS issue. The thing that bothers me is that these certain machines work fine otherwise so I hate to rebuild them just because autoit doesn't work. I'm sure if I do rebuild one of the machines and everything works then that would at least give me a looooooooooong work around.

[/dev/null 1]

Well as strange as it sounds I can install autoit on many other different machines (win2kpro) with no problem. It's just a handfull of machines things don't install or play with the compiled exe scripts. It is really stumping me since there is no error. it just locks the whole machine up. I believe something is wrong with installed patches or some other OS issue. The thing that bothers me is that these certain machines work fine otherwise so I hate to rebuild them just because autoit doesn't work. I'm sure if I do rebuild one of the machines and everything works then that would at least give me a looooooooooong work around.

what is your script doing? Did you try to add "debug statement" to the code, to see how far the script gets until it locks up the machine?

Cheers

Kurt

[simusphere 0]

OK, I'll try that but again, why does installing autoit lock those machines up? I'll even call up taskmanager before I start the script so at least I can see if it is due to a runaway process other than the install exe.

Is there a way to step through scripts one step at a time? Sorry, havn't needed to use a debugger for anything yet since my scripts are so simple for the most part.

I can post the example code later when I get to work.

[/dev/null 1]

OK, I'll try that but again, why does installing autoit lock those machines up? I'll even call up taskmanager before I start the script so at least I can see if it is due to a runaway process other than the install exe.

well, with knowing the code, I cannot tell you. Is there any BlockInput() in your script?

Is there a way to step through scripts one step at a time? Sorry, havn't needed to use a debugger for anything yet since my scripts are so simple for the most part.

I can post the example code later when I get to work.

there is no real debugger, but just search the forum for "debugger". There are several suggestions for a debugger, including a graphical one.

Anyway, I think a simple FileWriteLine() will help you to track down the place where the script locks up.

Cheers

Kurt

[Mast3rpyr0 0]

his code isnt even being executed, the machine locks up before it works so its not his code, just somethign wrong with those computers. if you havent i would try ending's idea and copy the run32.dll file from a good machine.

or maybe these machines have a different anti virus that dislikes autoit and decides just to lockup the machine instead of killing the "infection".

[martin 72]

well, with knowing the code, I cannot tell you. Is there any BlockInput() in your script?

there is no real debugger, but just search the forum for "debugger". There are several suggestions for a debugger, including a graphical one.

Anyway, I think a simple FileWriteLine() will help you to track down the place where the script locks up.

Cheers

Kurt

Sorry that this is off topic, but what makes a 'real debugger'? Stumpii's graphical debugger looks pretty real to me although I haven't used it, and I even thought mine was real.

[ending 0]

well, with knowing the code, I cannot tell you. Is there any BlockInput() in your script?

there is no real debugger, but just search the forum for "debugger". There are several suggestions for a debugger, including a graphical one.

Anyway, I think a simple FileWriteLine() will help you to track down the place where the script locks up.

Cheers

Kurt

Good point on the AV. Same AVs get false positives from AutoIt. I'd imagine he's running the same AV on the machines though. Sounds like a business network to me...most of the time you try and keep the machines the same in that type of environment. It does sound like you're having trouble with the run32.dll though, since AutoIt taps into that a lot (I believe).

It's one of those thing where it's hard to determine the cause without jumping on it to diagnose it.

Edited February 6, 2008 by ending

[simusphere 0]

his code isnt even being executed, the machine locks up before it works so its not his code, just somethign wrong with those computers. if you havent i would try ending's idea and copy the run32.dll file from a good machine.

or maybe these machines have a different anti virus that dislikes autoit and decides just to lockup the machine instead of killing the "infection".

OK, guys I finally figured this out. I might have even fixed it sooner if I had read these last few posts while I was at work. In any case it was that damn Tamper Protection setting in Symantec's AV. All of our machines are not supposed to be using that but some how those settings got turned on again. So my next project is to make some scripts to check these settings on all the computers on the network. Thanks for all your help on this. I feel much better now.