none
The Puzzle of C:\Windows\System32\slui.exe Which Exists/Does Not Exist Depending on C# Platform Target Setting RRS feed

  • Question

  • I recompiled my C# program with the Platform Target configuration parameter set to x64.  Now System.IO.File.Exists() is able to find C:\Windows\System32\slui.exe.  It escapes me why which Windows-on-Windows instance gets invoked would determine whether a hard link is found or not found.  Ours is not to reason why.  Just accept it and go on.  Still wondering why certain files (which the dir command displays) are not enumerated by System.IO.Directory.GetFiles().  Reference:  System.IO.Files.Exists().

    MARK D ROCKMAN

    Tuesday, March 3, 2015 11:23 AM

Answers

  • Hi,

    Firstly, there are two different versions of the Program Files folder and the Windows System folder.
    A 64-bit Windows has  two different versions of the program files folder and the Windows system folder
    (system directory). One version is intended for 32-bit files and other version  is intended for 64-bit files. The name of these folders, and the bitness they are intended for, is shown in the table below:

    Folder name Bitness Description
    System32 64 Windows System folder (system directory) for 64-bit
    files
    SysWOW64 32 Windows System folder (system directory) for 32-bit
    files
    Program Files 64 Folder for 64-bit program files
    Program Files (x86) 32 Folder for 32-bit program files

    Secondly the different options with Any CPU VS x86  VS X64

    • AnyCPU – The assembly is compiled in a CPU-independent manner. If you are compiling an EXE, the EXE will run as an x64 processes when loaded by an x64 version of the .Net Framework on an x64 operating system. Otherwise the EXE will run as an x86 process. When you’re compiling a DLL, the DLL will load as an x64 DLL when loaded from an x64 process. Otherwise, the DLL will load as an x86 DLL.
    • x86 – The assembly will always load as an x86 assembly, regardless of the operating system or .Net Framework version. The assembly will not load from an x64 process.
    • x64 – The assembly will always load as an x64 assembly, regardless of the operating system or .Net Framework version. The assembly will not load on an x86 operating system or from an x86 process

    For more detailed information, please refer to http://thingsthatshouldbeeasy.blogspot.se/2009/08/anycpu-x86-x64-whats-difference.html#.UZMed6KpqUQ

    Best regards,

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, March 4, 2015 2:21 AM
    Moderator
  • "But I find, depending on which Platform Target I select, I get more complete or less complete lists of files."

    Well, when you run 32 bit apps on a 64 bit OS you basically run them in some sort of emulator that tries to convince the app that it runs on a 32 bit OS. This including redirecting some OS folders to make the app believe that C:\Windows\System32 contains 32 bit dll/exe files like on a 32 bit OS.

    "It could be a feature.  And all features must be thoroughly and exactingly documented."

    It is: https://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

    "So, which forum is appropriate for probing this issue?"

    In theory that would be the Windows SDK forum: https://social.msdn.microsoft.com/Forums/en-US/home?forum=windowssdk

    But I'm not sure what kind of solution you'll get there since the best solution is .NET/C# specific:

    Don't set the target platform to x64 because if you do that the executable won't run on 32 bit OSes. Set the target to Any CPU and uncheck the "Prefer 32-bit" option. That will allow the executable run as a 32 bit process on a 32 bit OS and as a 64 bit process on a 64 bit OS.

    Friday, March 13, 2015 11:55 AM
    Moderator

