Persisting Data with the RAM-based Registry

  • Article

The RAM-based registry supports two different save-and-restore mechanisms. OEMs can use these mechanisms to persist registry data when the RAM, which contains the object store, is not being powered. In addition, the mechanisms can also be used to provide protection against invalid data configurations.

The first mechanism is based on the APIs RegCopyFile and RegRestoreFile. RegCopyFile saves the entire registry to a file, and RegRestoreFile sets up the registry to be replaced with the data in the given file on the next boot. To persist the registry when a target device is powered off, an OEM would first use RegCopyFile to save the data to a persistent file. On the next cold boot, the OEM would call RegRestoreFile to prepare the registry to be replaced with data in the file, and perform a warm reboot to complete the registry replacement. This manner of registry persistence is easy to implement, but because it requires a dual-boot to restore the registry after a target device was powered off, it is relatively slow. The RegCopyFile and RegRestoreFile mechanism is better suited to providing backup to protect against errors than it is to providing registry persistence.

The second mechanism gives the OEM responsibility for persisting the data. An OEM can implement the WriteRegistryToOEM and ReadRegistryFromOEM functions in the OAL. These functions, if implemented, are called by the registry code to save and restore the data. When an application calls the RegFlushKey function, the OS makes a series of calls to WriteRegistryToOEM to pass the entire registry to the OEM, which stores the data on any persistent media. Then while the system is booting, the system makes another series of calls to ReadRegistryFromOEM to receive the data from wherever the OEM stored it. The difficulty in using this mechanism is that file system calls, such as CreateFile, ReadFile, and WriteFile, cannot be used to read the data from storage during ReadRegistryFromOEM. While they can be used during WriteRegistryToOEM, the block and file system drivers needed to read from external media are not started until after the registry is initialized. Therefore, implementing ReadRegistryFromOEM is difficult; code to read from the persistent media must be added to the OAL. But this mechanism has the benefit of requiring only a single boot to restore the registry, as opposed to the dual-boot required by the RegCopyFile and RegRestoreFile mechanism.

The following pairs of APIs cannot be intermixed: RegCopyFile and RegRestoreFile, and WriteRegistryToOEM and ReadRegistryFromOEM. The file produced by RegCopyFile is not the same as that produced by WriteRegistryToOEM.

To use either save-and-restore mechanism, you must understand how the OS initializes the RAM-based registry. For more information, see Initializing the RAM-based Registry.

See Also

Persisting Data with the Hive-based Registry | How to Use the IDE to Create, Customize, and Build a Platform | RAM-based Registry Initialization | Persisting Data With the RAM-based Registry Using the OAL

Last updated on Wednesday, April 13, 2005

© 2005 Microsoft Corporation. All rights reserved.