locked
Problem starting programs with Process.Start() RRS feed

  • Question

  • Hi, I'm having a problem running programs with Process.Start(). I want to create a tool for running windows tools/programs such as cmd, powershell, task manager, ect... The problem is that some of the programs run a 32-bit and I want them to run in 64-bit, and two of them don't do anything. One even gives me an error. Most of the programs I try to run open just fine in 64-bit like I want.

    These programs run in 32-bit.

    Process.Start(@"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe")
    Process.Start(@"C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe")
    Process.Start(@"C:\Windows\System32\taskmgr.exe")
    Process.Start(@"C:\Windows\System32\msinfo32.exe")
    Process.Start("regedit.exe")
    Process.Start("cleanmgr.exe")
    
    

    I don't care so much about having all these running in 64-bit, but I do want powershell.exe, powershell_ise.exe, and taskmgr.exe to run in 64-bit. I tried to specify the path to the 64-bit version of the program, but they still run in 32-bit. I even tried to compile my program to run in 64-bit, but these programs still run in 32-bit. Also some other programs run in 64-bit no problem.

    These run in 64-bit.

    Process.Start("cmd.exe")
    Process.Start("Control.exe")
    


    These programs don't do anything

    Process.Start(@"C:\Windows\System32\msconfig.exe")//Gives me a file not found error.
    
    Process.Start(@"C:\Windows\System32\dfrgui.exe")//I don't get any errors, but nothing happens when I try to run it.

    Can someone help me out here?

    Tuesday, October 6, 2020 9:21 PM

Answers

  • Hi LavaCreeperKing,

    Thank you for posting here.

    When using Process.Start() to start a program, whether the started program is 32-bit or 64-bit depends on the current project.

    The command prompt launched from a 32-bit program will be a 32-bit command prompt, and a command prompt launched from a 64-bit application will be a 64-bit command prompt.

    In the default setting of Visual Studio, the program runs in 32-bit mode.

    It seems that msconfig.exe and dfrgui.exe can only run in 64-bit, so if you uncheck Prefer 32-bit, this program will run in 64-bit and the previous error will disappear.

    Best Regards,

    Timon


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, October 7, 2020 2:00 AM

All replies

  • Hi LavaCreeperKing,

    Thank you for posting here.

    When using Process.Start() to start a program, whether the started program is 32-bit or 64-bit depends on the current project.

    The command prompt launched from a 32-bit program will be a 32-bit command prompt, and a command prompt launched from a 64-bit application will be a 64-bit command prompt.

    In the default setting of Visual Studio, the program runs in 32-bit mode.

    It seems that msconfig.exe and dfrgui.exe can only run in 64-bit, so if you uncheck Prefer 32-bit, this program will run in 64-bit and the previous error will disappear.

    Best Regards,

    Timon


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, October 7, 2020 2:00 AM
  • Add before =>

    bool bWow64 = false;
    IsWow64Process(Process.GetCurrentProcess().Handle, out bWow64);
    if (bWow64)
    {
        IntPtr OldValue = IntPtr.Zero;
        bool bRet = Wow64DisableWow64FsRedirection(out OldValue);
    }

    with :

    [DllImport("Kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    private static extern bool IsWow64Process(IntPtr hProcess, out bool Wow64Process);
    
    [DllImport("Kernel32.dll", SetLastError = true, CharSet = CharSet.Unicode)]
    private static extern bool Wow64DisableWow64FsRedirection(out IntPtr OldValue);

    Wednesday, October 7, 2020 4:04 AM
  • Another way to deal with File System Redirection when running a 32-bit process (WOW64) is to follow the suggestion here - https://docs.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector

    "32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one."

    Wednesday, October 7, 2020 10:27 AM
  • Thanks that problem is now solved. New question. When I launch powershell from my program it opens with a different resolution then if I launch it from the windows start menu. When I launch it from my program the window and text is larger. Not that this is a problem, but how I might I correct it?
    Wednesday, October 7, 2020 10:13 PM
  • Hi,

    Usually, we focus on answering one question in a thread.

    If there are multiple questions in a thread, the topic of this thread will be confused. In the future, if someone has one of the same problems, it will be difficult for him to quickly find a solution from this thread.

    Therefore, it is best to mark the helpful reply in this thread as an answer, and then create a new thread. If there is necessary information in this thread, you can display this thread in the new thread in the form of a link.

    Best Regards,

    Timon


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, October 8, 2020 2:27 AM