Develop Reference

C# process being cancelled after Process.Start()

I'm trying to run Command Prompt commands from C# code.
After Process.Start() step is executed, console window shows
System error 1223 has occured. The operation was cancelled by the
user.
Error:
But, as you can see, I'm not cancelling the operation.
My Code:
Process process = new Process();
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.Arguments = $"/C NET USE {driveChar}: {URL}";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardInput = true;
process.Start(); // After this step, console window shows the above error
StreamWriter streamWriter = process.StandardInput;
streamWriter.WriteLine(username);
...
...
// remaining code
What is going wrong? Any ideas on resolving this error?
EDIT:
I don't actually need to redirect standard output, so I modified my code to only redirect standard input. But I'm still getting the same error.

This will work...I use /K switch as i don't want to terminate the CMDscreen and want to see the result..use /C if you need auto terminate
string strCmdText;
strCmdText = #"/K NET USE z: \\server\SharedFolderName";
System.Diagnostics.Process.Start("CMD.exe", strCmdText);
==========Result ============================

Running a cmd command from within my C# code

I'm currently hosting OSRM locally on my machine to build a routing application. When the application starts, a bool ServiceAvailable is checked with a test query to see if the application is available and running locally. I want to be able to start the OSRM application should this bool return false. I found a StackOverflow link with a similar issue and tried to implement it, but the application doesn't load. Here's my current code:
private void StartOSRMService()
{
Process process = new Process();
process.StartInfo.WorkingDirectory = #"C:\";
process.StartInfo.UseShellExecute = false;
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.Arguments = "/c cd users/james/desktop/osrm/osrm-backend/osrm_release";
process.StartInfo.Arguments = "/c osrm-routed wales-latest.osrm";
}
The method is ran but the service never starts. In other methods, my code breaks due to a Http.Web request error, due to the lack of the service.

