Configuring the registry can help you customize your system so that it better meets your needs. However, the registry of any Windows OS is delicate. Because of the registry's fragility, the possibility of damaging the registry exists when you enter changes programmatically or manually. Thus, having backup files that you can use to restore all or part of the registry is good practice, especially if you're planning to use scripts to automate the registry-manipulation process.
Understanding the registry's structure is key if you want to perform complete or partial registry backups. Although the registry's programming interface has remained roughly the same in the various OSs from Windows 9x to Windows 2000, the internal structure has changed quite a bit. The structure of Win9x's registry differs significantly from the structure of Win2K's registry. Here's a look at the Win9x and Win2K structures and how you perform backup and restore operations in each registry.
Win9x's Registry
In Win9x, the registry consists of two files: system.dat and user.dat. Both files reside in the Windows folder and are marked Hidden. So, unless you've selected the Show hidden files and folders option in Windows Explorer's Folder Options dialog box, chances are that you've never run across them.
System.dat contains information about the local machine and the OS software, user applications, and COM components installed on that machine. User.dat contains user-specific information that applies to the OS software and user applications.
System-provided tools, such as regedit, render the content of system.dat and user.dat. These tools organize this content into the various registry subtrees. System.dat provides the content for the HKEY_CLASSES_ROOT and HKEY_LOCAL_MACHINE subtrees, whereas user.dat provides the content for the HKEY_CURRENT_USER and HKEY_USERS subtrees.
Upon installation, Win9x automatically creates a backup copy of the registry in a file called system.1st and places that file in the root directory of the C drive. System.1st contains just enough information to make Win9x work. You can think of this file as an early snapshot of the registry. This file contains only system information because, upon installation, you haven't registered any users yet.
In case of serious problems, you can replace system.dat with system.1st. Although you'll lose all application-specific information and information about any COM objects you've installed, you'll get rid of the misbehaving information in the registry. You'll have a registry that's in a consistent state (i.e., a registry in which the data conforms to the necessary formats and requirements and isn't internally contradictory), which is what you need when you start to reinstall all your applications.
System.1st doesn't play a role in the daily operations of Win9x, so you can safely delete or move this file without affecting the way in which Win9x works. If you can delete or move system.1st, it stands to reason that you can also replace it. If you replace system.1st with a copy of the system.dat file and create a user.1st file from the user.dat file, you'll have backup files that you can use to restore the registry.
This backup strategy works well in Win95. In Win98, however, you don't need to follow this strategy because this OS has an interesting automatic backup utility called Scanregw. (Windows Me also has this utility and a registry structure similar to that in Win98.) On startup, Win98 silently launches this utility to check the registry. If the registry is working properly, Scanregw makes backup copies of four files: system.dat, user.dat, win.ini, and system.ini. Although win.ini and system.ini aren't part of the registry, the utility backs them up because they contain important information about some of the registry's API functions. Thus, if you have Win95, you might consider backing up these files in addition to replacing system.1st with system.dat and creating user.1st from user.dat.
Scanregw places system.dat, user.dat, win.ini, and system.ini into a cabinet (.cab) file. At any time, you have at least five .cab files in the Sysbckup folder under the Windows directory. The utility names these files rb00x.cab, where rb stands for registry backup and 00x is a number between 000 and 004. For example, the file containing the fifth backup is rb004.cab. The next time you start Win98, the utility replaces the existing rb000.cab with the new backup file. Scanregw makes a backup file only if you start Win98 from scratch and not if you restart it or wake it up. By default, Scanregw doesn't back up the registry more than once a day. However, you can manually run the utility at any time to make backup copies as often as you want.
To restore the Win9x registry, you need to replace the corrupted files with the backup files. You can't replace these files from within Windows because the registry files are in use, and Win9x doesn't have a built-in wizard to restore the registry. In addition, if you have Win98 and you use a .cab file, that file isn't easy to manipulate outside Windows. So, to restore the registry, you need to follow these steps:
- Extract system.dat, user.dat, win.ini, and system.ini from the .cab file, if applicable.
- Copy system.dat, user.dat, win.ini, and system.ini to a temporary directory.
- Shut down your system.
- Restart your system in DOS mode. From the command prompt, use DOS commands to make the substitution.
Win2K's Registry
Win2K's registry has a more modular structure and contains more files than Win9x's registry. (Windows NT's registry structure is similar to that in Win2K.) Table 1 shows the files that form the registry in Win2K.
In Win2K, Microsoft split system.dat into four groups of files: Sam, Security, Software, and System. You can find these files in the C:\winnt\system32\config folder. Microsoft split user.dat into three groups of files: Default, ntuser.dat, and usrclass.dat. The Default file is in the C:\winnt\system32\config folder. The ntuser.dat and usrclass.dat files are in user-specific folders in directories under C:\documents and settings.
When you're looking through the various folders that contain the registry files, you might notice files with a .sav or .log extension. Files with the .sav extension are temporary registry backup files that Win2K created during the setup process. These files speed the startup process if you reboot before the OS is running; during the reboot, Win2K doesn't read the registry but instead reads an updated .sav file, if available. Files with the .log extension are internally used logs. These logs record information about all the activity and updates entered in the registry during a session.
To back up the Win2K registry, you use Win2K's Backup utility. Under the Start menu, navigate to Programs, Accessories, System Tools. In the Tools menu, select Create an Emergency Repair Disk, then check the option you want to use to back up the registry files. To create the Emergency Repair Disk (ERD), you need a 3.5" floppy disk. Despite appearances, the utility doesn't copy the registry contents onto the floppy disk. With the average registry size being about 20MB, copying to a floppy disk isn't feasible. (For more information about the registry's size, see the sidebar "The Maximum Size of the Registry.") The Backup utility copies the registry contents in the C:\winnt\repair\regback folder. Treat the files in this folder with care—never delete or move them.
You'll also find registry backup files under C:\winnt\repair. However, these files date back to the latest Win2K installation. Thus, these files are similar to the system.1st file in Win9x in that they contain only basic system information.
You can use the Task Scheduler to schedule the Backup utility to perform regular backups. The application to invoke is Backup, and you make it copy, at minimum, the files under the C:\winnt\system32\config folder.
To restore the registry, you can use the Backup utility's Restore Wizard. The wizard provides detailed onscreen instructions. In case of severe registry damage, you can use the ERD you created to start and log on to Win2K.
Backing Up Part of a Registry
A full backup of the registry is crucial in the recovery from a severely damaged system. Sometimes, though, you might need to back up only a small portion of the registry. For example, suppose you're about to run code that changes several registry settings in only one subtree. In this case, a full backup is overkill. You only need to back up the subtree in which you'll be changing the settings.
To save a subtree's content, you use regedit's export tool. The export tool lets you not only browse but also save and restore registry settings. Here's how you back up a subtree in Win2K's regedit. (You can perform this procedure in NT's, Windows Me's, and Win9x's regedit as well. However, the option names might differ slightly.) To save a subtree, highlight that subtree, then select Export Registry File from the Registry menu. In the Export Registry File dialog box that Figure 1 shows, specify the filename and the location for that file, and click Save.
In the Export Registry File dialog box, note the All option in the Export range box. By selecting this option, you can export the entire registry. However, as Figure 2 shows, the export tool's output is in plaintext, which typically takes up a lot more space than binary data. Thus, although using the Export Registry File tool is perfect for backing up a subkey, key, or small subtree, this tool is impractical for backing up the entire registry.
Interestingly, regedit's export tool lets you port the content of a subtree from one machine to another. You save the subtree as a .reg file, then place that file on the target machine (or a network shared folder). The Windows shell provides special support for .reg files, so all you need to do is double-click the .reg file to prompt the registry to automatically import the content of that .reg file. The imported content replaces the value of any existing subkey or entry with the same name in the target machine. Thus, you can use regedit's export tool to restore a registry subtree.
Next Month
I'm close to finishing the registry tour that I started back in the December 2000 issue. Next month, I'll discuss the registry in a networked environment and how to manually and programmatically access a remote registry.