We Keep Coding

Batch script calling robocopy in Process won't terminate

If process.Kill() is called from another thread or even another program, the process never comes out of WaitForExit() if the batch script used robocopy.exe until it is finished as if it wasn't killed.
Robocopy.exe is called from the batch script. Every other script or program ends as you'd expect.
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "batch.bat";
startInfo.UseShellExecute = false;
startInfo.CreateNoWindow = true;
startInfo.RedirectStandardOutput = true;
startInfo.OutputDataReceived += CaptureHandler;
startInfo.RedirectStandardError = true;
startInfo.ErrorDataReceived += CaptureHandler;
process.Start();
process.BeginOutputReadLine();
process.BeginErrorReadLine();
process.WaitForExit();
The batch script looks like:
#echo off
call "robocopy.exe" "somedir" "somedest" /mir /fp /ndl /njh /njs /ns
I have a feeling it has to do with the output handlers.
I tried using process.CancelErrorRead and process.CancelOutputRead() as well after the Kill() call and before, no luck.
Oddly, if you use process.WaitForExit(timeout) overload, it will return true immediately after Kill() from the other thread. However, it's lying. The process is still running! If you try process.WaitForExit() again, as per the MSDN doc, it will still wait for the process to finish despite HasExited saying true.
To ensure that asynchronous event handling has been completed, call the WaitForExit() overload that takes no parameter after receiving a true from this overload.
https://msdn.microsoft.com/en-us/library/ty0d8k56(v=vs.110).aspx

You are successfully killing the batch processor (cmd.exe) but doing so won't kill robocopy, which is a separate process.
It doesn't seem to be documented, but when we look at the .NET source code it turns out that the Process.WaitForExit() method doesn't just wait for the process to exit, it also waits for end-of-file on the standard output and standard error streams. In this scenario, that means that it waits for robocopy to finish even after the batch processor has been killed.
(The overload of Process.WaitForExit with a timeout does not have this extra logic.)
I think this constitutes a bug in the .NET framework. At the very least, it should be documented.
As a workaround, you can use .HasExited and/or the version of WaitForExit with a timeout to determine whether the process has exited or not. Of course, in your scenario you might prefer to wait for grandchild processes, in which case your code is already behaving as desired.

I ran into the same problem. In my case, dropping the /mt switch from the RoboCopy argument list seemed to fix the issue.

Having followed up on Harry Johnston's helpful answer, I found that the process completes normally when you avoid RedirectStandardOutput = true. If this isn't an acceptable solution I found that using robocopy's /LOG:"C:\logs\robocopy.txt" switch to send its standard output to an external log file also works (although you lose the ability to get the file/directory log output from the process object itself).

Looks like right now the only way to do this without the application knowing to terminate Robocopy.exe specifically is to do kill the children of the script process before killing the script itself:
Kill process tree programmatically in C#
/// <summary>
/// Kill a process, and all of its children, grandchildren, etc.
/// </summary>
/// <param name="pid">Process ID.</param>
private static void KillProcessAndChildren(int pid)
{
ManagementObjectSearcher searcher = new ManagementObjectSearcher
("Select * From Win32_Process Where ParentProcessID=" + pid);
ManagementObjectCollection moc = searcher.Get();
foreach (ManagementObject mo in moc)
{
KillProcessAndChildren(Convert.ToInt32(mo["ProcessID"]));
}
try
{
Process proc = Process.GetProcessById(pid);
proc.Kill();
}
catch (ArgumentException)
{
// Process already exited.
}
}

Running commands in CMD as administrator

