Im trying to launch a .exe file that is nested within the program files (x86) folder structure. i have already used the standard RunAs Syntax and found that it fails to launch the application. I have switched to Run and that seems to work. My issue is I have to use RunAs as the applicaton would need to run under a completely different account. The Current logged in user is a Local User on the machine, however, the application must be run as a domain user. The Machine is domain connected.
have tried the following:
RunAs("username","logonpassword", $RUN_LOGON_PROFILE, "D:\Program Files (x86)\Vendor\Application Name\Exe Location\Executable.exe") The above fails to launch, there are no errors or syntax issues, it just does nothing when the variables are replaced for the correct values.
I did the same using the Run command
Run("D:\Program Files (x86)\Vendor\Application Name\Exe Location\Executable.exe") That seems to work fine, but runs in local user context. Any thoughts? Could it be a local Machine rights issue? Or have i missed something glaring in my script
The Run command on my machine suddenly stopped execution.
Anyone of you facing the same issue?
#include <AutoItConstants.au3> #include <FileConstants.au3.> #RequireAdmin $ExeName = FileOpenDialog("Select AutoIt executable", @ScriptDir & "\", "(*.exe)", $FD_FILEMUSTEXIST) If not @error Then If FileExists($ExeName) Then $iPID = Run($ExeName, "", @SW_HIDE, $STDIN_CHILD + $STDOUT_CHILD) If @error Then msgbox(0,"Failed", "Failed execution with @error: " & @error) EndIf Else Msgbox(0,"", "File does not exist") EndIf EndIf The above code always fails to execute the executable file. It was working perfect and stopped working now.
I have tried adding the files and folders to windows defender exclusion list and uninstalling the anti virus but still no luck.
OS: Windows 10 - 64 bit
for a script to display PDF files I'd like to simply use the default program for PDF files, so I used "ShellExecute(<pdf-file-full-path>)" to open these files.
The result for *SOME* of the workstations is, that the Adobe Reader starts up with asking for its language. (English/German). When starting AcroRd32.exe through "ShellExecute()", this "choose your language" dialog is showing up *ALWAYS*.
Just to have mentioned it: Process Explorer is presenting this command line, it looks the same for both, PCs with and without that question "Choose Language? [English|German]"
"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.exe" --channel=4680.0.860715181 --type=renderer "\\pc0009\Y_DRV_H\Daten\TIF\08\32\G000110832_Freigegeben.idw.pdf"
The next approach I thought of was to use Foxit Portable (instead of Acrord32.exe), started from a Network Drive, but it's starting up ugly slowly...
So I tried to "Run()" instead to "ShellExecute()" the Adobe Reader. Now the result looks more stange, the "select your language" dialog shows up every now and then, but not always for the Win7 installations affected.
If I place a "msgbox()" just in front of the "run()" command, it seems never to show this "select your language" dialog.
If I take out this MsgBox() the "select your language" dialog shows up sometimes.
When I "ClipPut()" the run command prior the "Run()" and paste that one to a CMD box, then it seems to *NEVER* happen, that this "select your language" dialog shows up.
"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.exe" "\\pc0009\Y_DRV_H\Daten\TIF\08\32\G000110832_Freigegeben.idw.pdf" $AcroRead='"C:\Program Files (x86)\Adobe\Reader 11.0\Reader\AcroRd32.exe"' $PDF='"Y:\Temp\DRV_H\Daten\TIF\33\85\153385_Freigegeben.dwg.pdf"' MsgBox(0,"Values",$AcroRead & @CRLF & $PDF,1) $MyCommand=$AcroRead & " " & $PDF ClipPut($MyCommand) Run($MyCommand)
It looks like, that this "--channel=... --type=renderer" parameters are always fact for the AcroRd32.exe instance, that is opening the PDF to be displayed. The Instance opening the "PDF Display GUI" seems to always be a child process of another AcroRd32.exe process.
Any clue, what's going on "backstage" here? How to avoid this "Choose your language" dialog? Or maybe someone can mention a different "portable" PDF viewer, I could use for this purpose?
Any suggestions appreciated, regards, Rudi.
Hi, I have a software which has a 'run file'-ie; when i double click on that file, the input file of the software is run by the software. I wish to double click/execute this run file using autoit. how do i achieve this. i opened the software and it shows the input file and run file in same folder, i will put my autoitscript file too in same location. how do i simulate double clicking the run file (using its file name, say - abc.run ). I entered the following lines to make software window active - it became active, dont know how to go forward
controlclick("program title","abc.run",1000,"primary",2) ; 1000 is ctrl id
I've written several scripts with the following sequence:
Execute a program using Run w/stdout+stderr captured Typically processes all the files in one directory tree to populate a second tree Execute a second program (also with Run) to monitor the products of the first program and Display a progress bar (percentage of output files complete) Also monitor the first program's process and exit when it terminates The script then calls ProcessWaitClose (no timeout) on the first program's process and Checks the first program's results Kills the monitor program if it hasn't already exited on its own. Sometimes, ProcessWaitClose returns 1 with @error = 0 and @extended = 0xCCCCCCCC (actually, 0xFFFFFFFFCCCCCCCC), which seems ambiguous: the documentation says that @error = non-zero and @extended = 0xCC... means an invalid PID (unclear what the return value is), and 1 is returned for non-existent processes (but no mention of @extended). The 1/0/0xCC... result seems to occur when the first program exits very quickly (with or without an error). Since the exit value is not available, the script scans the program's output and tries to determine whether it ran successfully. This has gotten complicated and unreliable.
I've now implemented a much simpler approach that works for most cases:
Modify the monitor program so that it ignores the other program's process (the monitor always gets killed by the script anyway) Execute the monitor program first using Run, then execute the processing program with RunWait When RunWait returns, the child process exit value is available, so the script can ignore its output (which isn't available anyway) If the monitor program is still running, kill it. Remaining Issue
However, there are still a couple of cases where it's necessary to get both the exit value from the processing program and its output. Since RunWait doesn't capture stdout and stderr for the parent script, it's looking like I'll have to call RunWait and redirect the 2 streams to a temp file and then scan it. Also, to do the redirect, I think I'll have to use @ComSpec to execute the processing program, which adds an undesired layer.
Does anybody have a better (cleaner) way to handle these cases?