Develop Reference

Process cannot find file specified

I have the following issue:
I have a C# app that runs as a 32-bit Application on my 64-Bit Machine. This application opens a process and starts wbadmin to make a backup of the C drive.
Now: when I call enter "wbadmin" in the command line wbadmin works and shows lists all its commands.
In my c# app when i do
ProcessStartInfo info = new ProcessStartInfo("wbadmin", $"start backup -backupTarget:{destinationDrive} -include:C: -quiet -vssCopy")
{
UseShellExecute = false
};
Process p = new Process()
{
StartInfo = info,
EnableRaisingEvents = true
};
p.Start();
it tells me that the file specified cannot be found.
I did some research and I think my app is looking for the wbadmin in the WOW64 folder, where it cant find it because it is inside the System32 Folder.
How do I tell my program to use the correct wbadmin.exe in the correct location?
Do I HAVE to run the app as a 64-bit application for it to work?
If so how would i support 32-bit architecture?
Thanks

Thanks to #PavelAnikhouski for providing me with the correct answer.
I had to specify the path to sysnative.

C# start Child Process (in CMD window) as Administrator with custom environment variables

I have a program which wraps around some Windows SDK executables and opens them in a separate CMD window.
Process process = new Process();
process.StartInfo.FileName = "cmd.exe";
process.StartInfo.Arguments = "/C signtool.exe [args] & pause";
process.StartInfo.Verb = "runas";
process.Start();
Right now, I have the Windows SDK folder added to my system's Path environment variable. Is there a way to programmatically add the Windows SDK folder to the Path environment variable of the user OR run the process with the SDK folder added to the Path variable of that particular CMD window?
This is the folder I need added to each CMD window's Path variable:
C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86
This sub-process must run as administrator. It does not need to receive the output of the child process.

Use a ProcessStartInfo and its Environment property instance to set this up.
var startInfo = new ProcessStartInfo();
var defaultPath = startInfo.Environment["PATH"];
var newPath = "C:\\Program Files (x86)\\Windows Kits\\10\\bin\\10.0.16299.0\\x86" + ";" + defaultPath;
startInfo.FileName = "cmd.exe";
startInfo.Arguments = "/c set > D:\\env.txt";
startInfo.Verb = "runas";
startInfo.Environment["PATH"] = newPath;
startInfo.UseShellExecute = false; // required to use Environment variables
Process.Start(startInfo);

There are a number of hurdles to overcome here.
As you've discovered, the Environment and EnvironmentVariables properties of ProcessStartInfo cannot be used when UseShellExecute is true (an exception is thrown). But Verb only works when UseShellExecute is false (the Verb is silently ignored). This comes down to the differences between CreateProcess (the core Win32 function) and ShellExecute/ShellExecuteEx (the shell function).
As another commenter suggested, you might try setting the environment in the parent process and then starting the child process. However, elevated processes don't inherit the environment from a non-elevated parent process.
I would be willing to bet that there is a way to do what you want using a correct series of Win32 calls to get an elevated token and then calling something like CreateProcessAsUser. I am also willing to bet it'll be a little error-prone and ugly in C# because of the necessary struct marshaling. So instead of trying to figure that out for you, I'll offer another suggestion:
Just programmatically write a batch script that sets the environment and invokes signtool.exe. You can then invoke that batch script using the runas verb as you're currently doing.

Unhandled C# Exception during an LPR process