All replies

  • Hi,

    Firstly, there are two different versions of the Program Files folder and the Windows System folder.
    A 64-bit Windows has  two different versions of the program files folder and the Windows system folder
    (system directory). One version is intended for 32-bit files and other version  is intended for 64-bit files. The name of these folders, and the bitness they are intended for, is shown in the table below:

    Folder name Bitness Description
    System32 64 Windows System folder (system directory) for 64-bit
    files
    SysWOW64 32 Windows System folder (system directory) for 32-bit
    files
    Program Files 64 Folder for 64-bit program files
    Program Files (x86) 32 Folder for 32-bit program files

    Secondly the different options with Any CPU VS x86  VS X64

    • AnyCPU – The assembly is compiled in a CPU-independent manner. If you are compiling an EXE, the EXE will run as an x64 processes when loaded by an x64 version of the .Net Framework on an x64 operating system. Otherwise the EXE will run as an x86 process. When you’re compiling a DLL, the DLL will load as an x64 DLL when loaded from an x64 process. Otherwise, the DLL will load as an x86 DLL.
    • x86 – The assembly will always load as an x86 assembly, regardless of the operating system or .Net Framework version. The assembly will not load from an x64 process.
    • x64 – The assembly will always load as an x64 assembly, regardless of the operating system or .Net Framework version. The assembly will not load on an x86 operating system or from an x86 process

    For more detailed information, please refer to http://thingsthatshouldbeeasy.blogspot.se/2009/08/anycpu-x86-x64-whats-difference.html#.UZMed6KpqUQ

    Best regards,

    Kristin


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, March 4, 2015 2:21 AM
    Moderator
  • My answer is simpler. Have you checked the security set on the folder. Does that user having all the rights to see that file in Windows Explorer? Has the file attribute set to Hidden?

    chanmm


    chanmm

    Wednesday, March 4, 2015 2:51 AM
  • A little poking around in the debugger turns up the implementation of File.Exists goes through FillAttributeInfo:

    http://referencesource.microsoft.com/#mscorlib/system/io/file.cs,1529

    Both 32 bit and 64 bit builds get the result from Win32Native.GetFileAttributesEx.

    A quick C++ test returns the same results:

    int _tmain(int argc, _TCHAR* argv[])
    {
    	DWORD gle = 0;
    	WIN32_FILE_ATTRIBUTE_DATA info;	
    	BOOL bret = GetFileAttributesExW(L"c:\\windows\\system32\\slui.exe", GET_FILEEX_INFO_LEVELS::GetFileExInfoStandard, &info);
    	if (!bret)
    	{
    		gle = GetLastError();
    	}
    	return 0;
    }

    bret is true for x64, false for x86 with gle being 2, or ERROR_FILE_NOT_FOUND in the 32 bit build. So, it's a Win32 issue.

    I'm not sure if that helps, but it should get you to the right forum if you want to pursue it deeper ;->

    Wednesday, March 4, 2015 2:52 AM
  • Thanks very much.  That's pithy.  A number of "apps" that I've created depend on me being able to enumerate all, emphasis on ALL, files in a directory.  The .NET Framework implements System.IO.Directory.GetFiles() and System.IO.Directory.GetDirectories().  Artful use of recursive functions (or "methods") produces what appears to be a complete list of files.  But I find, depending on which Platform Target I select, I get more complete or less complete lists of files.  If one were concerned from a security standpoint that one is getting complete information then this would be disturbing.  I'm just creating (unknown before this) incomplete backups.  I'm not saying this behavior is a bug.  It could be a feature.  And all features must be thoroughly and exactingly documented.  So, which forum is appropriate for probing this issue?

    MARK D ROCKMAN

    Wednesday, March 4, 2015 10:42 AM
  • @MARK D ROCKMAN

    I think you can ask in .NET Framework >  Common Language Runtime Internals and Architecture

    If you still not sure, here is a forum Where is the forum for..?

    the moderator forum ("Where is the forum for..?"). The owner of the forum will direct you to a right forum.

        

    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Friday, March 13, 2015 10:25 AM
    Moderator
  • "But I find, depending on which Platform Target I select, I get more complete or less complete lists of files."

    Well, when you run 32 bit apps on a 64 bit OS you basically run them in some sort of emulator that tries to convince the app that it runs on a 32 bit OS. This including redirecting some OS folders to make the app believe that C:\Windows\System32 contains 32 bit dll/exe files like on a 32 bit OS.

    "It could be a feature.  And all features must be thoroughly and exactingly documented."

    It is: https://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx

    "So, which forum is appropriate for probing this issue?"

    In theory that would be the Windows SDK forum: https://social.msdn.microsoft.com/Forums/en-US/home?forum=windowssdk

    But I'm not sure what kind of solution you'll get there since the best solution is .NET/C# specific:

    Don't set the target platform to x64 because if you do that the executable won't run on 32 bit OSes. Set the target to Any CPU and uncheck the "Prefer 32-bit" option. That will allow the executable run as a 32 bit process on a 32 bit OS and as a 64 bit process on a 64 bit OS.

    Friday, March 13, 2015 11:55 AM
    Moderator