I've been trying to solve the problem that Chris Iverson was having in this other Stackoverflow question.
I want to launch SFC
(the System File Checker tool) programatically.
It works on Windows XP:
private void RunSfc()
{
ProcessStartInfo startInfo = new ProcessStartInfo("cmd", "/K sfc.exe /scannow");
System.Diagnostics.Process.Start(startInfo);
}
Other variants that do work under Windows XP:
//Launch SFC directly
ProcessStartInfo startInfo = new ProcessStartInfo("sfc.exe", "/scannow");
System.Diagnostics.Process.Start(startInfo);
//Use full path to SFC
String sfcPath = Path.Combine(Environment.GetFolderPath(Environment.SpecialFolder.System), "sfc.exe");
ProcessStartInfo startInfo = new ProcessStartInfo(sfcPath, "/scannow");
The same code fails on Windows 7 (with the launching program running as an administrator). The console window appears, but SFC gives the error:
Windows Resource Protection could not start the repair service.
But if i manually run sfc /scannow
from a separate elevated command prompt, it works:
So there is obviously something strange happening with Windows Vista/7/8. i don't know what, exactly. But it's likely related to UAC, UIPI, session 0 isoloation, or the fact that console windows were run by CSRSS
But still, i don't understand the issue.
It would have been nice to solve Chris's issue, in the off chance that i want to do what he did.
And remember: My code already is running as an administrator. I right-click and Launch as administrator:
That doesn't mean the issue is not some other subtle issue related to UAC, but it's not due to the fact that i'm running as a standard user.
Code in WinForms application
private void button1_Click(object sender, EventArgs e)
{
RunSfc();
}
32-bit fails
Turns out there is a 32-bit version of cmd.exe
and a 32-bit version of sfc.exe
:
- C:\Windows\SysWOW64\cmd.exe
- C:\Windows\SysWOW64\sfc.exe
If you run an elevated 32-bit cmd, neither the 32-bit nor 64-bit version of sfc will work.
So the conundrum becomes how to launch the 64-bit cmd.exe
from a 32-bit process. Which probably means the conundrum becomes how to find the the 64-bit version of cmd.exe
from a 32-bit process, given:
- you may not be on a 64-bit machine
- you might already be running a 64-bit process
- Windows likes to fake the names of the
System32
folder based on the bit-ness of your process