We Keep Coding

Running remote batch file with PsExec and C#

I'm trying to run a remote batch file - already located on the remote machine - using PsExec, called via Process in C#. I've confirmed that all required files already exist, but believe I may have a problem with my syntax, as the redirected output indicates that it can't find the file specified.
The machine against which PsExec runs is dynamic, which is the myArray[0].MachineName value (this pulls in without issue).
wsStopProcess.StartInfo.FileName = #"C:\Windows\system32\PsExec.exe";
wsStopProcess.StartInfo.Arguments = #" \\" + myArray[0].MachineName + #"D:\stopprofile.bat";
wsStopProcess.StartInfo.UseShellExecute = false;
wsStopProcess.StartInfo.CreateNoWindow = true;
wsStopProcess.StartInfo.RedirectStandardOutput = true;
wsStopProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
wsStopProcess.Start();
Any ideas on what appears to be formatted incorrectly? I'm guessing it's too many backslashes (or not enough!) somewhere.

I think the main problem is you do not have a space between the two arguments.
Try this:
wsStopProcess.StartInfo.Arguments = #"\\" + myArray[0].MachineName + #" D:\stopprofile.bat";
I would also warn you that I could not get psexec to work 100%, despite trying many different things.

Try this:
wsStopProcess.StartInfo.Arguments = #"\\" + myArray[0].MachineName + #" D$\stopprofile.bat";
So instead of using : try $ sign. Also setting breakpoint on the above line while debugging will help you to see the exact path.

C# running Process weird stuff

no error. no exception. Second and Third produce a file f[1]/[2]. but not first. why? I verify using debug that the command is good. and using the command I capture from debug , cut and past to command line, I can produce the file[f0].
string[] f = new string[4];
f[0] = "SNICKER.reg.txt";
f[1] = "SNDIS.reg.txt";
f[2] = "SNICS.reg.txt";
f[3] = "Ssmf.xml";
//First
Run_Process("REG", "EXPORT HKEY_LOCAL_MACHINE\\SOFTWARE\\sridge\\Snicker " + f[0] + " /y");
//Second
Run_Process("REG", "EXPORT HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\SNDIS " + f[1] + " /y");
//Third
Run_Process("REG", "EXPORT HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\SClass " + f[2] + " /y");
private static void Run_Process(string exe_name, string arg)
{
Process myProcess = new Process();
try
{
myProcess.StartInfo.UseShellExecute = false;
myProcess.StartInfo.FileName = exe_name;
//myProcess.StartInfo.Arguments = "/C getLH.exe > feed.txt";
myProcess.StartInfo.Arguments = arg;
myProcess.StartInfo.CreateNoWindow = true;
myProcess.Start();
myProcess.WaitForExit();
}
catch (Exception ep)
{
Console.WriteLine(exe_name + " " + arg + ". Error: " + ep.Message);
}
}

When your app runs on a 64bit OS and you try to access the registry you could end up reading the values in the wrong folders.
This happens when you compile for x86 Platform, and thus your code is emitted as 32bit code.
In this scenario the registry redirector kicks in and changes your hand made registry paths that point to folders inside HKLM\SOFTWARE to HKLM\SOFTWARE\Wow6432Node.
The reasoning behind this behavior is complex and you could try to read something here
Said that, I still cannot understand really well what happen when we put in this scenario the REG program executed as a process launched from an application built with AnyCPU. This application should be executed as a 64bit code but, for some reason, the REG program executed is the 32 bit version (yes, there are two version of REG.EXE, one in system32 and one in SysWow64) and this version search your data in the wrong path. Perhaps this is related to the current value of the PATH environment variable.
As a side note. One of the worst decision ever made by Microsoft is to allow applications to store their configuration data in the registry. I really suggest to change this behavior, if possible
UPDATE
I can confirm that on a 64bit OS, a console application compiled as AnyCPU running the code that executes the REG.EXE command as above launches the 32bit version of REG.EXE from the WINDOWS\SYSWOW64. I have checked with ProcMon and I cannot explain why this happens. It is not related to the PATH env variable because I have only the path to C:\WINDOWS\SYSTEM32

Check out Process.start: how to get the output? and try to use that method to see the output of your command. I don't think there will be any exception, because it will only catch the exception of that block of code, not the exception of outside program that you attempt to run.

On a Windows machine is there a way to programmatically find out which application is responsible for opening files with a particular extension?

On a Windows machine, is there a way to programmatically find out which application is responsible for opening files with a particular extension? Suppose I want to find out programmatically which application is responsible for opening .PDF files. (don't care if you have C# or VB.NET code)

Well, you will start out by looking in the registry in the following position:
HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts.pdf\OpenWithList
There will be one or more keys from a and onwards, which point to the program used for opening a file of that type:
using Microsoft.Win32;
var key = Registry.CurrentUser
.OpenSubKey("Software")
.OpenSubKey("Microsoft")
.OpenSubKey("Windows")
.OpenSubKey("CurrentVersion")
.OpenSubKey("Explorer")
.OpenSubKey("FileExts")
.OpenSubKey(".doc")
.OpenSubKey("OpenWithList");
var firstProgram = key.GetValue("a"); // E.g. Winword.exe
You might want to split the assignment to key into several statements with null checks ;-)
Hope this helps!

