Share via

Windows Vista File and Registry Virtualisation

  • Article

Windows Vista is designed to be more secure than previous versions of Windows. Part of the improvements are related to User Account Control (UAC), which encourages the good practice of not logging on with an Administrator account (and even if you do, it limits your available rights by default). While this is good for security, it can be problematic when dealing with legacy application, many of which were developed with the expectation that the user can make changes to locations such as the Windows directory.

Ideally, applications should be re-written or patched to make them compliant with Windows Vista security, but where this is not possible Windows Vista provides a new feature that will help alleviate problems in this area. The feature is known as File and Registry Virtualisation (FARV).  Below is a brief overview of FARV:

How File and Registry Virtualisation Helps

FARV presents a “virtual” view of certain parts of the filesystem and registry to legacy applications. That is, the legacy application can read and write to what it thinks is the correct location in the registry and filesystem, but any changes are actually redirected to a user-specific location.

File changes are redirected to the following location:

%UserProfile%\AppData\Local\VirtualStore

This directory contains subdirectories matching the location that was redirected. For example, if changes were redirected from the Windows directory, the store will look similar to this:

 

The FARV VirtualStore, showing some redirected folders.

If you navigate to the Windows drectory in Windows Explorer, you will not see the virtual version of the file. Explorer will show the actual content of folder. However, it does alert you to the fact that virtual copies of some files exist by a new button on the taskbar:


Explorer alerts you to the existence of user-specific files in the VirtualStore

Clicking this button takes you to the virtual store mentioned above.

A similar store exists for redirected Registry changes:

HKEY_CLASSES_ROOT\VirtualStore

This may appear to be a system-wide store since it doesn’t contain any user-specific information in the path. However, this key is actually just a pointer to the following location:

HKEY_USERS\<user SID>\Software\Classes\VirtualStore
[also accessible via: HKEY_CURRENT_USER\Software\Classes\VirtualStore]

So, registry changes are also stored on a per-user basis.

What is Virtualised?

File and Registry Virtualisation is hard-coded to present a virtual view of only these locations in the filesystem and registry:

Registry (includes subkeys)

HKEY_LOCAL_MACHINE\Software

Exceptions are:

  • HKLM\Software\Microsoft\Windows
  • HMLM\Software\Microsoft\Windows NT
  • Other subkeys under “Microsoft”

Keys can be excluded by setting the new DONT_VIRTUALIZE flag for the key using the Reg.exe tool.

Filesystem (includes subfolders)

  • %SystemRoot% (e.g. C:\Windows)
  • %ProgramFiles% (e.g. C:\Program Files)
  • %AllUsersProfile% (e.g. C:\ProgramData – previously C:\Documents and Settings\All Users)

Binary executable files (.exe, .dll, .sys, etc) are excluded from virtualisation. Additional extensions can be added here:

HKLM\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd

These are locations where it is common for legacy applications to store their settings and data, but which should be secured against unauthorised access. There is no mechanism for adding additional folders or registry keys.

When is File and Registry Virtualisation Enabled?

File and Registry Virtualisation is an “opt-out” feature. That is, it is enabled for an application unless Windows is told otherwise. The mechanisms that Windows uses to tell if it should disable FARV are:

  1. Process Target Architecture. FARV is not enabled for 64-bit applications.

  2. Logon Type. Only activity originating from an interactive logon is virtualised. So, for example, any file writes due to file sharing across the network are not subject to FARV.

  3. Running as Administrator. If an application was launched with a Full Token, then Windows does not enable FARV since it is assumed that the user has appropriate access permissions for the locations discussed above.

  4. Application Manifest. If the application has an associated manifest file (embedded or external) that contains the new requestedExecutionLevel entry, Windows assumes the application has been written specifically for Windows Vista and thus will deal appropriately with security restrictions.

  5. User Intervention. If the user decides that FARV is not required, they can disable it using Task Manager:

     

Virtualisation status shown in Task Manager

Right-clicking on an entry in Task Manager shows a context menu with an option to toggle FARV on and off.

Limitations of File and Registry Virtualisation

FARV is not intended to be a complete answer to dealing with poorly written legacy applications. It is really a stop-gap mechanism to help with migration to the new Windows Vista Security model. It is likely that this feature will be dropped from future versions of Windows, so application developers should not rely on it for the proper operation of their applications, but should instead change their applications to work within the security constraints of Windows Vista.

Some places where FARV is limited are:

  • Target locations. The locations handled by FARV are hard-coded and apart from the Registry exclusions mentioned above users cannot alter this list. Nor can the user specify where the redirected data is stored.
  • Machine-wide changes. FARV works on a per-user basis, thus changes stored by one user are not seen by other users. Also, since user-specific data over-ride any actual data, Administrators have no way to make changes for all users at the same time.
  • Roaming users. FARV data that is stored in the local filesystem and does not roam with the user when they move to another computer.
  • Application functionality. For poorly written applications that may rely on settings stored in the virtualised locations to determine what they allow users to do, etc, this can be by-passed by the user changing data in the virtualised location, which over- rides any “real” settings in the restricted locations. Even if this does not result in a security problem (which it might), it could still lead to unexpected behaviour.