At least one commenter wondered if this still is a developers blog or just a personal whereabouts chitchat. It is both. And although this blog is going to present some code at last I wondered for a moment what would happen if I obfuscated all the logical names in the code to famous tourists attraction like Cape Town, Tafelberg, Cape Alguhas and the majestic Hangklip. Maybe three blogs of chitchat is enough for most readers, pity.

On a small project last week I encountered an issue when I needed to launch an windows application. In my mind the solution was pretty simple, instantiate the Process class, supply it with a ProcessStartInfo, call Start(); and you're in business.

The first test run however ended in an Win32 Exception: File not Found. I'm still partly human so mistakes come natural. The command prompt was quickly started and the dir "c:\Windows\system32\filename.exe" showed immediately….that the file did exist, it even had a size, and when I ran the file it actually showed what I expected.

Puzzled I reverted back to the code, verifying that I was indeed providing the correct path and that ProcessStartInfo had the correct settings and arguments. Google pointed out that there are issues when you want to run a 64bits exe from a 32bits process. Could that be the case: I was on Vista x64, building a .Net 4.0 commandline app, targeting x86 from within Visual Studio 2010. The executable I wanted to launch was the Backup and Restore app, sdclt.exe. On disk it resided in the Environment.SystemDirectory ("c:\windows\system32"). The reason it refused to start/to be found lay in the Windows on Windows functionality. WOW is a concept that I first encountered in the form of win32s (yes, I'm that old). It automagically let you run apps compiled for an other number of bits on the same box. One of the features of WOW is to redirect file access in system32 to SysWow64, without the user ever knowing it. Great, and now disable that.

You could recompile to x64 and you're done. If that is not possible you might find this little class help full. It tries to determine as good as it can if the executable you want to launch is a 64bits PE file. I use the GetBinaryType api for that. Once that is determined a call to Wow64DisableWow64FsRedirection (the microsoft employee responsible for coming up with decent short names for API's was an holiday) disables redirection and therefor a call to Process.Start() will succeed.

For convenience (or over engineered) I extended the Process class and abstracted the disabling and enabling in a helper class that implements IDisposable. Leveraging this class becomes as easy as this:

ProcessStartInfo restoreBackupProcess = new ProcessStartInfo(
                Path.Combine(Environment.SystemDirectory, "sdclt.exe"), 
                @"/RESTOREPAGE");

ProcessEx pe = new ProcessEx();
pe.StartInfo = restoreBackupProcess;
pe.Start();
pe.WaitForExit();

The Start(); method will always succeed either if the windows executable is 64bits or 32bits.

The new Start() method looks like this:

    /// <summary>
    /// ProcessEx extends Process to Start 64bits system exe's from a 32 bits process
    /// </summary>
    public class ProcessEx:Process
    {
        /// <summary>
        /// Overriden Start method
        /// </summary>
        new public void Start()
        {
            // we can only start if we have a StartInfo
            if (this.StartInfo != null)
            {
                // Disable WOW64 redirection if needed
                using (new DisableWOW64(base.StartInfo.FileName))
                {
                    base.Start(); // real start
                }
            }
        }
       ....
     }

Have a look at the full source code for the DisableWOW64 implementation.