The Windows Registry 6






Registry Virtualization


Registry virtualization is an application compatibility technology that enables registry write operations that have global impact to be redirected to per-user locations. This redirection is transparent to applications reading from or writing to the registry. It is supported starting with Windows Vista. This form of virtualization is an interim application compatibility technology; Microsoft intends to remove it from future versions of the Windows operating system as more applications are made compatible with Windows Vista. Therefore, it is important that your application does not become dependent on the behavior of registry virtualization in the system.


Virtualization Overview


Prior to Windows Vista, applications were typically run by administrators. As a result, applications could freely access system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access rights. Windows Vista improves application compatibility for these applications by automatically redirecting these operations. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user's profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software). Registry virtualization can be broadly classified into the following types:


Virtualization Type



If the caller does not have write access to a key but opens the key with KEY_ALL_ACCESS, the key is opened with the maximum allowed access for that caller. If the REG_KEY_DONT_SILENT_FAIL flag is disabled for a key, this implicitly disables virtualization for that key.


If the caller does not have write access to a key and attempts to write a value to it or create a subkey, the value is written to the virtual store.

For example, if a limited user attempts to write a value to the following key: HKEY_LOCAL_MACHINE\Software\AppKey1, virtualization redirects the write operation to HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1.


If the caller reads 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. For example, suppose HKEY_LOCAL_MACHINE\Software\AppKey1 contains two values V1 and V2 and that a limited user writes a value V3 to the key. When the user attempts to read values from this key, the merged view includes values V1 and V2 from the global store and value V3 from the virtual store.

Note that virtual values take precedence over global values when present. In the example above, even if the global store had value V3 under this key, the value V3 would still be returned to the caller from the virtual store. If V3 were to be deleted from the virtual store, then V3 would be returned from the global store. In other words, if V3 were to be deleted from HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1 but HKEY_LOCAL_MACHINE\Software\AppKey1 had a value V3, then that value would be returned from the global store.


Registry Virtualization Scope


Registry virtualization is enabled only for the following:


  1. 32-bit interactive processes.
  2. Keys in HKEY_LOCAL_MACHINE\Software.
  3. Keys that an administrator can write to. (If an administrator cannot write to a key, then the application would have failed on previous versions of Windows even if it was run by an administrator.)


Registry virtualization is disabled for the following:


  1. 64-bit processes
  2. Processes those are not interactive, such as services. Note that using the registry as an inter-process communication (IPC) mechanism between a service (or any other process that does not have virtualization enabled) and an application will not work correctly if the key is virtualized. For instance, if an antivirus service updates its signature files based on a value set by an application, the service will never update its signature files because the service reads from the global store but the application writes to the virtual store.
  3. Processes that impersonate a user. If a process attempts an operation while impersonating a user, that operation will not be virtualized.
  4. Kernel-mode processes such as drivers.
  5. Processes that have requestedExecutionLevel specified in their manifests.
  6. Keys and subkeys of HKEY_LOCAL_MACHINE\Software\Classes, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows, and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT.


Controlling Registry Virtualization


In addition to controlling virtualization at an application level by using requestedExecutionLevel in the manifest, you can also enable or disable it on a per-key basis for keys in HKEY_LOCAL_MACHINE\Software. The command line utility Reg.exe has a new FLAGS option that administrators can use for this purpose.


C:\>reg flags HKLM\Software\AppKey1 QUERY








The operation completed successfully.


The Windows reg command and its options


Whenever auditing is enabled on a key that is being virtualized, a new virtualization audit event is generated to indicate that the key is being virtualized (addition to the usual audit events). Administrators can use this information to monitor the status of virtualization on their systems. Virtualization is intended only to provide compatibility for existing applications. Applications designed for Windows Vista should not write to sensitive system areas, nor should they rely on virtualization to remedy any problems. When updating existing code to run on Windows Vista, developers should ensure that applications only store data in per-user locations or in computer locations within %alluserprofile% that properly use an access control list (ACL).





< Windows Registry 5 | Windows Registry Index | Win32 Programming | Windows Registry 7 >