I am running one batch file every few seconds to do timesync with server using following code:
Process process = new Process();
process.StartInfo.WorkingDirectory = Environment.GetFolderPath(Environment.SpecialFolder.System);
process.StartInfo.FileName = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "cmd.exe");
process.StartInfo.Arguments = #"/C C:\TimeSync.bat";
process.StartInfo.CreateNoWindow = true;
process.StartInfo.UseShellExecute = false;
process.StartInfo.WindowStyle = ProcessWindowStyle.Minimized;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.UserName = "username";
SecureString pwd = new SecureString();
Char[] pwdCharacters = "password".ToCharArray();
foreach (char t in pwdCharacters)
{
pwd.AppendChar(t);
}
process.StartInfo.Password = pwd;
process.Start();
string output = process.StandardOutput.ReadToEnd();
The problem is it flashes the command windows on the screen which I don't want. How can I prevent that?
One behavior I have seen is if I run the same code with UseShellExecute = true and don't provide username and password then the command window doesn't flash.
So basically I want to run .bat file using c# code as different user silently.
Because you are passing a user name and password, the CreateNoWindow parameters are not respected. This is a feature (i.e. bug) in windows. Here's the five year old connect details:
http://connect.microsoft.com/VisualStudio/feedback/details/98476/cmd-windows-shows-using-process-with-createnowindow-when-using-username-password-option
Process.Start() calls advapi32.dll's
CreateProcessWithLogonW in the event
that a user supplies a username and
password, and CreateProcessWithLogonW
always opens a new window.
Unfortunately, there is no workaround
for this behavior
An excellent overview of the create no window option is given here:
http://blogs.msdn.com/b/jmstall/archive/2006/09/28/createnowindow.aspx
which also points out errors in the msdn documentation on this topic.
And there's a very good overview in this stackoverflow answer:
How to hide cmd window while running a batch file?
In the end, I think you want to create a separate little app that you call out to only once, and it runs the whole time, as the escalated user. It can then perform the time sync as often as you want, in the same manner as you've described above, but without having to specify username and password. Thus there will only be one 'flash' of a console window for the entire duration of the application.
Hope this helps
lb
Change your line:
process.StartInfo.WindowStyle = ProcessWindowStyle.Minimized;
to
process.StartInfo.WindowStyle =
ProcessWindowStyle.Hidden;
That will hide the window and never show it.
Hope that helps!
Phil
Did you try to just specify:
process.StartInfo.CreateNoWindow=true;
?
You could use impersonation. I've written an impersonation class that implements the IDisposable interface and is rather straightforward to use, I hope.
Related
I am writing a C# application that uses WinForms.
I want to launch my own shell as an Admin then use Stream Writer to run some commands.
I am not doing any thing malicious. It's to fix the connection issues with another internal application (for work). The other team isn't willing to fix their program so they provided us with a command line fix. However I have to run this on many PC's so I am learning C# and trying to build something that I would use.
As soon as myProcess.Start executes, a black box appears then quickly disappears before going to the next line.
public void ProcessStartAsAdmin(string command)
{
string cname = Environment.UserDomainName + "\\" + Environment.UserName;
Process myProcess = new Process();
myProcess.StartInfo.FileName = #"C:\Windows\System32\CMD.exe";
myProcess.StartInfo.Verb = #"runas";
//myProcess.StartInfo.Arguments = command;
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.RedirectStandardInput = true;
myProcess.StartInfo.RedirectStandardError = true;
myProcess.StartInfo.RedirectStandardOutput = true;
myProcess.Start();
StreamWriter myStreamWriter = myProcess.StandardInput;
String inputText;
string resetConnection = "C:\\APP\\application.exe /reset /server:example.com /uid:" + cname + " /pwd:" + textBoxPassword.Text.Trim();
myStreamWriter.WriteLine(resetConnection);
myStreamWriter.Close();
myProcess.WaitForExit();
myProcess.Close();
}
If I am doing anything wrong, please let me know. If I can use a better technique, I'm open for suggestions.
Thanks.
I don't know whether this is the only issue, but there's no space between these two arguments:
/uid:" + cname + "/pwd:"
it should be:
/uid:" + cname + " /pwd:"
string resetConnection = "C:\\APP\application.exe
\a is illegal. You should write \\ (it seems you know it, and missed).
Edit:
The screen that your see is empty, because of you chose to redirect output.
What is probably happening is that the line has some error (or it's running time is very small), and you not see that.
Cancel temporary the output redirection, and the process closing, and see what happened.
Let's take a look at how you initialize the start info:
myProcess.StartInfo.Verb = #"runas";
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.RedirectStandardInput = true;
myProcess.StartInfo.RedirectStandardError = true;
myProcess.StartInfo.RedirectStandardOutput = true;
You are redirecting the standard input, output and error streams. The documentation for this says:
You must set UseShellExecute to false if you want to set RedirectStandardOutput to true. Otherwise, reading from the StandardOutput stream throws an exception.
And likewise for the other two standard streams. So, redirection implies that you must set UseShellExecute to false.
On the other hand, you wish the new process to be elevated. Which means that you want to use the runas verb.
The documentation does not say so, but the Verb property only has impact when UseShellExecute is set to true. So, requesting elevation implies that you must set UseShellExecute to true. There is no other way to request elevation for a new process. You have to pass through the ShellExecuteEx (or its relatives) with the runas verb and that forces you to set UseShellExecute to true.
So there are two conflicting requirements here. You've got no option at all over elevation I presume. You must elevate for this task. Which means you'll have to give up on redirection. I suppose the only other option would be for you to run the calling process elevated. That would mean that any child processes would also be elevated and there would be no need for runas and so you could set UseShellExecute to false.
However, I see no reason for redirection. You are only doing that, I think, so that you can send commands to the cmd process. Instead you can pass the commands as arguments, or place them in an external .bat or .cmd file. So if I were you I would stop redirecting, and set UseShellExecute to true, and take it from there.
I am trying to launch the default application registered for an extension specifying an additional argument:
ProcessStartInfo p = new ProcessStartInfo();
p.Arguments = "myargument";
p.FileName = "file.ext";
Process.Start(p);
The application starts correctly opening the specified file.
The problem is that it is getting just one parameter (the name of the file), totally ignoring the additional "Arguments".
Is it possible to do what I want?
Am I doing something wrong?
Thanks in advance for any help,
Paolo
I believe this is expected. Behind the scenes, Windows is finding the default application in the registry and creating a new process and passing your file name to it. I get the same behavior if I go to a command prompt and type "filename.ext argument", that my arguments are not passed to the application.
What you probably need to do is find the default application yourself by looking in the registry. Then you can start that process with arguments, instead of trying to start by filetype association. There is an answer here on how to find the default application in the registry:
Finding the default application for opening a particular file type on Windows
what exactly is your "argument", does it have spaces, backslash, etc?
Process process = new Process();
process.StartInfo.FileName = #"C:\process.exe";
process.StartInfo.Arguments = #"-r -d something else";
process.StartInfo.CreateNoWindow = false;
process.StartInfo.UseShellExecute = false;
process.Start();
Is there any reason why you cant start the app, then use the extension and arguments in your arguments?
I think an easier method is using the cmd command
void LaunchAssociatedProgram(string filename) {
Process.Start( #"cmd.exe", "/C start "+ filename );
}
EDIT:
I don't know if it works with arguments, but it is what I was looking for to launch an associated program...
Due to the joys of UAC, I need to open an elevated command prompt programmatically and then redirect the standard input so I can use the time command.
I can open the link (a .lnk file) if I use
Process ecp = System.Diagnostics.Process.Start("c:/ecp.lnk");
however, if I use this method, I can't redirect the standardIn.
If I use the StartProcessInformation method (which works wonderfully if you are calling an exe)
ProcessStartInfo processStartInfo = new ProcessStartInfo("c:/ecp.lnk");
processStartInfo.UseShellExecute = false;
processStartInfo.ErrorDialog = false;
processStartInfo.RedirectStandardError = true;
processStartInfo.RedirectStandardInput = true;
processStartInfo.RedirectStandardOutput = true;
Process process = new Process();
process.StartInfo = processStartInfo;
bool processStarted = process.Start();
StreamWriter inp = process.StandardInput;
StreamReader oup = process.StandardOutput;
StreamReader errorReader = process.StandardError;
process.WaitForExit();
I get the error message:
The specified executable is not a valid Win32 application.
Can anyone help me create an elevated command prompt which I can capture the standard input of? Or if anyone knows how to programatically escalate a command prompt?
In case no-one comes up with a better idea (pretty please), here is the work around one of the more devious in my office just came up with:
Copy cmd.exe (the link it pointing at this file)
Paste this file into a different directory
Rename the newly pasted file to something different
Set the permissions on this new file to Run As Administrator
You will still get the escalation dialog popping up, but at least you can capture the standardIn of this valid Win32 app!
I'm trying to run a Jscript task from a C# console application.
The Jscipt file is not mine so I can't change it. The script moves some files and this is what is causing the issues.
When I run the script manually, i.e. form the shell it executes correctly. When I try and run the script from my console application the bulk of the process runs but I get a ":Error = Permission denied" error when it tries to move the files.
I've tried every permutation of the Diagnostics.Process class that I can think of but I've had no luck.
My current code:
Process process = new Process();
process.StartInfo.WorkingDirectory = Path.GetDirectoryName((string)path);
process.StartInfo.FileName = #"cmd.exe";
process.StartInfo.Arguments = "/C " + (string)path;
process.StartInfo.UseShellExecute = false;
process.StartInfo.Verb = "runas";
process.StartInfo.LoadUserProfile = true;
process.StartInfo.Domain = "admin";
process.StartInfo.UserName = #"cardax_sync_test";
process.StartInfo.Password = GetSecureString("abc123");
process.Start();
process.WaitForExit();
Any ideas?
Thanx
Rookie Mistake!
I forgot to close the text reader that creates one of the input files for the jscript.
I'll submit this question for deletion when it get's old enough. Don't want more useless info clogging up the net!
I have a service that sometimes calls a batch file. The batch file takes 5-10 seconds to execute:
System.Diagnostics.Process proc = new System.Diagnostics.Process(); // Declare New Process
proc.StartInfo.FileName = fileName;
proc.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
proc.StartInfo.CreateNoWindow = true;
proc.Start();
proc.WaitForExit();
The file does exist and the code works when I run the same code in-console. However when it runs inside the service, it hangs up at WaitForExit(). I have to kill the batch file from the Process in order to continue. (I am certain the file exists, as I can see it in the processes list.)
How can I fix this hang-up?
Update #1:
Kevin's code allows me to get output. One of my batch files is still hanging.
"C:\EnterpriseDB\Postgres\8.3\bin\pg_dump.exe" -i -h localhost -p 5432 -U postgres -F p -a -D -v -f "c:\backupcasecocher\backupdateevent2008.sql" -t "\"public\".\"dateevent\"" "DbTest"
The other batch file is:
"C:\EnterpriseDB\Postgres\8.3\bin\vacuumdb.exe" -U postgres -d DbTest
I have checked the path and the postgresql path is fine. The output directory does exist and still works outside the service. Any ideas?
Update #2:
Instead of the path of the batch file, I wrote the "C:\EnterpriseDB\Postgres\8.3\bin\pg_dump.exe" for the proc.StartInfo.FileName and added all parameters to proc.StartInfo.Arguments. The results are unchanged, but I see the pg_dump.exe in the process window. Again this only happens inside the service.
Update #3:
I have run the service with a user in the administrator group, to no avail. I restored null for the service's username and password
Update #4:
I created a simple service to write a trace in the event log and execute a batch file that contains "dir" in it. It will now hang at proc.Start(); - I tried changing the Account from LocalSystem to User and I set the admnistrator user and password, still nothing.
Here is what i use to execute batch files:
proc.StartInfo.FileName = target;
proc.StartInfo.RedirectStandardError = true;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.UseShellExecute = false;
proc.Start();
proc.WaitForExit
(
(timeout <= 0)
? int.MaxValue : timeout * NO_MILLISECONDS_IN_A_SECOND *
NO_SECONDS_IN_A_MINUTE
);
errorMessage = proc.StandardError.ReadToEnd();
proc.WaitForExit();
outputMessage = proc.StandardOutput.ReadToEnd();
proc.WaitForExit();
I don't know if that will do the trick for you, but I don't have the problem of it hanging.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Diagnostics;
namespace VG
{
class VGe
{
[STAThread]
static void Main(string[] args)
{
Process proc = null;
try
{
string targetDir = string.Format(#"D:\adapters\setup");//this is where mybatch.bat lies
proc = new Process();
proc.StartInfo.WorkingDirectory = targetDir;
proc.StartInfo.FileName = "mybatch.bat";
proc.StartInfo.Arguments = string.Format("10");//this is argument
proc.StartInfo.CreateNoWindow = false;
proc.Start();
proc.WaitForExit();
}
catch (Exception ex)
{
Console.WriteLine("Exception Occurred :{0},{1}", ex.Message,ex.StackTrace.ToString());
}
}
}
}
string targetDir = string.Format(#"D:\");//PATH
proc = new Process();
proc.StartInfo.WorkingDirectory = targetDir;
proc.StartInfo.FileName = "GetFiles.bat";
proc.StartInfo.Arguments = string.Format("10");//argument
proc.StartInfo.CreateNoWindow = false;
proc.Start();
proc.WaitForExit();
Tested,works clear.
What does the batch file do? Are you certain the process is getting launched with enough privs to execute the batch file? Services can be limited in what they are allowed to do.
Also make sure if you are doing something like usin the copy command to overwrite a file that you do something like:
echo Y | copy foo.log c:\backup\
Also, make sure you are using full paths for the batch commands, etc. If the batch file is launching a GUI app in some sort of "Console" mode, that may be an issue too. Remember, services don't have a "Desktop" (unless you enable the "interact with desktop") to draw any kind of windows or message boxes to. In your program, you might want to open the stdout and stderr pipes and read from them during execution in case you are getting any error messages or anything.
WebServices are probably executing as the IUSR account, or the anonymous account, which ever, so that might be an issue for you. If it works when you run it in console, that's just the first step. :)
I don't recall if System.Diagnostics. are available only in debug or not. Probably not, but some of them might be. I'll have to check up on that for ya.
Hope this gives you some ideas.
Larry
pg_dump.exe is probably prompting for user input. Does this database require authentication? Are you relying on any ENVIRONMENT variables that won't be present for the service? I don't know pg_dump but what are the other possible reasons it would prompt for input?
The next step I would take is to fire up the debugger, and see if you can tell what the program is waiting on. If you are expierenced at debugging in assembly, you may be able to get an IDEA of what's happening using tools like ProcExp, FileMon, etc.
Being a windows SERVICE, and not a web service, makes quite a bit of difference. Anyways, have you tried my suggestion of setting the "Allow Service to interact with desktop"?
If you are desperate, you might try launching cmd.exe instead of your batch file. Then, using the cmd.exe's cmd line parameters, you can have IT start the batch file. This would probably give you a cmd prompt window to view the actual output, if you turn on the interact with desktop.
For complete help on cmd.exe, just type cmd /? at any command prompt.
Larry
Here is the solution. The solution is not clear because I have changed so many time the code and now it's working!
I have tried to use a Account of User, and it's not what worked. Use LocalSystem. Here is the code that execute, mostly what Kevin gave me.
System.Diagnostics.Process proc = new System.Diagnostics.Process();
proc.StartInfo.FileName = fileName;
proc.StartInfo.RedirectStandardError = true;
proc.StartInfo.RedirectStandardOutput = true;
proc.StartInfo.UseShellExecute = false;
proc.Start();
proc.WaitForExit();
output1 = proc.StandardError.ReadToEnd();
proc.WaitForExit();
output2 = proc.StandardOutput.ReadToEnd();
proc.WaitForExit();
Thank you all, I'll up-vote everybody and accept Kevin since he helps me since the beginning. Very weird because it works now...
Daok, it looks as if the only thing you changed was the timeout period on the initial WaitForExit(). You need to be VERY careful of that. If something DOES hang your service, it will NEVER return (and well, pretty much work like it has been for you thus far.. heh), but it won't be good for the end users...
Now, perhaps that you know what's causing this to hang, you can debug it further and find the full solution...
That, or spin this off in some thread that you can monitor, and kill if it hangs too long.
Just my 2 cents worth, which usually isn't a whole lot. ;)