Question

as comming from a *nix world I’m very confused with Windows behaviour and probably its security system.

I’m simply trying to execute an external program within my app. I’ve found the WinAPI function ShellExecute which works as expected except when launching some programs placed in %windir%\System32 subdirectory.

• execution of ping.exe succeeds

  ShellExecute(NULL, "open", "c:\\Windows\\System32\\ping.exe', NULL, NULL, SW_SHOW) );
  // ^^^ OK, retcode == 42
  

• execution of java.exe fails

  ShellExecute(NULL, "open", "c:\\Windows\\System32\\java.exe', NULL, NULL, SW_SHOW) );
  // ^^^ ERROR_FILE_NOT_FOUND, retcode == 2
  

It’s very strange because java.exe does exist in System32, has read/execute permissions for Users group and can be invoked from cmd.

C:\>dir /q c:\Windows\System32\java.exe
 Volume in drive C has no label.
 Volume Serial Number is 56E3-0868

 Directory of c:\Windows\System32

11.01.2012  23:40           172 320 NT AUTHORITY\SYSTEM    java.exe
               1 File(s)        172 320 bytes
               0 Dir(s)  226 127 564 800 bytes free

C:\>cacls c:\Windows\System32\java.exe
c:\Windows\System32\java.exe NT AUTHORITY\SYSTEM:F
                             BUILTIN\Administrators:F
                             BUILTIN\Users:R

What am I missing here ?

OS is Windows 7 Home edition.

Update: If I copy c:\Windows\Sytem32\calc.exe to c:\Windows\Sytem32\calc2.exe, ShellExecute can run original calc.exe but fails with calc2.exe although files are identical !! The only difference are additional permissions for TrustedInstaller group which calc2.exe and also java.exe are missing. A coincidence ?

Answer 1

Are you running a 64 bit operating system?

If so, C:\Windows\System32 will contain 64 bit binaries while C:\Windows\SysWOW64 will contain 32 bit binaries (yes, it really is that way around). For backwards compatibility reasons, when running 32 bit processes, Windows redirects access to C:\Windows\System32 to C:\Windows\SysWOW64.

So if you’re using a 32 bit process to look at C:\Windows\System32, you’re actually seeing what’s in C:\Windows\SysWOW64.

You can call the Wow64DisableWow64FsRedirection function to disable this behavior. Do note the warning in the documentation and consider carefully whether it applies to your case:

Note: The Wow64DisableWow64FsRedirection function affects all file operations performed by the current thread, which can have unintended consequences if file system redirection is disabled for any length of time. For example, DLL loading depends on file system redirection, so disabling file system redirection will cause DLL loading to fail. Also, many feature implementations use delayed loading and will fail while redirection is disabled. The failure state of the initial delay-load operation is persisted, so any subsequent use of the delay-load function will fail even after file system redirection is re-enabled. To avoid these problems, disable file system redirection immediately before calls to specific file I/O functions (such as CreateFile) that must not be redirected, and re-enable file system redirection immediately afterward using Wow64RevertWow64FsRedirection.