OS updates and the hive-based registry
Posted by: Sue Loh
I attempted to document this behavior in the file that has become https://msdn.microsoft.com/library/en-us/wcedata5/html/wce50conUpgradingtheHiveBasedRegistry.asp. It is not very discoverable information though, I fear. And some of the information in that doc has gotten vague as more hands have crossed over it. I swear there used to be more information there, but it has disappeared into the void. Here I'll attempt to recreate it.
The system.hv and user.hv file on your device's persistent store are tied to default.hv and user.hv in ROM. All of these files have an MD5 hash of your "reginit.ini" file from your release directory stored in them. If you build a new image with a new system.hv/user.hv, then the MD5 hash in those files will be different than the hash in the ones on the persistent store. If you download the new image onto a device with persistent registry files that went along with a previous image, the persistent files will be deleted during boot. They MUST be deleted, really, because the persistent files contain many cross-links to the data inside the ROM files, which will be invalid if you change the ROM files. The registry would be severely broken. We don't delete the files just to be annoying, but because we have no choice.
You might find that on day-to-day rebuilds, you can keep your registry. That happens if you haven't changed any of the .reg files that go into your image, because reginit.ini would still be the same, so even if you rebuild new default.hv/user.hv files for ROM, they have the same hash stored inside them and the persistent files can still work. But as soon as you modify a .reg file, even just to add whitespace or comments, your persistent files will be wiped.
You actually have two options, if you need to update the image without losing the persistent registry.
- Probably your best option for your update is to keep the same system.hv/user.hv in ROM, and store any registry changes that go with the update in a separate file of your own. Then you'd have to write a program to import those changes to the registry during the update. You can keep the same file if you don't change .reg files at all -- but chances are, as part of your own work, you may have already changed them and have no hope to recover the original files. What you can do instead is get the default.hv/user.hv from the original ROM, and swap them into your new image via makeimg tricks like writing your own preromimage.bat.
- (Sigh) I just went looking for documentation explaining that batch file, and it is lacking -- suffice to say, there are a few batch files that the build system looks for during makeimg, to let you write your own scripts to affect the image at different points during the image building process. preromimage.bat runs at about the last step of the image-building process: after the registry has been built but before everything has been built into the image. If you write a preromimage.bat and set up your system to copy it into your release directory, then you can use preromimage.bat to do things like copy previously-saved default.hv/user.hv into your release directory, so that those go into the image instead of the ones that are built from your own .reg files. I don't know what other .bat file call-outs there might be, but I think there might be preregcomp.bat, postregcomp.bat, prefmerge.bat, postfmerge.bat. Look here for a little more info.
- This option means you'd probably have to build some tool to parse your reginit.ini and pull out the things that are different from what is in the default.hv/user.hv that you'd be putting into ROM. We don't have anything to help you do that. :-( Nor do we have anything to help you import those differences to the persistent registry during the update.
- The alternative is to enumerate the entire registry to some file of your own before the update, then do the update (which would give you a completely new registry), then import the settings from the file you exported after the update. The tricky thing there is to know what settings NOT to write -- since your update might have changed some settings.
Neither option is great, I know. The image update solution that is built into Windows Mobile 5.0 and that will possibly ** be available in future embedded releases deals with this problem basically by putting an empty default.hv/user.hv in ROM from the start, and importing everything during the first boot after an update.
** I have to say "possibly" because I can never promise what is going to be in future releases. I cannot guarantee anything.