Hive-Based Registry Stored in RAM (Windows CE 5.0)

Article
09/14/2012

You can specify a region of RAM to store a registry hive in, 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 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 retrieve the necessary information for storing the hive-based registry.

Rather than using a file on the file system, the registry data is stored directly in the region of RAM. There can only be 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 have to 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 equal to zero prevents Device.exe from starting in the first boot phase. Setting NoDefaultUser equal to zero simply logs in a default user.

Storing the hive-based registry in RAM and the incorporation of the user hive into the same RAM space has certain implications, as follow:

There is no OS-provided save-and-restore mechanism for the registry when it is stored in the RAM region. RegCopyFile, RegRestoreFile, RegReplaceKey, WriteRegistryToOEM and ReadRegistryFromOEM are not supported. The registry data persists as long as its region of RAM persists, and atomic transactioning of changes protects the registry data against corruption. RegSaveKey is supported; when an application calls RegSaveKey, the OS will make a call to the OEM's implementation of IOCTL_HAL_SAVE_HIVE_RAM_REGION. This mechanism allows the OEM to save the registry when it is in a steady state.
RegFlushKey is unsupported. The RAM region assumes persistence, so there is no need to flush anything.
IOCTL_HAL_GET_HIVE_CLEAN_FLAG is applicable in this case and you can use it to force the registry to be cleaned. However, because there is only one user and the data for that user is stored together 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 there will not be any user registry data 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.
The registry security mechanism applies with no differences.
Because VirtualCopy receives the region of RAM to obtain a virtual address to access the RAM with, the region resides inside 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. Therefore, limit the registry RAM region to 2 MB or less if possible.
There is only one copy of user data stored. You can still implement multiple-user support by leaving the data under the HKEY_CURRENT_USER subtree. All users share the data under this subtree. SetCurrentUser will still succeed in switching between users. User profile directories will still be created for each user, and will be placed in the object store as specified by the "ProfileDir" registry subkey. For more information see User Profile Storage.

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.

Partager via

Hive-Based Registry Stored in RAM (Windows CE 5.0)

See Also

Ressources supplémentaires