Rules that i need to hold on to are the following:
run command prompt command as administrator
change directory (path is always the same)
run command net start something
Any thoughts on how can i do this programatically using C# ?
Just for the record i am running console application built in .net 4.0
I am using this function
private static void commandtorun(string commandexecuted)
{
string currentstatus;
ProcessStartInfo startInfo = new ProcessStartInfo();
Process myprocess = new Process();
try
{
startInfo.FileName = "cmd"; //
startInfo.RedirectStandardInput = true;
startInfo.RedirectStandardOutput = true;
startInfo.UseShellExecute = false; //'required to redirect
//startInfo.CreateNoWindow = true; // '<---- creates no window, obviously
myprocess.StartInfo = startInfo; //
myprocess.Start(); //
System.IO.StreamReader SR;
System.IO.StreamWriter SW;
Thread.Sleep(200);
SR = myprocess.StandardOutput;
SW = myprocess.StandardInput;
SW.WriteLine(commandexecuted); // 'the command you wish to run.....
SW.WriteLine("exit"); // 'exits command prompt window
Thread.Sleep(200);
currentstatus = SR.ReadToEnd();
SW.Close();
SR.Close();
}
catch (Exception e)
{
Console.WriteLine("{0} Exception caught.", e);
Console.ReadLine();
}
// throw new NotImplementedException();
}
and i get access is denied when i call the function using this command:
commandtorun(#"cd c:\Program Files (x86)\folder1\folder2"); // change the folder because cmd always runs on different path
commandtorun("net start something"); run the COMMAND
I tried to run both commands in one statement but got the same error.

There are lots of problems here.
You want to run the other process elevated, but your code does not take steps to make that happen. In order to do that you need to invoke your process with the runas verb, and UseShellExecute set to true. But you also want to re-direct which is why you set UseShellExecute to false.
I see no compelling reason to redirect, so I think you can use true for UseShellExecute. You are pumping an exit command into cmd.exe to terminate the process. You don't need to do that. Simply pass cmd.exe the /c argument and the process will close when it is done.
These changes will allow you to remove those calls to Sleep(). Any time you call Sleep() you should ask yourself why you are doing it and if it can be avoided. Very few problems have Sleep() as the optimum solution.
You are trying to specify the working directory by executing cd. That again is the wrong way to do it. You can specify the working directory in the ProcessStartInfo object. That's how you should do it.
Your design has you executing each command in a separate process. That's a really poor way to go. You want to execute all the commands one after the other in a single instance of cmd.exe. Put the commands into a .bat or .cmd file and get cmd.exe to process that.
Imagine if you carried on processing each command as a separate process. How would the second process remember the working directory change that you made? Would you really want your user to see a UAC dialog for each separate command?
Having said all of that though, you are going about this the wrong way. You are just trying to start a service. Yes, you do that with net start when you are working in the command line. But from a program you use the service API to start a service. In other words I believe that you should throw away all of this code and call the service API.

How to wait until MSTSC.exe exits

I have created a management application that also allows to quickly access a remote desktop session to remote machines. I need to wait until the process ends, so I can close the VPN connection to the remote server. Everything works fine, except waiting for the process to end.
The following code is being used to start the MSTSC process and wait until it ends:
var process = new Process
{
StartInfo = new ProcessStartInfo("mstsc.exe"),
EnableRaisingEvents = true
};
process.Exited += (o, e) => Console.WriteLine("Process stopped.");
process.Start();
Console.ReadLine();
The Exited event is raised almost immediately after the program starts. When I replace mstsc.exe with notepad.exe everything works as expected. I thought that MSTSC might fork itself and abort the initial process.
But it is possible to wait for MSTSC to end using the following command (from the commandline):
start /wait mstsc.exe
This command doesn't return until I exit the remote desktop session. Given that information I replaced my code with this:
var process = new Process
{
StartInfo = new ProcessStartInfo("cmd.exe"),
Arguments = "/c start /wait mstsc.exe",
EnableRaisingEvents = true
};
process.Exited += (o, e) => Console.WriteLine("Process stopped.");
process.Start();
Console.ReadLine();
This would run CMD.exe and it will issue the start /wait mstsc.exe command. If that ends, the CMD process ends as well and I'm fine (with a nasty workaround, but okay). Unfortunately, this doesn't happen. The CMD process terminates immediately. Somebody knows what I am doing wrong?

process.WaitForExit();
Won't work because mstsc on start opens new copy of itself and closes original.
process.WaitForExit();
process = Process.GetProcessesByName(process.ProcessName).First();
process.WaitForExit();
Will work but it's awful workaround.
Update 1:
It seems that mstsc closes original process but NOT it's output stream!
So you can wait for process StandardOutput to close.
var process = new Process
{
StartInfo = new ProcessStartInfo("mstsc.exe") { UseShellExecute = false, RedirectStandardOutput = true }
};
process.Start();
process.StandardOutput.ReadToEnd(); //This will wait for stream to close.
Or if you don't want to block current thread:
var process = new Process
{
StartInfo = new ProcessStartInfo("mstsc.exe") { UseShellExecute = false, RedirectStandardOutput = true }
};
process.Start();
var outputResultPromise = process.StandardOutput.ReadToEndAsync();
outputResultPromise.ContinueWith(o=> Console.WriteLine("Stream closed"));
Console.ReadLine();

Here is the link at MSDN about starting mstsc,
It might be answer to your problem with mstsc closing immediately after running (raising Exited event). Try changing in Visual Studio target platform to AnyCPU.
Let's say your machine is 64bit Windows, your app is 32bit. The app runs 32bit mstsc. 32bit mstsc detects that Windows is 64bit, tries to close itself and run 64bit mstsc (Exited event is raised at that moment even though mstsc starts GUI window).
Changing target platform solved my issue.

There are multiple MSTSC processes running, so it's difficult to wait for one. What I don't understand is that CMD.EXE can do it when I use the start /wait command.

this worked with me:
process.Start();
Thread.Sleep(2000);
while(getNumProcesses() > 0)
process.WaitForExit();
private static int getNumProcesses()
{
Process[] myProcesses = Process.GetProcessesByName("mstsc");
return myProcesses.Length;
}

You cannot wait for mstsc.exe process. Say exactly, you cannot simply wait for end of remote desktop. When I observed mstsc.exe process by Process Monitor, mstsc passed his work to svchost, mstsc.exe ended, but remote desktop was still run.
But I wrote script for remoting application.
Script remoteCmd.cmd starts remoteApplication, remote machine creates a temp file ( \\tsclient\c..\temp\xxx) and remoteCmd.cmd waits until temp file exists.
See
https://github.com/turzik/WindowsScripts/tree/master/remoteApp

You need to call WaitForExit() after you call Start():
process.Start();
process.WaitForExit();
This overload causes the current thread to wait indefinitely to wait until the process exits. There's also an overload that allows you to specify the number of milliseconds you'd like to wait.

Understanding how to control stdout using System.Diagnostics.Process

I see several questions about how to launch processes and push data into stdin, but not how to control where their output goes.
First here is my current code, run from a console mode C# application:
// Prepare the process to run
ProcessStartInfo start = new ProcessStartInfo();
// Enter in the command line arguments, everything you would enter after the executable name itself
start.Arguments = " -";
// Enter the executable to run, including the complete path
start.FileName = "doxygen.exe";
// Do you want to show a console window?
start.WindowStyle = ProcessWindowStyle.Normal;
start.CreateNoWindow = false;
start.RedirectStandardInput = true;
start.UseShellExecute = false;
// Run the external process & wait for it to finish
using (Process proc = Process.Start(start))
{
//doxygenProperties is just a dictionary
foreach (string key in doxygenProperties.Keys)
proc.StandardInput.WriteLine(key+" = "+doxygenProperties[key]);
proc.StandardInput.Close();
proc.WaitForExit();
// Retrieve the app's exit code
int exitCode = proc.ExitCode;
}
What happens when I run this is I do not see any new window (though I think I should) and all of doxygen.exe's stdout is printed to my app's console window.
What I would like to happen is one of two things:
Doxygen is launched in a visible window, and I can see its stdout in that window, not in my app's window.
Doxygen is launched in a hidden window, and it's stdout is written to a log file.
How can I achieve these?
In addition, why am I not getting a separate window for the spawned process, and why is the spawned process writing output to my window not its own?

One thing that you can do is use RedirectStandardOutput and instead of using WaitForExit you can use ReadToEnd
ProcessStartInfo start = new ProcessStartInfo();
start.RedirectStandardOutput = true;
//make other adjustments to start
Process p = new Process();
p.StartInfo = start;
p.Start();
string output = p.StandardOutput.ReadToEnd();
and then you can use string output at your leisure
If you want to get output in real-time the p.StandardOutput property has methods that allow you to get the output asynchronously. I don't know all the details to it offhand, I've only used it once before, but there's plenty of literature out there if you search for it.
Also be careful when redirecting both StandardOutput and StandardError at the same time, If they're long enough, it is possible for that to cause deadlocks.

You need to do two things:
1) Indicate that you want the standard output of the process to be directed to your app by setting the RedirectStandardOuput property to true in the process.
2) BEFORE the call to WaitForExit, start capturing the output:
string sOutput = p.StandardOutput.ReadToEnd();
If you do not start reading the output before calling wait for exit, you can encounter a deadlock.
However, it is important to know that standard output will only capture output information, not anything written to the standard error stream of the app.
In order to capture both streams of information, you can hook the process's OutputDataReceived and ErrorDataReceived events and write the event data directly into a log file or store it in a class property for use after the process has completed.