You can try the following:
private void StartOSRMService()
{
var startInfo = new ProcessStartInfo(#"C:\users\james\desktop\osrm\osrm-backend\osrm_release\osrm-routed.exe");
startInfo.WorkingDirectory = #"C:\users\james\desktop\osrm\osrm-backend\osrm_release";
startInfo.UseShellExecute = false;
startInfo.Arguments = "wales-latest.osrm";
Process.Start(startInfo);
}
More info on Process.Start()
Also, based on your original StartInfo.Arguments, the "/C" tells to console to terminate after the command has been executed, thus, if the "osrm-routed" is the service that needs to run in the console, and the console is terminated, then the application itself will also terminate when the console terminates.

HandbrakeCLI wont automate via C# process

I am trying to automate HandbrakeCLI using C# via the System.Diagnostics.Process class. However, as long as my program is trying to run the process, it seems like the process never advances.
Here is my process setup:
Process process = new System.Diagnostics.Process();
ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.RedirectStandardOutput = true;
startInfo.RedirectStandardError = true;
startInfo.UseShellExecute = false;
startInfo.CreateNoWindow = true;
startInfo.FileName = parameters.HandbrakeLocation;
startInfo.Arguments = arguments;
process.StartInfo = startInfo;
process.Start();
string output = string.Empty;
while ((output = process.StandardOutput.ReadLine()) != null)
{
Debug.WriteLine(output);
}
process.WaitForExit();
HandbrakeCLI.exe does appear in my processes list. The Debug.WriteLine(output); line continually prints out "Encoding: task 1 of 1, 0.00 %" and the process never completes. If I kill my C# app then HandbrakeCLI instantly shoots up from 7,000k in memory to 145,000k and then does the encoding that I want it to do. Its like my C# app is holding it back.
I have tried to use Read() instead of ReadLine() and I have tried flushing the StandardOutput stream before and after the read with no success. I have a suspicion that since HandbrakeCLI overwrites stdout when it writes the encoding progress, that it won't act like a normal process when automated via C#.

I figured it out. I was redirecting stderr to my C# application, but not consuming it. The process was hanging until stderr was consumed.

How to open Putty Process without it opens in another window

using this Code
Process process = new Process();
// p.EnableRaisingEvents = true;
process.EnableRaisingEvents = true;
process.OutputDataReceived += new DataReceivedEventHandler(p_OutputDataReceived);
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.CreateNoWindow = true;
process.StartInfo.LoadUserProfile = false;
process.StartInfo.UseShellExecute = false;
process.StartInfo.FileName = #"C:\putty.exe"; ; // Gets or sets the application or document to start.
process.StartInfo.Arguments = "-serial com31 -sercfg 9600,8,n,1,N";//Gets or sets the set of command-line arguments to use when starting the application
Thread.Sleep(1000);
process.Start();//Starts (or reuses) the process resource that is specified by the StartInfo property of this Process component and associates it with the component.
process.BeginOutputReadLine();
process.WaitForExit(); // wait forever with ping
I'm trying to open putty in console application , but any timr I use it it opens in New windows and I cant get to output of the process using process.OutputDataReceived event
I'm using code very similar to this to open Iperf and it works fine
What am I missing here ?

Putty is not a console application and therefore does not provide output on it's stdout and stderr streams.
And since it is a windowed application it does not care whether you start it with the CreateNoWindow flag. Try and start notepad.exe with that flag, you will see it appearing obviously.
There is however a programm by the creators of Putty that provides the functionality you need.
It's called Plink.exe and you can download it on their homepage

Why won't "cmd.exe /C command" end when called via Process.Start()?

I'm trying to run a command via command prompt from an ASP.Net web application. I can see the process start in task manager on the web server, however the process just sits there and never exits nor does it run the commands I specified.
Process process = new Process();
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "cmd.exe";
startInfo.Arguments = "/C " +command;
startInfo.UserName = "myuser";
startInfo.UseShellExecute = false;
startInfo.RedirectStandardOutput = true;
startInfo.Domain = "mydomain";
startInfo.CreateNoWindow = true;
String pass = "mypass";
System.Security.SecureString secPass = new System.Security.SecureString();
foreach (char c in pass.ToCharArray())
{
secPass.AppendChar(c);
}
secPass.MakeReadOnly();
startInfo.Password = secPass;
process.StartInfo = startInfo;
process.Start();
//output = process.StandardOutput.ReadToEnd();
process.WaitForExit();
process.Close();
I've tried both with and without reading the standard output.
The application will hang on process.WaitForExit(); until I kill the process via task manager.

I think we need to understand what commands you are actually trying to process in order to determine what's going on. Also we need to know what OS the server is running.
For example, I did see in your comments where you tried "echo test > C:\test.txt" Under Windows Server 2008 (and Windows 7) the root directory requires administrator permissions in order to create files. If this is executing under IIS, my guess is that your IIS user isn't an administrator and you are getting security exceptions.
Also, a number of commands may require elevated priviledges due to UAC. I don't remember exactly, but I'm guessing that if those commands are being caught by UAC then the process is waiting for UAC confirmation... Which I believe you cannot supply via a command line.
This type of problem won't be seen if you log into the machine and execute it directly... unless you are logging in with the worker process user account.
So, the very first thing you need to do is figure out what it is you are trying to run and see if the user the worker process is executing under can even perform those actions. Security is there to protect you, so be careful about granting additional permissions to the user.
The reason why it might work on one machine versus another again depends on the OS's those machines are running and the configuration of the user the commands are executing under.
If this is truly a security issue, as I suspect, then you should post a question on serverfault.com to ask what permission sets you need to execute various commands under your worker process user.
You might look at the machines event logs to see if there were any warnings or errors thrown about the command. Sometimes things like this can show up there to give you a bit more information as to what happened.

Once passed to CMD, the control has passed to the shell. It's better to add a close it like this:
private void closeSubProcess()
{
Process[] currentProcesses = Process.GetProcesses();
foreach (Process p in currentProcesses)
{
string s = p.ProcessName;
s = s.ToLower();
if (s.CompareTo("YOURPROGRAMNAMEHERE") == 0)
{
p.CloseMainWindow();
p.Close();
}
}
}

I am calling cmd.exe to start a node module in Windows. npm obviously must be installed first, along with the node module I need, and then I can call the module with args in C#. Problem was, the cmd.exe would not shut off, I'd have to use Task Mgr (just like this question!).
//This requires npm, and the module installed by npm...
ProcessStartInfo psi = new ProcessStartInfo();
psi.FileName = "cmd.exe";
psi.WindowStyle = ProcessWindowStyle.Hidden;
psi.UseShellExecute = true; //closes command window
psi.Arguments = "/c <nodemodulename>" + file1 + ".txt " + file2 + ".log";
Process p = Process.Start(psi);
p.Close();
The /c argument was key to closing down cmd.exe. When I started out, I had put in the /K argument, which keeps the darned thing running. Solved. Hope this helps. (This is like ancient, but we always forget)