We are in the need of spawning processes from session 0 isolation to a logged in user in session 1.
This task is done by using psexec
, this happens entirely on the same machine, but I am unable to get the output of the child process to be displayed in psexec. Since this runs on a build-server I don't want to redirect output to a file, etc
Here is a sample call which does not work:
C:\>PsExec.exe cmd.exe -i 1 -u user -p pwd /C echo foo
The result shows nowhere any "foo"
PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
cmd.exe exited with error code 0.
One thing that works, but is currently useless is to ommit -i
and add \\localhost
:
C:\>PsExec.exe \\localhost cmd.exe /C echo foo
returns:
PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
foo
cmd.exe exited on localhost with error code 0.
But when I specify session 1, it breaks. This:
C:\>PsExec.exe cmd.exe -i 1 -u user -p pwd \\localhost /C echo foo
again shows no foo
for me.
Again: The intention is not to tee
or redirect echo foo
into some file and then perform type myfile.log
as a second step but to receive the output in the original psexec.
We are bound to session 1 as we need a Direct 3D context, having the service configured with "Allow interacting with the desktop" does not help here.
I don't think that what you are asking is possible.
psexec -i
runs the process interactively on the remote machine, so everything including the console I/O happens in the respective session on the remote machine.The
-i
behavior does in fact make sense. Suppose for example that you ran a batch file which required user input e.g. had apause
orset /p
. With-i
that input would need to be entered on the target machine, not on the machine where you runpsexec
. Similarly, the output goes (only) to the remote machine.The other part of your question is the difference between
psexec \\localhost
andpsexec
without a computer name at all. This one appears to be an undocumentedpsexec
quirk, which has been noticed and reported before, for example (with a bit of reading between the lines) at Redirect output of process started locally with PSExec.