Hive-Based Registry Startup Sequence (Windows CE 5.0)
Storing the registry on an external file system complicates the sequence of events that must occur to boot the system. For example, registry settings are needed to start the drivers that control the media on which the registry is stored. The solution is that a small boot registry hive is used to start only the few drivers necessary to reach the working system hive, which is in a persistent store such as a disk or flash chip. The boot hive is stored in ROM and so it does not change from boot to boot. Any changes made to it by drivers during boot will be propagated to the system hive when it becomes available, but on the next boot, the boot registry will revert to its ROM contents.
The loading of drivers in the system was broken into two boot phases. In the first phase, a small set of drivers is loaded, as specified in the boot registry. These are the drivers that are necessary to reach the file system on which the system registry is stored. When the registry is fully available, the second phase begins and another round of driver loading takes place. There are some special cases for drivers that were started in the first boot phase; they must set a particular flag to avoid being loaded a second time during the second boot phase. For more information, see Using the Hive-Based Registry. Also, because those drivers are started with the boot registry, which is in ROM, they are started with settings that will never change. If those drivers need to be configured dynamically, they may wait for the second boot phase and then reread their registry settings, because at that point the mutable system registry is in place.
The file system process (Filesys.exe) brings up the boot registry, starts Device.exe, and blocks waiting for the file system containing the system registry to be ready. The device manager loads a small set of drivers as specified in the boot registry, and then blocks waiting for the system registry to be available. The driver for the file system that contains the system registry must be marked with a bootable flag so that Filesys.exe knows what file system to wait for. When it is ready, the system registry is read from that file system. At this point, the registry is ready to go and applications are started. The second boot phase begins when it becomes time to start Device.exe in the application initialization sequence; because Device.exe is already running, an event named System/BootPhase2 is set to signal the second phase of driver loading. This event causes Device.exe to re-enumerate drivers based on the system registry.
The following illustration shows the startup sequence in detail. The order that processes run in is shown along with the periods of time that drivers are available and which registry hive is loaded at the time.
The following table describes the stages shown in the illustration.
|A||The kernel starts Filesys.exe.|
|B||Filesys.exe loads the boot registry.|
|C||Filesys.exe starts the device and blocks.|
|D||The device starts drivers based on the boot registry.|
|E||The device blocks and the boot file system is initialized.|
|F||Filesys.exe loads and mounts system registry.|
|G||Filesys.exe ready, kernel initializes using the system registry.|
|H||The kernel is ready and signals Filesys.exe.|
|I||Filesys.exe starts applications.|
|J||Instead of starting the device, Filesys.exe signals the BootPhase2 event.|
Device.exe then re-enumerates, starting drivers. Filesys.exe starts the remaining applications in the initialization key.
Send Feedback on this topic to the authors