mkornuser Posted November 18, 2008 Share Posted November 18, 2008 Hi there! Im having a problem with my Autoit-Script converted to 32-Bit-Exe to run on Windows 2003 Server X64 via PSExec. X64 converted Exe-Script hasnt any problem on X64-Windows, but i wanted to use the exe on x86 too, so this is no option. The problem occurs when exe is copied and run via Psexec to remote-machine (e.g. psexec \\serverX64 -c -f script.exe) The Exe then resides in system32-Folder and is executed. When its executed it then decompresses its script and trys to execute it in SysWOW64-Folder, but its not there. Then it shows an error message: Unable to open the script file. Executing the exe in any other folder than system32 works, but psexec always uses system32 as the remote-target for execution. So: Any ideas how to execute an 32bit-exe in system32 on WindowsX64? tnx for any suggestions! Link to comment Share on other sites More sharing options...
Airwolf Posted November 18, 2008 Share Posted November 18, 2008 Hi there!Im having a problem with my Autoit-Script converted to 32-Bit-Exe to run on Windows 2003 Server X64 via PSExec.X64 converted Exe-Script hasnt any problem on X64-Windows, but i wanted to use the exe on x86 too, so this is no option.The problem occurs when exe is copied and run via Psexec to remote-machine (e.g. psexec \\serverX64 -c -f script.exe)The Exe then resides in system32-Folder and is executed. When its executed it then decompresses its script and trys to execute itin SysWOW64-Folder, but its not there. Then it shows an error message: Unable to open the script file.Executing the exe in any other folder than system32 works, but psexec always uses system32 as the remote-target for execution.So: Any ideas how to execute an 32bit-exe in system32 on WindowsX64?tnx for any suggestions!A 32-bit exe will run fine on x64. I'm a bit confused... is this a problem with PSExec or your AutoIt script? If it's the script, post the code so we can try to help. Certifications: A+, Network+, Security+, Linux+, LPIC-1, MCSA | Languages: AutoIt, C, SQL, .NETBooks: AutoIt v3: Your Quick Guide - $7.99 - O'Reilly Media - September 2007-------->[u]AutoIt v3 Development - newbie to g33k[/u] - Coming Soon - Fate Publishing - Spring 2013UDF Libraries: SkypeCOM UDF Library | ADUC Computers OU Cleanup | Find PixelChecksumExamples: Skype COM Examples - Skype4COMLib Examples converted from VBS to AutoIt Link to comment Share on other sites More sharing options...
Kerros Posted November 18, 2008 Share Posted November 18, 2008 (edited) I was running into a similar problem, not even using PSExec. Autoit was having an issue on 64-bit Vista finding WinSAT.exe which resides in the system32 folder. Even doing Consolewrite(Fileexists(C:\Windows\system32\winsat.exe)&@crlf) returns a -1 when I know that winsat.exe is there. This must be do to the system doing 64-bit redirection, but without turning that off, as mentioned in the helpfile, I don't know of a solution. Edit: Fixed tags Edited November 18, 2008 by Kerros Kerros===============================================================How to learn scripting: Figure out enough to be dangerous, then ask for assistance. Link to comment Share on other sites More sharing options...
mkornuser Posted November 18, 2008 Author Share Posted November 18, 2008 A 32-bit exe will run fine on x64. I'm a bit confused... is this a problem with PSExec or your AutoIt script? If it's the script, post the code so we can try to help.Its not the script and its not PSexec itself. Just copy any given autoit-compiled-exe to system32 on a 64bit-System and it wont work, cause it doesnt find its own decompressed script. Any hints for that? Link to comment Share on other sites More sharing options...
mkornuser Posted November 18, 2008 Author Share Posted November 18, 2008 I was running into a similar problem, not even using PSExec. Autoit was having an issue on 64-bit Vista finding WinSAT.exe which resides in the system32 folder. Even doing Consolewrite(Fileexists(C:\Windows\system32\winsat.exe)&@crlf) returns a -1 when I know that winsat.exe is there. This must be do to the system doing 64-bit redirection, but without turning that off, as mentioned in the helpfile, I don't know of a solution. Edit: Fixed tags Similar problem there... Link to comment Share on other sites More sharing options...
Vofffka Posted May 20, 2009 Share Posted May 20, 2009 my solution of this issue: 1. compile 2 installers (x32&x64) add below string in the code: if node x64 then <through psexec copy and run x64 installer> else <through psexec copy and run x32 installer> endif Link to comment Share on other sites More sharing options...
Valik Posted March 24, 2011 Share Posted March 24, 2011 The Exe then resides in system32-Folder and is executed. When its executed it then decompresses its script and trys to execute itin SysWOW64-Folder, but its not there. Then it shows an error message: Unable to open the script file.This is because AutoIt lets Windows redirect it. While the binary itself is in system32 the system calls to open the binary to read the attached script are redirected to SysWOW64.I know two ways to fix this problem but I don't think I'll do either. The first method is to disable redirection (briefly) until the script is loaded and then turn it back on. This is somewhat hackish to me though so it's right out. The second method is to by-pass the problem entirely by reading the script directly from memory (Meaning we need to convince Windows to load it into memory with the rest of the binary). The second issue is much preferred but requires a lot of other changes. In short, this will be fixed someday. I'm not sure what to do about FileInstall(), though. We should not load installed files into memory so the second method is out for those. Anyway, I'm going to hijack your ticket and re-write it completely. This does not help you at all and so for that see below:So: Any ideas how to execute an 32bit-exe in system32 on WindowsX64?Copy the file to a shared directory and then instruct psexec to run it from there. Use separate 32-bit and 64-bit binaries and instruct psexec to use the appropriate one depending on target system architecture. This quirk is not going to be fixed any time soon. Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now