I'm creating a C# app that should use lpr.exe and pass arguments to it. I'm currently trying to do it this way:
DirectoryInfo filePathDirectory = new DirectoryInfo(filePath);
Process a = new Process();
a.StartInfo.FileName = #"C:\Windows\System32\lpr.exe";
a.StartInfo.Arguments = "-SServerName.Domain.net -Plp " + "\"" + filePathDirectory + "\"";
a.StartInfo.UseShellExecute = false;
a.Start();
a.WaitForExit();
But whenever I get to a.Start(); I get an unhandled Win32 exception which states "The system cannot find the file specified". This is really confusing me becuase, at first I thought it was my arguments, but turns out, I can pass the exact same arguments from a VB app and get it to work.
Update 1:
The VB code that works is:
Dim RPname As String
RPname = FileName.ToString
Dim a As New Process
a.StartInfo.FileName = "C:\Windows\system32\lpr.exe"
a.StartInfo.Arguments = "-SServerName.Domain.net -Plp " & Chr(34) & RPname & Chr(34)
a.StartInfo.UseShellExecute = False
a.Start()
a.WaitForExit()
What's more is that my issue doesn't seem to be with the arguments statement, as I can comment it out and I still receive the error.
Update 2:
The error I get at the start of the process is: The system cannot find the file specified. I do not get the error if I change the FileName to "C:\Windows\System32\cmd.exe", that works fine...