The command-line command ASSOC finds file associations, and the command FTYPE finds actions assigned to them:
C:\> assoc .docx
.docx=Word.Document.12
C:\> ftype Word.Document.12
Word.Document.12="C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE" /n /dde
You can probably invoke them programmatically from any script.
From C#, you'd want to do something like this:
private string ShellCommand(string command)
{
var psi = new ProcessStartInfo("cmd", "/c " + command) {
RedirectStandardOutput = true,
CreateNoWindow = true
};
var p = Process.Start(psi);
return p.StandardOutput.ReadToEnd();
}
private string FindDefaultProgram(string extension)
{
assoc = ShellCommand("assoc " + extension).Split('=')[1];
program = ShellCommand("ftype " + assoc).Split('=')[1];
return program;
}
Haven't tested any of this, so take it with a grain of salt, but this should get you on the right track.

I won’t give you code but rather tell you where this information is stored – I’m sure you can figure out the rest on your own :)
So, all that data is stored inside the registry, in HKEY_CLASSES_ROOT. Taking .pdf as an example, there is a key .pdf which contains AcroExch.Document as it’s default value (on my setup at least).
Again in HKEY_CLASSES_ROOT there is a key AcroExch.Document\Shell\Open\Command and that one contains "C:\Program Files (x86)\Adobe\Acrobat 8.0\Acrobat\Acrobat.exe" "%1" as its value. And that’s what is being used on my computer to open a PDF file.

How to get the exact path of notepad.exe in order to associate a file extension

I need to associate a file extension I have created “.rulog” with notepad.exe as part of a setup project installation for a windows 7 machine (it’s here since we require admin privileges to write to the registry).
Basically I need to obtain programmatically the exact path of the notepad.exe. Now, I understand that it typically lives in C:\Windows\system32. This is part of PATH system environment variable, so I guess I could loop through all the PATH variables and test if “notepad.exe” exists by combining “notepad.exe” with the current path using File.Exists. However this feels very clumsy.
Essentially I need to add an entry to
Computer\HKEY_CLASSES_ROOT\.rulog\shell\open\command\
with the value of the path of notepad.
Incidentally I can see that .txt in:
Computer\HKEY_CLASSES_ROOT\.txt\ShellNew
has a value for ItemName of
“#%SystemRoot%\system32\notepad.exe,-470”
Perhaps I can just copy this value? Or is this dangerous?(e.g. does not exist).

You can use:
Environment.GetEnvironmentVariable("windir") + "\\system32\\notepad.exe";
Or even easier:
Environment.SystemDirectory + "\\notepad.exe";
That way it doesn't matter which drive the os is on.

Copying the value with %systemroot% should be just fine. If it works for the OS, it should work for you!

Fool-proof solution:
string NotepadPath = Environment.SystemDirectory + "\\notepad.exe";
if (System.IO.File.Exists(NotepadPath))
{
Microsoft.Win32.Registry.SetValue("HKEY_CLASSES_ROOT\\.rulog\\shell\\open\\command\\", "", NotepadPath + " %1");
}
else
{
//do something else or throw new ApplicationException("Notepad not found!");
}

Network COPY Cmds within C# - File Not Found?

I'm trying to copy a file over to a networked folder on a mapped drive. I tested out COPY in my command line which worked, so I thought I'd try automating the process within C#.
ProcessStartInfo PInfo;
Process P;
PInfo = new ProcessStartInfo("COPY \"" + "c:\\test\\test.txt" + "\" \"" + "w:\\test\\what.txt" + "\"", #"/Z");
PInfo.CreateNoWindow = false; //nowindow
PInfo.UseShellExecute = true; //use shell
P = Process.Start(PInfo);
P.WaitForExit(5000); //give it some time to finish
P.Close();
Raises an exception : System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
What am I missing? Would I have to add anything else to the command parameters?
I've tried File.Copy but it doesn't appear to work (File.Exists("<mappeddriveletter>:\\folder\\file.txt");) brings up false.

This SO post contains an example
Run Command Prompt Commands
how to do it right. You need to call cmd.exe with /c copy as a parameter.

Well, for the technical bit: copy in itself is not an executable, but merely a command interpreted by cmd. So basically, you'd have to start cmd.exe as a process, and pass it a flag that makes it run the copy command (which you'll also have to supply as a parameter).
Anyways, I'd side with Promit and recommend looking into File.Copy or something similar.
e: Ah, missed your comment on Promit's answer when I posted this.

Wouldn't it be a lot easier to use File.Copy ?