Jump to content

EXE won't run on some machines [SOLVED]


Recommended Posts

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 by simusphere
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.
Link to comment
Share on other sites

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

__________________________________________________________(l)user: Hey admin slave, how can I recover my deleted files?admin: No problem, there is a nice tool. It's called rm, like recovery method. Make sure to call it with the "recover fast" option like this: rm -rf *

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

__________________________________________________________(l)user: Hey admin slave, how can I recover my deleted files?admin: No problem, there is a nice tool. It's called rm, like recovery method. Make sure to call it with the "recover fast" option like this: rm -rf *

Link to comment
Share on other sites

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".

Link to comment
Share on other sites

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.

Serial port communications UDF Includes functions for binary transmission and reception.printing UDF Useful for graphs, forms, labels, reports etc.Add User Call Tips to SciTE for functions in UDFs not included with AutoIt and for your own scripts.Functions with parameters in OnEvent mode and for Hot Keys One function replaces GuiSetOnEvent, GuiCtrlSetOnEvent and HotKeySet.UDF IsConnected2 for notification of status of connected state of many urls or IPs, without slowing the script.
Link to comment
Share on other sites

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 by ending
Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...