You are using a DirectoryInfo object in your c# code and concetanate it. Try to change your code to this:
try
{
DirectoryInfo filePathDirectory = new DirectoryInfo(filePath);
Process a = new Process();
a.StartInfo.FileName = #"C:\Windows\syswow64\lpr.exe"; // ADAPTED to the new path!! worked!
// use filePathDirectory.FullName!!
a.StartInfo.Arguments = "-SServerName.Domain.net -Plp " + "\"" + filePathDirectory.FullName + "\"";
// or change it to - found it more readable imo
a.StartInfo.Arguments = string.Format(
"-SServerName.Domain.net -Plp \"{0}\"",
filePathDirectory.FullName);
a.StartInfo.UseShellExecute = false;
a.Start();
a.WaitForExit();
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
EDIT
Found the solution to your problem! First - credits go to #Sundeep according to his given answer. He pointet me to a webSite indicating that
Yes I have, but 64-bit files located in c:\windows\system32 is not
seen by a 32-bit command prompt (c:\windows\syswow64\cmd.exe) which is
launched when call at batch file from a 32-bit application.
And furthermore
... trying to get a 32 bit program to launch
lpr.exe inside of Windows 2008 R2. It fails because lpr.exe does not
exist in the 32 bit view of the O/S. ...
For a work-around, I copied lpr*.* from a 32 bit O/S system32 folder
into SYSWOW64 on the 2008 R2 machine...

Change your code to this:
DirectoryInfo filePathDirectory = new DirectoryInfo(filePath);
Process a = new Process();
a.StartInfo.FileName = #"C:\Windows\Sysnative\lpr.exe";
a.StartInfo.Arguments = "-SServerName.Domain.net -Plp " + "\"" + filePathDirectory + "\"";
a.StartInfo.UseShellExecute = false;
a.Start();
a.WaitForExit();
Pilgerstorfer Franz' explanation is exactly right, but especially in an environment like mine, going and moving the location of the lpr.exe on every machine is a lot of work. The simple solution is to use the sysnative directory.
http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm
The 'Sysnative' folder is invisible in Windows Explorer If you
start Windows Explorer and open the Windows folder on your hard disk,
you may notice that the Sysnative folder is not shown. The main reason
to this is that Windows Explorer is a 64-bit program (when run in a
64-bit Windows), and the Sysnative folder is only visible and
accessible from 32-bit software. If 64-bit software need access to the
64-bit system folder in Windows, the only option is to use the
System32 folder name (for example: C:\Windows\System32).
Using the 'Sysnative' folder will help you access 64-bit tools from
32-bit code Some tools in a 64-bit Windows only exist in a 64-bit
version; there is no 32-bit version available. And some of these tools
are located in the 64-bit System32 folder. One example is the nbtstat
tool that is used to help troubleshoot NetBIOS name resolution
problems. If you try to run the nbtstat tool from 32-bit code (for
example from an application or from script) and use a path like
C:\Windows\System32, you will get a "File not found" error. The file
can not be found; although Windows Explorer shows that the nbtstat
program file actually is located in the C:\Windows\System32 folder.
The solution to this (somewhat confusing) problem is to include the
virtual Sysnative folder in the folder path when you want to run the
tool. For example like this: C:\Windows\Sysnative\nbtstat.exe The
file path above will give you access to the 64-bit nbtstat tool from a
32-bit application or from a 32-bit script. We recommend you to read
this article / blog post (at Scottie’s Tech.Info) to get more details
about this.

Why does my IL generated Assembly, ilasm.exe called by C#, need UAC?

I'm trying to compile an IL Code to an Assembly. The ilasm.exe should get called by my C# Application. I'm invoking the ilasm.exe through an ProcessStartInfo Instance. The generation of the PE works fine and my Assembly is working.
My problem is that the files that were created by my application, afterwards need administrator privileges to be executed.
If I call ilasm.exe manually from command line, no admin rights are needed.
Used ilasm.exe command:
ilasm.exe /qui /output="c:\test\newFile.exe" <path to il file>
My Application calling the ilasm.exe:
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.CreateNoWindow = false;
startInfo.UseShellExecute = false;
startInfo.FileName = #"C:\Windows\Microsoft.NET\Framework\v4.0.30319\ilasm.exe";
startInfo.WindowStyle = ProcessWindowStyle.Hidden;
startInfo.Arguments = ilFilePath + " /qui /output=" + outputPath + "testFile.exe";
try
{
using (Process exeProcess = Process.Start(startInfo))
{
exeProcess.WaitForExit();
}
}
catch
{
// Log error.
}
Am I doing anything wrong? Do I need to specify anything else when calling another Process from C#?
I'm running my Application and the commandline without admin rights.

It's requiring UAC because you're not supplying a path to a writable location in output, so it's trying to write to the same folder ilasm is in (or the current folder for your app).
A non-admin user doesn't have write access to anything under %WINDIR% (the Windows folder) or %ProgramFiles%, so it's asking for elevation to a user that does have write access to the folder.

What is patchFile?
This comment by #Chris is relevant to this puzzle, I don't see it in the question. You are probably dealing with a difficult problem that Microsoft needed to solve with UAC. Supporting old programs that need UAC privileges but don't ask for it because they were written before Vista. Like installers. And patch programs.
My crystal ball says that your actual program name is not newFile.exe like your question says but has a name like "update.exe" or "patch.exe". And furthermore, it isn't obvious either, that you don't include a manifest in the program you generated. A manifest that says that the program is Vista aware with the <requestedExecutionLevel> element. And furthermore, also not obvious, that when you run this from the command line by hand that you use another name for the .exe.
That's a lot of guesses, but put them together and it makes sense: Windows goes "aha! Old program, sounds like it is going to want to write to .exe files in a restricted directory. Better display the UAC prompt".

c# application doesn't perform batch file command correctly

public void runBatchfile(String batchfilename)
{
try
{
ProcessStartInfo processInfo = new ProcessStartInfo(batchfilename);
processInfo.UseShellExecute = false;
Process batchProcess = new Process();
batchProcess.StartInfo = processInfo;
batchProcess.StartInfo.CreateNoWindow = true;
batchProcess.Start();
batchProcess.WaitForExit();
}
catch (Exception r) { }
}
runBatchfile(#"c:\lol.bat");
lol.bat contains these 2 lines
dir c:\ /s /b > c:\filelist.txt
exit
and when I run my code all it does is creating a filelist.txt file, but doesn't actually perform the rest of the command, which does work if I manually insert it into CMD.
Btw I've tried making the extension .cmd and I also tried without the exit command, without any other results.
please help me :)

On my Windows 7 64-bit machine with Visual Studio 2010, running this code straight from the IDE doesn't do anything whatsoever.
On a hunch that it might have something to do with permission to write to the root directory of drive C:, I tried running the .exe directly from an Explorer window with admin rights (right-click, Run as Administrator) and that worked.
I'd say it's a permission problem.
Maybe you could redirect the output to a file located elsewhere?
update:
I changed the batch file so that the dir command gets redirected to my desktop and it runs just fine.

I've had issues with this as well when calling from C#. The workaround that I usually use is to physically allow it to show the window when running the command. Not sure why this makes a difference but it has worked for me in the past.