3 posts in this topic
hey, can anybody enlighten on lesser known Windows hacks or uses ?
I am having a bit of trouble and was wondering if anyone may have a workaround for my issue. I made a script that would automatically install a piece of software each night on a Windows 7 Box. Now I have been instructed to do the same with a Windows 10 box since the application is now being tested on Windows 10.
The way I did the win7 installation was that I made a script and then made an executable that I call with a batch file along with the Installer. So the process is
AutoitMainFile calls batch file, batch file opens Installer, and the automatedinstaller.exe The automatedinstlaller waits 10-20 seconds to make sure the Installer has been fully loaded.
When I try to do the same both get loaded but the automatedinstallation.exe does not send commands to the installer. The code does work and nothing from the program we are wanting to install has changed as our Windows 7 runs every night no problem.
Do I need to make a new automatedinstall script for windows 10?
Any advice is appreciated
I am trying to spawn a cmd.exe shell on a remote machine using psexec then proceed to running commands on that machine and reading the output. I.e. running pwd.
Unfortunately, the code I have now will just immediately exit cmd on the remote system
I'm trying to use the current code
#include <Constants.au3> $pid = Run('C:\Users\test\Desktop\psexec.exe \\192.168.1.123 -u test -p "P@$$word1" -h -s cmd',@SystemDir, @SW_HIDE, $STDIN_CHILD + $STDOUT_CHILD) StdinWrite($pid,"pwd") StdinWrite($pid,@CRLF) Local $data Sleep(2000) $data &= StdoutRead($pid) ConsoleWrite("Debug:" & $data & @LF) StdinWrite($pid,"cd ") StdinWrite($pid,"C:\users\test2") StdinWrite($pid,@CRLF) StdinWrite($pid) $data &= StdoutRead($pid) ConsoleWrite("Debug:" & $data & @LF) http://stackoverflow.com/questions/19206834/command-prompt-and-autoit-stdinwrite <- credits to this stack overflow post
Unfortunately, on my end, my cmd just starts/stops with this prompt
Connecting with PsExec service on 192.1.123...Starting cmd on 192.168.1.123... cmd exited on 192.168.1.123 with error code 0. Any ideas how I can keep my shell open over psexec and still interact with it using AutoIT?
Any feed back would be amazing! Thanks!
When I run a program in remote vm virtualbix machine windows 7 64 bit with psexec from my current machine. It is working fine in system context. C:\Users\kirud01>"C:\Software\application packaging\PsTools\PsExec.exe" -s -i -d "\\erwin-pc" -c -f "C:\Build\delete.exe" But when I run the same in user context i.e., without -s parameter. The screen is getting freezed in the remote machine. Could you please help me on this. If possible any alternatives for PSEXEC in AutoIT code itself.
I've been using autoit for about a year now and overall it's been great despite my limited understanding of all of its features. I have several scripts that run on virtual machines that have been running smoothly for several months without any issues. Recently, I had to create new virtual machines and migrate my scripts over and now I am getting errors that I can't seem to repeat, but seem to happen at least once a day with all of my executables that were flawless before.
The error that I keep getting is:
Line [this number varies per script] (File "[path to my executable]"); Error: variable must be of type object.
I never received this error before until I moved everything to the new VMs, and when I rerun my scripts after clearing the error everything seems to work and run fine until hours later or sometimes the next day. I am assuming that that the root cause may be in some kind of settings on the VM itself since it is happening nearly across the board, but I have no idea where to even look. These are running on Windows 7, which is what they were running on before I had any errors.
The only consistent include used in these scripts is IE.au3
Has anyone run into a similar problem or can maybe point me in the right direction. I am at the point of pulling hair out trying to resolve this. I have even rewritten and re-compiled the scripts to see if somehow the executables got corrupted, but that didn't help.