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 -iruns the process interactively on the remote machine, so everything including the console I/O happens in the respective session on the remote machine.The
-ibehavior does in fact make sense. Suppose for example that you ran a batch file which required user input e.g. had apauseorset /p. With-ithat 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 \\localhostandpsexecwithout a computer name at all. This one appears to be an undocumentedpsexecquirk, 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.