none
Reading virtualized file in Windows 7 fails!

    Question

  • Running Windows 7, 64-bit.

    Sloppy 32-bit application A tries to write this file:
    C:\Program Files\SloppyApp\MyFile.txt

    Due to file virtualization, the file ends up here:
    C:\Users\MyUser\AppData\Local\VirtualStore\Program Files\SloppyApp\MyFile.txt

    Now I run my well written 32-bit application B and try to open the file:
    hFile = fopen("C:\\Program Files\\SloppyApp\\MyFile.txt", "rb");

    It fails, and GetLastError() returns 3. Obviously, that file does not exist.

    I read on MSDN that file virtualization is disabled when the application is UAC aware. Here is the relevant part of the manifest of application B:
    <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
        <security>
          <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
          </requestedPrivileges>
        </security>
      </trustInfo>


    My question
    How do I read MyFile.txt from application B? Do I have to guess that the file ended up in the VirtualStore directory or could this somehow be handled by the driver? What is the preferred method here?

    Thanks!
    Sunday, March 07, 2010 11:31 PM

Answers


  • Basically from what I have experienced in the past is that if the application does not have the manifest and is not elevated, then Windows Vista and greater assumes its an older application that doesn't know any better.  So rather than failing to create the file in the Program Files directory and causing the application to fail, it virtualizes it in the appdata directory.

    If app B is well behaved, I think it will have to search for it.
    • Marked as answer by zirconia Tuesday, March 09, 2010 7:49 PM
    Monday, March 08, 2010 4:51 AM
  • Hello zirconia,

    Virtualization(File and Registry) is designed to make legacy appliation to run well under Windows User Account Control(UAC). If the requestedExecutionLevel section(newly added from Windows Vista) is added to the appliation's manifest, the application is not treated as a legacy application, the file virtualization is disabled for that application. Also, Virtualization only applies to 32bit applications.

    How do I read MyFile.txt from application B?
    You can remove the requestedExecutionLevel from B's manifest. 

    More information
    http://msdn.microsoft.com/en-us/library/bb530410.aspx

    Virtualization is disabled for:

    • 64 bit processes
    • Non-interactive processes
    • Processes that impersonate
    • Kernel mode callers
    • Executables that have a requestedExecutionLevel

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by zirconia Tuesday, March 09, 2010 7:49 PM
    Monday, March 08, 2010 6:07 AM

All replies

  • I would expect that you could read and write to the virtual file in the program files folder with no problem.

    However, I have definitely seen file read/write problems with Vista and Windows 7.

    It does seem like the driver is involved. So we see few issues on brand new Windows 7 machines, but if the machine is an upgrade or a older laptop we have seen file problems especially with many reads and writes.

    The manifest you show doesn't have much to do with it one way or another, virtualization is never disabled by that. See IECreateFile for a routine that will fail when writing to a virtual area.

    Monday, March 08, 2010 12:29 AM

  • Basically from what I have experienced in the past is that if the application does not have the manifest and is not elevated, then Windows Vista and greater assumes its an older application that doesn't know any better.  So rather than failing to create the file in the Program Files directory and causing the application to fail, it virtualizes it in the appdata directory.

    If app B is well behaved, I think it will have to search for it.
    • Marked as answer by zirconia Tuesday, March 09, 2010 7:49 PM
    Monday, March 08, 2010 4:51 AM
  • Hello zirconia,

    Virtualization(File and Registry) is designed to make legacy appliation to run well under Windows User Account Control(UAC). If the requestedExecutionLevel section(newly added from Windows Vista) is added to the appliation's manifest, the application is not treated as a legacy application, the file virtualization is disabled for that application. Also, Virtualization only applies to 32bit applications.

    How do I read MyFile.txt from application B?
    You can remove the requestedExecutionLevel from B's manifest. 

    More information
    http://msdn.microsoft.com/en-us/library/bb530410.aspx

    Virtualization is disabled for:

    • 64 bit processes
    • Non-interactive processes
    • Processes that impersonate
    • Kernel mode callers
    • Executables that have a requestedExecutionLevel

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
     


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    • Marked as answer by zirconia Tuesday, March 09, 2010 7:49 PM
    Monday, March 08, 2010 6:07 AM
  • Thanks for your clarification!

    Wouldn't you agree with Eric Haddan though? Since application B is "well behaved", the manifest should indeed be there - with requestedExecutionLevel set. No?

    If you know an application is a legacy application, perhaps you should follow this principle?
    hFile = fopen("C:\\Program Files\\SloppyApp\\MyFile.txt", "rb");
    if (!hFile)
    {
        hFile = fopen("C:\\Users\\MyUser\\AppData\\Local\\VirtualStore\\Program Files\\SloppyApp\\MyFile.txt", "rb");
    }

    Would you agree?
    Monday, March 08, 2010 8:21 AM
  • Hello zirconia,

    >Would you agree?

    Yes, I agree.

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, March 08, 2010 8:31 AM
  • No because Virtualisation is not guaranteed to be in future versions of Windows. It was only put in originally to take the burden off of legacy applications. At the same time Microsoft was publishing lots of information on best practices to convince developers to be aware of standard user accounts.

    So even if you know the hard coded path now it isn't guaranteed to be the same in newer versions. For example, Wow64 registry virtualisation has already had a big change between Vista and 7.

    So that may work now, but will it work in the future.
    Visit my (not very good) blog at http://c2kblog.blogspot.com/
    Monday, March 08, 2010 8:35 AM
  • Hello crescens2k,

    Thanks for your input. Yes, Virtualisation is designed to legacy appliations to run well under UAC without to many changes or even without any change. And an well designed application should not be depend on the Virtualisation.

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Monday, March 08, 2010 10:38 AM
  • Is there an API to get the VirtualStore directory for the currently logged on user?
    Monday, March 08, 2010 12:01 PM
  • Monday, March 08, 2010 12:31 PM
  • Hello zirconia,

    In my opinion, that is because UAC by design is difficult to check for.

    Thanks,
    Rong-Chun Zhang
    MSDN Subscriber Support in Forum
    If you have any feedback on our support, please contact msdnmg@microsoft.com
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Tuesday, March 09, 2010 7:25 AM