I'm trying to open up a an .exe program that is on a remote computer through my main desktop using a batch file and psexec.exe.
I have been able to remotely kill programs using pskill, but when I run the command line required to open a program the window opens up for a fraction of a second before closing down due to an error. The error code it gives is: -2146232576.
I've tried Googling what this error actually is but I can't find much. Does anyone know for sure what this error relates to?
This is the batch file I made that does not work:
cd c:\Users\[local user]\Downloads\PSTools\
psexec.exe \\computername -u [user] -p [password] "C:\Users\[user]\Desktop\SQAUtilities\utlity.exe"
Note: I found a question on StackOverflow which is similar, but has a different error code:
psexec error code -1073740771
And also:
Error code 1073741502 when running psexec through TeamCity
This one has an answer that says the error is "a low-level .NET initialization error, the CLR cannot get loaded":
visual studio 2010: error code -2146232576 (0x80131700)
This is likely the exit code of utility.exe that PSExec is passing back to you, not an error generated by PSExec.
Here's one possible source:
FIX: 0x80131700 error code when starting or configuring the Enterprise Single Sign-On Service
I don't know what utility.exe does, but if it attempts to perform Windows authentication, PSExec might be blocking it. In my experience, PSExec deliberately blocks some actions (under certain circumstances). For example, if you don't use a username/password, all attempts to access remote shares fails instantly.
Since you're providing some creds, this might not be the precise problem, but if utility.exe requires access to your Kerberos tickets or something, they might not be accessible in a PSExec session.
Things to Try
Do you know that this command (utility.exe) works on the remote machines as your user when run interactively (GUI logon)? Surely you've already tried that, but just to make sure...
Is the build directory on the remote computer or is it a share on a third machine? The method of accessing those files might require more steps within PSExec (like mapping a drive, etc.).
If the program absolutely requires a GUI, you may have to allow it to interact with a specific GUI session using the -i parameter of PSExec. You might try logging into the remote machine, running the command with -i 2 (or whatever session qwinsta tells you you're using—2 is common for remote desktop connections) and see if it opens any error dialogs that are more informative.
You might try running ProcMon on the remote machine while you run the PSExec command and seeing if there are any ACCESS_DENIED or other failures that it notices.
Got the same error while remotely running an EXE install file (not copying it local). As near as I can tell this is an error related to insufficient permissions. For me, the simple addition of the -S switch (to run as SYSTEM) fixed my problem.
Why this works I'm not sure - I'd always thought SYSTEM was strictly limited to local resources, yet the EXE I'm running is located on a network share.
Hope this helps someone.
I got the same error lately and found out why I get this.
You must make a local copy of "utility.exe" on the remote computer for before launching it via PsExec.
for /f "usebackq delims=" %%i in ("d:\utility\remote_computers.txt") do (
xcopy "D:\utility\utility.exe" "\\%%i\d$\" && psexec \\%%i -u %%i\administrator -p password cmd /c "/i \\%%i\d$\utility.exe"
)
Pause
Related
I am getting the following error and the process of creating a DB gets terminated automatically while creating a DB in PostgreSQL.
ORACLE_HOME must be set and %ORACLE_HOME%\database must be writeable
createdb terminated unsucessfully.
How to create a Database in Postgres using createdb command?
Running the same command on the Git Bash also doesn't work, the process doesn't getting terminated and it showing as in the picture below.
I wanted to leave this as a comment but I cannot, there are several issues that may be happening here, the first that comes to mind is that your command prompt is not showing as admin. This can also be a path issue, because sometimes cmd will not recognize paths for software except when you try to use it on the folder its installed. Another common issue with Windows is that sometimes you want to run the GUI software instead of cmd, and if you absolutely need cmd try powershell with admin rights.
The error it gives makes me believe that its either a path error or a user rights error, I also agree with the comments. My suggestion if you keep having issues like this who are either depending on your windows path system or your system requirements in general is to try using Anaconda or (conda), this will give you a clean environment to properly see what you did wrong.
How do i do this?
i've tried all i can think of.
Browsing for my .exe file i want to run.
run a bat file
writing forcedos.exe in program textbox and path to my bat file in command line parameters textbox
Why cant it just work with an normal exe?
and i know it should run a program because it can restart the service correctly.
EDIT
Application: test.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.Exception
This is my latest try to make it work.
the script has the code
Dim objShell
Set objShell = WScript.CreateObject( "WScript.Shell" )
objShell.Run("iexplore")
Set objShell = Nothing
Now the script opens internet explorer if i run the cmd command
wscript.exe "C:\asfh.vbs"
The "run a program" recovery option for when a service crashes runs the specified executable in the same way as the service, i.e., it runs in session 0 (and so is affected by session 0 isolation, see also related questions) and it runs with the same security context as the service.
This means that it can't interact directly with the user (you can display a GUI, but nobody will see it) but it also restricts what the executable or script can do. For example, some shell API functions will not work properly unless the user account has been interactively logged in at some point. In the example script you posted, the script itself is probably running, but is unable to launch Internet Explorer because IE is only designed to run in an interactive session.
Provided you restrict yourself to basic functionality, it should all work as expected. (There is no master list that I know of describing what functionality is safe to use in a service context, but it is usually easy to guess. You can resort to trial and error if necessary!)
Also note that as far as I know forcedos.exe is no longer present in modern versions of Windows. If you want to run a batch file, you can specify cmd.exe as the application and /c myscript.bat as the command line parameters.
I have been using psexec successfully for a couple of years now. Recently, I have had some major issues when running on several remote machines. Calling psexec from a simple batch file seems to completely crash (restart) the computer, leaving the bewildered pc locked on the DELL startup screen (same issue on 3 separate computers).
Anyone having a similar issue? This seems to occur when using the old and new version of psexec (May 2014 release v2.11). Could this be a windows update issue (Windows 7 64bit)?
FYI, here's the process I call from a .bat file (run_model.cmd contains local exe).. note: This opens up in a loop, so that I get a new window for each model run.
start cmd.exe /c psexec -i -s \\VOSTRO460-4 \\VOSTRO460-4\model\run_model.cmd
If not, can anyone suggest an alternative to psexec which works as simply as this?
Cheers
Neil
I have a batch file which uses gpresult /v and saves the output in a text file and copy that text file to a shared folder. This batch when i run on my local machine works perfectly fine but once i deploy it through SCCM it says can not open file with error code 4. I dont know what is wrong in the file.
the code is Like this:
#echo off
gpresult /v >%computername%.txt
xcopy %computername%.txt \some path
Error 4 is "The system cannot open the file.", as if the path is invalid or the open() fails for some other reason.
Do you know what directory the program is running in (CWD)?
That's where the results of gpresult are going (if the output redirection succeeds).
gpresult is not going to produce meaningful user-level data for the SYSTEM user.
Perhaps you should use gpresult /v scope computer.
Why are you using xcopy when you're only copying one file? xcopy really only has added value (over copy) if you are copying directories.
xcopy's behavior changes depending on how you specify the target. If the target ends with the directory separator (backslash), xcopy treats it like it's a directory. If it doesn't and the target doesn't exist, xcopy asks you what to do, which causes automated processes to pause indefinitely waiting for user input.
SCCM Programs Run as 'NT Authority\SYSTEM'
When SCCM (2007) runs a program, the program doesn't run as a regular user. It runs as the highest privilege user (sort of), SYSTEM.
This account is not a regular account, and many settings and environment variables that exist and are predictable for a regular user are different or do not exist for SYSTEM.
One particularly frustrating "feature" of the SYSTEM account's profile is that it is nestled away under %WINDIR%\System32, and so it is subject to filesystem redirection whenever you refer to anything relative to the profile.
Try this: use psexec -s (sysinternals) to get shell access as the SYSTEM account and run the command in that environment to see how it behaves. This is as close as we can get to an environment like the one SCCM programs run under.
When SCCM runs the command, the CWD will probably be somewhere under %WINDIR%\SysWOW64\CCM\ and may be invoked with the 32-bit version of CMD.EXE.
I have a question in regards to something similar to this. So I have an uninstall bat that runs. Due to the vendors uninstall it causes a force close of the windows explorer UI. So in haste to solve that issue I added a call to open explorer.exe. There is a problem with this as someone pointed out to me. Actually as soon as he said I knew exactly what he was saying and where he was going with his statement. Calling explorer.exe would be fine except that the bat is running under the system context not the user so when explorer is restarted it will start under the guise of the system desktop profile not the user's. I know there is way to still run under the guise of system but to restart explorer under the currently logged in user's profile.
I have implemented automation through batch file to login into a remote server and run a series of commands therin. My batch file contents are as follows:
#ECHO OFF
ECHO 1 -^> Connect 2 Server
ECHO 2 -^> Quit
SET /p ID=Enter Choice :
IF "%ID%"=="1" start "" C:\work\putty.exe -load SessionName -l UserName -pw Password -m cmd.txt
IF "%ID%"=="2" exit
My cmd.txt file contains the following commands:
su superuser
password
ssh server
password
su MyID
password
The batch successfully connects to the server; but it fails to retain the session. Any tweak would be appreciated.
For my own use I verified what -m switch does for putty
The -m option performs a similar function to the ‘Remote command’ box in the SSH panel of the PuTTY configuration box (see section 4.18.1). However, the -m option expects to be given a local file name, and it will read a command from that file.
With some servers (particularly Unix systems), you can even put multiple lines in this file and execute more than one command in sequence, or a whole shell script; but this is arguably an abuse, and cannot be expected to work on all servers. In particular, it is known not to work with certain ‘embedded’ servers, such as Cisco routers.
Roughly what I guessed. I think what's happening is that your commands might be running ok, but it terminates the session when done (which is also default behaviour for ssh [command] on unix. To get around this you could try running 'bash' at the end to start a terminal as that user, which should stay running until you exit. If this doesn't work you could try running 'sleep 10' to see if the session stays running longer - should verify that's the problem we're dealing with.
Much as stackoverflow demands strictly the answer to the question, which I hope I've provided above. I feel in this case it would be remiss to not flag the serious security concerns I'd have on what you're doing. I would maintain that you shouldn't answer a question about doing something securely (with ssh and root passwords involved) without covering potential security pitfalls.
What you're doing seems like a bad idea because:
it makes a file with two unencrypted root-capable passwords to anyone who finds that file
this script is also giving you root access by default, which isn't a safe way to operate. Ever accidentally type rm -r in the wrong window?
Also, someone messing with your second hop (by say, replacing the ssh server with a script to run ssh but log passwords) would get the password to the third hop with root privileges.
SSH keys should do away with using passwords to log on. Use them.
SSH port forwarding lets you also skip sshing from the second hop - instead just tunnel through it (I'm guessing the third box isn't internet accessible), again using ssh keys lets you skip passwords.
the first 'su superuser' shouldn't be necessary unless your permissions don't allow you ssh (does an ssh_allow group exist on that box?), which might be the problem you should actually fix - not being a member of the group allowed to use SSH.