Hive-Based Registry Stored in RAM

Other versions of this page are also available for the following:

Windows Mobile Not SupportedWindows Embedded CE Supported

8/28/2008

You can specify a region of RAM in which to store a registry hive, rather than using the hive as a memory-mapped file on a file system. Presumably, the region of RAM is static RAM (SRAM) chip or similar permanent storage, although it can also be a reserved area of RAM specified in the Config.bib file.

When the file system brings up the registry, the file system calls IOCTL_HAL_GET_HIVE_RAM_REGION to obtain the necessary information for storing the hive-based registry.

Rather than using a file in the file system, the registry data is stored directly in the region of RAM. There can be only one user, and the user data is stored in the same RAM region as the system data. If you want to support multiple users, all users must share the same data under the HKEY_CURRENT_USER registry subtree.

To support IOCTL_HAL_GET_HIVE_RAM_REGION, you must set certain registry keys to specified values. The following registry key example shows how to support IOCTL_HAL_GET_HIVE_RAM_REGION:

[HKEY_LOCAL_MACHINE\init\BootVars]
"Flags"=dword:0
"NoDefaultUser"=dword:0

Setting Flags to zero prevents Device.exe from starting in the first phase of startup. Setting NoDefaultUser to zero simply logs a default user on.

Storing the hive-based registry in RAM and the incorporation of the user hive into the same RAM space has the following implications:

  • The OS provides no save-and-restore mechanism for the registry when it is stored in the RAM region.
  • The following registry functions are not supported:
  • Registry data persists as long as its region of RAM persists.
  • The registry security mechanism applies with no differences.
  • The registry stores only one copy of user data.
    You can implement multi-user support by leaving the data under the HKEY_CURRENT_USER subtree. In this scenario, all users share the data under this subtree.
    • SetCurrentUser switches between users.
    • User profile directories are still created for each user and placed in the object store as specified by the "ProfileDir" registry subkey. For more information see User Profile Storage.

Best Practices

The following practices can help make a RAM-based hive registry successful:

  • Protect registry data against corruption by using atomic transactioning of changes. You can use RegSaveKey. When an application calls RegSaveKey, the OS calls the OEM implementation of IOCTL_HAL_SAVE_HIVE_RAM_REGION. This mechanism enables the OEM to save the registry when it is in a steady state.
    If the OAL does not support IOCTL_HAL_GET_HIVE_RAM_REGION, or if IOCTL_HAL_GET_HIVE_RAM_REGION fails for any reason, the registry hives are stored in the object store.
  • Use IOCTL_HAL_GET_HIVE_CLEAN_FLAG to force the registry to be cleaned. However, because there is only one user and the data for that user is stored with the system data, there is only one call to IOCTL_HAL_GET_HIVE_CLEAN_FLAG, along with HIVECLEANFLAG_SYSTEM, to determine whether you want to clean the entire registry.
    If you clean the registry, the cleaning does not affect the user profile directories. While no user registry data will be stored in the user profile directories, these directories may be used to hold other user-specific data and settings. Therefore, you are responsible for implementing your own cleanup mechanism to remove user profiles.
  • Limit the registry RAM region to 2 MB or less, if possible. Registry stored in RAM resides in the memory space of Filesys.exe, as long as it is under 2 MB in size. If the region is larger than 2 MB, it will be in public memory space. This is significant because in public memory space, any application can read and overwrite the data stored in the region.

See Also

Concepts

Hive-Based Registry

Other Resources

Registry
IOCTL_HAL_GET_HIVE_RAM_REGION
IOCTL_HAL_SAVE_HIVE_RAM_REGION