Registry Virtualization in Windows Vista

  • Article

 

Microsoft Corporation

June 2007

Summary: Registry Virtualization is an application compatibility technology that allows globally impacting writes to be re-directed to per-user locations in the registry. (4 printed pages).

Contents

What is Registry Virtualization?
Why Virtualization?
How does Registry Virtualization Work?
What is Virtualized?
What is Not Virtualized?
Controlling Virtualization
Virtualization and Auditing
Virtualization Recommendations
Resources

What is Registry Virtualization?

Registry Virtualization is an application compatibility technology that allows globally impacting writes to be re-directed to per-user locations in the registry. This re-direction is transparent to applications reading from or writing to the registry.

As virtualization is an interim application compatibility technology, Microsoft intends to remove this form of virtualization from future versions of the Windows operating system as more applications are migrated to Windows Vista. As a result it is imperative your application does not take a hard dependency on the presence of virtualization in the system.

Note   Refer to the UAC Developer Guide for more information on building UAC compliant applications for Windows Vista.

Why Virtualization?

Prior to Windows Vista, many applications were typically run by administrators. As a result, applications could freely read and write system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access. Windows Vista improves application compatibility for these users by redirecting writes to a per-user location within the user's profile. For example, if an application attempts to write to HKEY_LOCAL_MACHINE\Software\Contoso\ it will automatically redirect to HKEY_USERS\< User SID >_Classes\VirtualStore\Machine\Software\Contoso.

Note   For more information about other User Account Control technologies in Windows Vista refer the UAC Developer Guide.

How does Registry Virtualization Work?

Based on the type of operation virtualization can be broadly classified into three types.

Open

When the caller does not have write access to a key, but opens the key with ALL_ACCESS, the key will be opened with MAX_ALLOWED access for that caller.

Note: If this is disabled for a key, it will also implicitly disable virtualization for that key. (Controlling Virtualization).

Write

When the caller does not have write access to the key and attempts to write a value (or create a subkey), the value will be virtualized and stored in a per-user location within the user's profile.

    HKLM\Sofware\Key1
            V1 
            V2
            V3  -> RegSetValueEx(…)
         ACCESS_DENIED =>
   HKU\{SID}_Classes\VirtualStore\Machine\Software\Key1
                                       V3

In the example above, if the caller (limited user) attempts to write Value V3 to Key1, virtualization would kick-in and re-direct the write to the virtual store on the non-roaming user hive (HKU\{SID}_Classes\VirtualStore\Machine\Software) and the call will succeed without any additional requirements on the caller.

Read

When reading from a key that is virtualized, the registry presents a merged view of both the virtualized values (from the virtual store) and the non-virtual values (from the global store) to the caller. In the example above, the caller will get a merged view with values V1 and V2 being read from the global store and value V3 being read from the virtual store whenever the caller attempts to read values of the key HKLM\Software\Key1.

Note that virtual value take precedence over global values when present. In the example above, even if the global store had value V3 under Key1, the value V3 from the virtual store will be returned to the caller. If the virtual value were to be deleted from the virtual store, then the reads would fallback to the global store. For example, if V3 were to be deleted from HKU\{SID}_Classes\VirtualStore\Machine\Software\Key1, and if HKLM\Software\Key1 had a value V3, then that value would be returned.

What is Virtualized?

Registry Virtualization is enabled only for:

  • 32-bit interactive process
  • Keys in the Software hive (HKLM\Software)
  • Only for keys that are administrator writeable
    • If an administrator cannot write to a key, then the legacy application would have failed in previous versions of Windows even if the application was run as an administrator.

What is Not Virtualized?

  • 64-Bit Processes—As virtualization is purely an application compatibility technology meant to help legacy applications it is enabled only for 32-bit applications. The world of 64 bit applications is relatively new and should follow the application development guidelines for Windows Vista.

  • Non-interactive process like Windows Services—Calls from these processes are never virtualized. As a result, reads and writes from these processes will always go to the global store (HKLM\Software).

    Note that using the registry as an Inter Process Communication (IPC) mechanism between a service and a user process will not work correctly if the key were to be virtualized. For instance, if an antivirus service upgrades its signature files based on a value being a set by a user application in its key, then it will never read the value set by the user application as it will read the key from the global store and the writes from the user application will be virtualized to the virtual store for that user.

  • Callers that impersonate—If a process is attempting an operation while impersonating, that operation will not be virtualized.

  • Kernel Mode Callers

  • Executables that have a requestedExecutionLevel specified in the manifest (More information on the requestedExecutionLevel can be found in the UAC Developer Guide)

  • By default Virtualization is disabled for certain Windows keys (and their subkeys) in the software hive like HKLM\Software\Classes; HKLM\Software\Microsoft\Windows; HKLM\Software\Microsoft\Windows NT

Controlling Virtualization

In addition to controlling virtualization at an application level by using the requestedExecutionLevel, it can also be enabled/disabled on a per-key basis for keys in the Software hive. The command line utility reg.exe has a new FLAGS option that allows administrators to tweak the settings on keys to suite their requirements.

C:\Users\karthikt>reg flags HKLM\Software\Key1 QUERY

HKEY_LOCAL_MACHINE\Software\Key1

        REG_KEY_DONT_VIRTUALIZE: CLEAR
        REG_KEY_DONT_SILENT_FAIL: CLEAR
        REG_KEY_RECURSE_FLAG: CLEAR

The operation completed successfully.

For more information on using reg.exe to control virtualization refer to the command line help using reg flags /?.

Virtualization and Auditing

Whenever auditing is enabled on a key that is being virtualized, in addition to the regular audit events a new virtualization audit event is generated to indicate that the key is being virtualized. Administrators can usage this information to monitor the status of virtualization on their systems.

Virtualization Recommendations

Virtualization is intended only to assist in application compatibility with existing programs. Applications designed for Windows Vista should not perform writes to sensitive system areas, nor should they rely on virtualization to provide redress for incorrect application behavior. When updating existing code to run on Windows Vista, developers should ensure that, during run-time, applications only store data in per-user locations or in computer locations within %alluserprofile% that have access control list (ACL) settings properly set. Refer the UAC Developer Guide for more guidelines on developing applications for Windows Vista.

Resources