I used C# with a console program to create a new cmd process, did not redirect stdin or stdout, so I could type into the command line from here.
(I was having trouble using telnet from there, so this step was just an investigation.)
Able to type into the window and receive output.
When I switched to c:Windows\system32, typing dir te*.exe shows nothing.
In another command prompt I created directly, I see the file (telnet.exe).
Any suggestions about what is wrong?
{
ProcessStartInfo startInfo = new ProcessStartInfo(#"cmd.exe");
startInfo.UseShellExecute = false;
startInfo.CreateNoWindow = true;
startInfo.WindowStyle = ProcessWindowStyle.Normal;
startInfo.CreateNoWindow = false;
startInfo.Arguments = host;
using (Process p = new Process())
{
p.StartInfo = startInfo;
p.Start();
}
}
Since Windows 7, I believe, you have to install Telnet as a Windows Feature.
Here you have a guide to enable Telnet on Win 7, but it's applicable to Win 8.1 as well as Windows 10.
Just in case you can't read the site, the steps are:
Go to Control Panel -> Programs -> Turn Windows Features on or off -> Scroll down until you find the Telnet Client option
Based on the above article, looked at project build properties.
Platform target was set to x86.
Changing to "Any CPU" at least allows me to see the program!
BTW I have looked for the answer for several days before posting this, but in the margin in related - "C# New process created cannot access certain files" gave me the info - after I created this question
Thanks, heuristics!
This is a really devious one. When you are using windows explorer or opening a command prompt directly, you are starting a 64-bit process. When you are starting the "cmd.exe" with Process.Start(), you will get the same version as the process that's starting it. In your case, you are creating a 32-bit process, so you get the 32-bit version of the command prompt. If you change your project to create target x64, you will see the files!
Why is this so? Because, depending on whether you are accessing System32 through a 32-bit or 64-bit app, you will actually be accessing different System32 folders! For more on this, follow this link:
https://superuser.com/questions/330941/some-files-in-system32-not-accessible-outside-explorer-on-windows-7
Related
I'm trying to start an application called snort from a C# application, using System.Diagnostics.Process, and I need to capture its output. To achieve this, I've used the code below.
When I try to run this, I get an error which is related to loading the configuration file. I get this same error if I try to manually run the exe from a CMD without administrator privileges, so I think this is a permissions issue for the forked process, but I'm not entirely sure of that. However, I have tried the following, to no avail:
I have added to the C# application manifest (the C# application is definitely running as administrator).
I have tried using a username and password with Process.StartInfo
However, the error still remains. Also, for clarity: The process is started, I am receiving output in My OutputHandler method, etc -- the issue is with the forked exe, it is having a problem reading the specified configuration file.
The sample code is as follows:
var process = new Process();
process.StartInfo.FileName = #"C:\Snort\bin\snort.exe";
process.StartInfo.Arguments = #"-A console -i2 -c C:\Snort\etc\snort.conf -l C:\Snort\log\ -K ascii";
process.StartInfo.UseShellExecute = false;
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardError = true;
process.OutputDataReceived += new DataReceivedEventHandler(OutputHandler);
process.ErrorDataReceived += new DataReceivedEventHandler(OutputHandler);
process.Start();
process.BeginOutputReadLine();
process.BeginErrorReadLine();
process.WaitForExit();
This does start the required process, but as I mention that process (snort) then outputs an error when trying to read the configuration file (the same error I get if I try to manually run the same process from a CMD without admin rights--hence why I think the issue might be permissions-based).
Can anyone suggest anything else I might try to get around this. I do need to capture output, so (if I understand it correctly) the 'runas' verb doesn't help.
Thanks for your time.
I explored a few option and tried to continue on the path of permission and changed the application manifest file permission and replaced the standard permission file with:
requestedExecutionLevel level="requireAdministrator" uiAccess="false"
This did not change anything.
I am using windows 8.1 and when I visited the properties of the snort.exe file I changed the compatibility and run the application compatible with win 7 and ticked the box to run as administrator, it is now working fine.
snort.exe properties
Many Thanks to everybody
Ok, so I'm having an issue starting the the Windows XP mode VM through a c# program. The command I'm using is vmwindow -file "absolute path to vmcx file" , but the problem is that the command does not work with the cmd prompt that my program kicks off. So, it's very weird. I can go to command prompt on my computer and run this command on my computer and it works, but if i have the same command on my c# program, the command prompt that pops up tells me the "vmwindow" is not a recognized command. I even looked at the paths of each of the command prompts and they're different, but they still both contain "C:\Windows\system32\" which is where vmwindow.exe exists. So, I navigate on the command prompt window that my program populated and the file "vmwindow.exe" is not there, but if I open a command prompt window from my computer and navigate to that folder, it exists there. I can't think of anything else as I already made sure they're both running in administrator mode, and also i tried starting a bat file which contained that command instead of running the command directly. Hope anyone knows anything about this. Here is the code I'm using:
private void button1_Click(object sender, EventArgs e)
{
Process process = new System.Diagnostics.Process();
ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Normal;
startInfo.FileName = "cmd.exe";
startInfo.WorkingDirectory = #"<my path>";
startInfo.Arguments = "/k vmwindow.exe -file \"<path to vcmx file>\\Windows XP Mode.vmcx\"";
process.StartInfo = startInfo;
process.Start();
}
What you can do is using Powershell. It has a native integration for Hyper V control and is easy to call from c#
You can see all HV-cmdlets here
a simple command to start your machine would be
Start-VM "Windows 8.1 Pro" -Computername HV-Host1
// etcetc
Stop-VM "Windows 8.1 Pro" -Save
So this should be something like this in C#
using (PowerShell PowerShellInstance = PowerShell.Create())
{
PowerShellInstance.AddScript("Start-VM "Windows 8.1 Pro" -Computername HV-Host1");
}
Probably it's because of the bitness setting you compile your program with. ("Platform target" and "Prefer 32-bit" settings under the build tab of the project).
32 and 64 bit processes see different files under System32.
See https://stackoverflow.com/a/950011
I have this very simple program
Process process = new Process();
process.StartInfo.FileName = #"psexec";
process.Start();
But when I run it the debug says "The system cannot find the file specified"
If I have the same program and change "psexec" by "Notepad", it works and opens notepad.
Process process = new Process();
process.StartInfo.FileName = #"notepad";
process.Start();
This is weird because I have my psexec in the System32 and if run "psexec" using Windows-Run, it works.
Thank you in advance for any help.
Update: I specify the full path #="C:\Windows\System32\PSexec.exe" and It doesnt work. But If I move Psexec to, as example #"D:\psexec.exe" it works!!
Why coud this happen?
Running programs from c:\windows\system32 is troublesome on a 64-bit operating system. The workaround is Project + Properties, Build tab, change Platform target to AnyCPU. Or to copy the file also to c:\windows\syswow64.
Or to just not put it in the Windows directory, it is not an operating system specific file that belongs there. The appropriate place is the same directory as your EXE.
You can learn more about the File System Redirector in this MSDN article.
try specify the full path of 'psexec'
there is any property 'WorkingDirectory', which might help.
I need to write code to download and run a program, e.g. notepad++ (npp.5.9.3.Installer.exe) this can be found on the web.
I run it with the ProcessStartInfo class. However when I normally execute the notepad++ installer, it will show me a few steps before actually installing, like choose language, path etc.
Is there any way to programatically skip these steps, and install the software? I hope my question is clear. If it helps, I also attach the method that so far only starts the installer
private int RunFile()
{
ProcessStartInfo psi = new ProcessStartInfo(GetFileFullPath());
psi.WindowStyle = ProcessWindowStyle.Hidden;
psi.CreateNoWindow = true;
using (Process process = Process.Start(psi))
{
process.WaitForExit();
if (process.HasExited)
return process.ExitCode;
}
}
Shall I pass some arguments for this to work?
Thank you in advance.
Regards,
Use npp.5.9.3.Installer.exe /S for unattended installation of notepad++, and %ProgramFiles%\Notepad++\uninstall.exe /S for uninstall.
There are some installers which supports -s or -silent switches which means that when you install a software by passing -s switch to installer and it will silently install with default options. Try to find out whether your installer supports that or not
you have to drive the installation emulating the user. It is possible send kind of command(message) to the other window from a C# application
have a look at the below
http://social.msdn.microsoft.com/forums/en-US/winforms/thread/345d85e8-cc5f-4508-b3f2-74ee43521169/
Interact with other desktop-applications in windows using C# winforms
A wellwritten installer have options for silent installs with no user interface. If the installer is an .msi file there are options that can be passed to msiexec to make a silent install.
For other install systems there are sometimes options to. Automating installations without user involvement is a common task for system administrators, so if you have questions on a specific installation package I would suggerst asking at ServerFault or AppDeploy. Unfortunately there are many bad installation programs out there that doesn't support silent install.
This will ONLY depend on the installer (npp.5.9.3.Installer.exe). You have to search if the installer provides options that can be used in command line, such as silentinstall.
EDIT: You can use the /S (capital S) option for Notepad++ to perform a silent install.
I'm launching the path C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk via Process.Start, but it fails with The system cannot find the file specified.
The link shows up on a dir, so it exists.
Can it be permissions?
Notes:
The path is auto-discovered by iterating over the Start Menu directory.
I can launch it via explorer and command line.
Clarifications:
Code is as follows:
public void Execute() { Process.Start(_shortcut.FullName);}
_shortcut is of type FileInfo
_shortcut.Exists is true, so the file can be found
replacing _shortcut.FullName with the explicit path #"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk" has the same effect.
This is a WPF app using Caliburn and MEF.
Running as Administrator has the same effect.
This here on the other hand seems to work:
[Fact]
public void TestIisManager()
{
var path = new FileInfo(#"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk");
Process.Start(path.FullName);
}
It does seem to be a bit "environment" based.
Second clarification:
It seems to work in a Windows 7 x86 but not in a Windows 7 x64.
I ran into this recently. Windows Forms based solution, VS2013, x64 machine. Process.Start() could not launch applications via .lnk file. Using process explorer, it seemed that the target specified in the .lnk file was resolving incorrectly to c:\program files (x86)... instead of c:\program files... I followed Bruno's excellent advice, but then again my Target was already marked as "AnyCPU".
After some head scratching, it turned out there's a new compiler flag in VS11+ called "Prefer 32-bit" that was checked by default. This was forcing the EXE output to be 32-bit even though my OS was 64-bit and platform was set to AnyCPU. After I unchecked and recompiled, the problem was fixed.
More reading at: http://blogs.microsoft.co.il/sasha/2012/04/04/what-anycpu-really-means-as-of-net-45-and-visual-studio-11/
Found the issue.
The WPF application was compiled as x86 (all other dlls were compiled as AnyCPU), and when launching some executables or links in a 64 bit machine it failed.
Changing the "Platform Target" to AnyCPU fixes this.
This may not actually relate to your situation, but you can launch the IIS Manager by using
Process.Start("inetmgr.exe")
If you want to continue to use the shortcut, it will probably work if you start the process using a ProcessStartInfo and set ProcessStartInfo.UseShellExecute to true
Can you make sure that you are trying this from an STA thread? You can see whether the apartment state is a problem if the following sample succeeds:
using System;
using System.Diagnostics;
public class Program
{
// make sure to call Process.Start from an STA thread
[STAThread]
static void Main(string[] args)
{
Process.Start(#"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk");
}
}
Process.Start calls ShellExecute under the hood to run the file passed. As described by Raymond Chen, shell functions require an STA thread:
One possible reason why ShellExecute returns SE_ERR_ACCESSDENIED and ShellExecuteEx returns ERROR_ACCESS_DENIED
As stated already, you will see the "The system cannot find the file specified" error because Windows is looking for inetmgr.exe in ...\SysWOW64\intsrv\ (caused by file system redirection), but it only exists in ...\System32\intsrv\.
This is caused by your 32-bit executable attempting to launch a 64-bit executable. As suggested, not using a 32-bit executable will solve this, but for anyone who must build for 32-bit (a WiX installer bundle in my case), try the following.
Using the start menu LNK/shortcut to inetmgr.exe instead of the executable is a good start, but an extra level of distance is required. This can be provided by using explorer.exe, which can be launched from a 32-bit executable:
System.Diagnostics.ProcessStartInfo startInfo = new System.Diagnostics.ProcessStartInfo();
startInfo.FileName = "explorer.exe";
startInfo.Arguments = "/seperate /root,\"C:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Administrative Tools\\IIS Manager.lnk\"";
System.Diagnostics.Process process = new System.Diagnostics.Process();
process.StartInfo = startInfo;
process.Start();
It's a bit of a hack, but try launching it like this:
string path = #"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools\IIS Manager.lnk";
Process.Start("cmd.exe", String.Format("/k \"\"{0}\"\"",path));
Note the double quotes needed to save the spaces in the path.
That way, you might see a more precise error message and/or walk around in the command environment afterwards to see what is wrong with the path.