Did you know (Part II) File / Registry virtualization on Windows 7 / Vista

Hi

In this post I discussed some issues I faced regarding software running on Vista 64 bits. Well it ended up that all my troubles was happening because my program (64 bits) was launching IE 64 bits (instead of the 32 bits) and I had not installed Silverlight plugin on it! Solution: just switch my program to 32 bits and it worked as expected!

In this post I want to discuss some pitfalls when running software on x64 bit versions of Windows (most of the discussion applies equally well to Vista x64 ,Windows 7 x64 and probably to newer versions also - haven't tried it with Windows  8 but I bet that the behavior is the same).

Keep in mind that when talking about the reasons that lead Microsoft to add a specific feature I am just speculating, so take every word with a grain of salt :)

On previous Windows versions, to many (almost every single?) developer used to login as admistrator into their workstations¹ so there were way to many applications that relied on being able to change system resources (such as to create files/fonders under "Program Files"), after all they always succeed doing that since developers had the rights to do so (remember, administrator...).

At Vista launch time MS had a tough issue to deal with: how raise the bar for system security / stability without breaking such ("legacy") applications?

AFAIK a compromise was settled so Windows development team decided that for some 32 bit applications such requests would not fail, but instead, Windows would lie to the calling process and would just create the file somewhere else (the same principle apply to registry access): this feature is known as file virtualization (the rules that governs whether file/registry will be enabled or not for a specific process can be found here)

Note that this feature is meant to allow legacy applications² to run on the new platform (at that time, Windows Vista) so Microsoft plans to remove it (as soon as your application gets compiled as 64 bits, virtualization will be disabled anyway).

If you are running the 64 bits version of Windows 7 (or Vista for that matter) you can try it right now by downloading the test application source³ and running it with something like:

FileSystemVirtualizationTest.exe -e %windir%\test.txt "adriano's test"

For now, just run it with the arguments shown above and take a closer look in the produced output:

Virtualization ENABLED.

Virtualization is ON

14 bytes writen to C:\Windows\test.txt

It seams that the application succeed in creating a file under %windir% (which it should obviously not be allowed to) but how can we confirm that? Easy, just run the application again now providing only the file name (the application will try to read the file and dump its contents):

FileSystemVirtualizationTest.exe %windir%\test.txt

Virtualization is ON

adriano's test

and there it is! But wait! Let's open Windows Explorer and try to locate the file. Hey! I can't find the file anymore! Windows search can't find it either:

But the application does succeeded opening the file! how can that be? Launch Windows Explorer again on %windir% folder but this time paying attention to the little button: "Compatibility Files":

Ok, now that you noticed this button, press it and Windows Explorer will open a folder that looks like the one bellow:

Wow! Windows just created the file under %localappdata%\VirtualStore\Windows folder (which is a per user folder). 

This way Windows let applications believe they had successfully updated files / folders / registry keys when actually they didn't (preventing possible global system corruption). Clearly avoiding system corruption is a fair reason to support this functionality, but now, developers (and IT admins) must pay attention to scenarios with mixed 32 / 64 bits applications interacting in such ways that they need to observe changes from each other (since the first ones may be writing to the virtual store and the last ones will not see the virtual store).

Last, but not least :), make sure your application do not depend on registry/file virtualization; these mechanisms were introduced sonly to raise the likelihood of legacy applications to run without problems on Windows versions with stricter security settings (Vista, 7, etc). So if you have an application that does writes to protected file system areas, please do your users a favor: update it to write to a more appropriated location (%appdata%, %localappdata%, etc).

Bellow you can find some links if you want to read more about file system virtualization:

• http://blogs.sepago.de/helge/2008/04/20/windows-x64-all-the-same-yet-very-different-part-7/ 
  
• http://msdn.microsoft.com/en-us/library/dd464643(VS.85).aspx
• Best practices for WOW64
• UAC file / registry virtualization

Have fun!

Adriano

[1] I am guiltily of doing the same thing :(
[2] Basically all applications developed for previous Windows OSs are handled as legacy by Vista
[3] In the first drafts of this post I used Notepad++ to write to %windir% but it looks like they added a manifest in the latest versions so it will not work for our demonstration purposes. Even in my sample application I was required to remove the manifest explicitly (VS 10 included one that disabled virtualization)