PsExec v 1.98 Output Redirection Issue

I dont think any of the previous questions on this topic gave an answer for this issue. I use psexec to execute a remote exe file . I am getting the output of the exe file when i run it in command line. psexec.exe \\machine C:\somename.exe.
When i use C sharp Process Execution it either hangs or it doesnt redirect the output. For some exe's it timesout and for some Redirected standard Output is empty and Error contains Exe exited with code 0. Is there any way to capture the output ?
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName =GetPsExecPath();
startInfo.Arguments = arguments;
Debug.WriteLine(arguments);
startInfo.UseShellExecute = false;
startInfo.RedirectStandardError = true;
startInfo.RedirectStandardOutput = true;
startInfo.CreateNoWindow = true;
Process process = new Process();
process.StartInfo = startInfo;
process.Start();
process.WaitForExit();
error = process.StandardError.ReadToEnd();
output = process.StandardOutput.ReadToEnd();
Debug.WriteLine(error);
Debug.WriteLine(output);
process.close();
Edit: Soln
So the issue is primarily cause Psexec throws a lot of other things into the stderr and hence the order in which we read them, whtever it may be leads to deadlock if we use ReadToEnd(). So if we use BeginOutputReadLine it works like a charm!

This code snippet has very high odds for causing deadlock. Because you first read StandardError, then StandardOutput. Which means that process.StandardOutput.ReadToEnd() isn't going to get called until the process exits. Which means that psexec won't be able to flush its stdout output buffer when it fills up with enough characters. Which means that it will block and thus never terminate. Deadlock city.
You'll have much better odds if you swap the two calls, most programs send the bulk of output to stdout. However with still non-zero odds for deadlock if psexec writes a lot of characters to stderr for some reason. You eliminate that entirely by using BeginOutputReadLine and BeginErrorReadLine instead.