C# running Process weird stuff

Question

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);

        }
    }

It would be helpful to add the process return codes as well: Console.WriteLine("Process exit code: {0}", myProcess.ExitCode); — aquaraga, Apr 26 '13 at 20:09
@aquaraga. so it has error but dont know what. I cut and paste the command from the method to the command line and it works ok — John Ryann, Apr 26 '13 at 20:34
Try to compile for x86 if you run on a 32bit OS or with x64 if you run on a 64bit OS — Steve, Apr 26 '13 at 20:36
@Steve: you are DA MAN! it works. but why? I am still puzzled. — John Ryann, Apr 26 '13 at 20:44

Steve · Accepted Answer · 2013-04-26T21:35:41.837

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

Right on all counts, and I couldn't agree more with your suggestion not to use the registry to store app configuration data. The AppData folder is a better option, see [the bottom part of this answer](http://stackoverflow.com/questions/5210575/5210642#5210642) for details. As far as your update, if you're compiling the test app on VS 2012, [the "AnyCPU" option has become more complicated](http://blogs.microsoft.co.il/blogs/sasha/archive/2012/04/04/what-anycpu-really-means-as-of-net-4-5-and-visual-studio-11.aspx). It's actually a 32-bit app, so the behavior you see makes sense. — Cody Gray - on strike, Apr 26 '13 at 22:51
@CodyGray, now it is clear, thanks. Duh, `In .NET 4.5 and Visual Studio 11 the cheese has been moved.` Someone in Redmond fell out of bed on the wrong foot. — Steve, Apr 26 '13 at 23:18
As far as I'm concerned, in VS 2012, it's not even cheese anymore. — Cody Gray - on strike, Apr 26 '13 at 23:57

score 0 · Answer 2 · edited May 23 '17 at 12:04

0

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.

edited May 23 '17 at 12:04

Community

1
1

answered Apr 26 '13 at 20:11

m0s

4,250
9
41
64

C# running Process weird stuff

2 Answers2