Backing Up and Restoring the Windows XP Registry

It wasn't very long after I installed XP that I was messing around with the registry. I suspect you're probably going to be doing the same thing or else you wouldn't be in this area of the site. Before you make any changes, take the time to read over this section. It's pretty dry reading material, but it might save you from finding yourself with a putty colored box that just sits there doing nothing rather than firing up XP as you would expect.

There are two ways of working with the registry; software based and direct access. The software based method is generally considered to be safe, although a badly behaved piece of software that mangles the registry can make you doubt the wisdom of this statement. Anyone who has used a computer is familiar with the software based method of making changes. Control Panel is an excellent example. Make a change to one of the Control Panel settings and almost assuredly you have initiated a change within the registry. It's just that you are insulated by Control Panel from seeing what went on behind the scenes in the registry.

Directly accessing the registry is far more dangerous. There used to be two versions of Registry Editor, regedit and regedt32, but for XP they have been incorporated in Microsoft Registry Editor Version 5.1. Type either name in the [Run] box and Version 5.1 is what you're going to end up with. The only real disadvantage of not having regedt32 anymore is the lack of read-only mode in Version 5.1, but it just means you need to be careful not to make any unintended changes when browsing through the registry. And make sure you have a valid backup and restore point.

How The Windows XP Registry is Structured

Open the Registry Editor [Fig. 01] using Start > Run and typing regedit in the Open: line and you'll see it's divided into two panes. Understanding Registry Editor is much easier if you think of the left pane as the Keys Pane and the right side as the Values Pane. In the left pane there are five (5) main divisions or root keys as shown below. I've inserted the root key abbreviations in red text behind each key.

Registry Editor uses a hierarchical structure similar to Windows Explorer but with one major difference. In Windows Explorer you have folders in both the left and right hand panes, but in Registry Editor there are never any folder icons in the right hand section. In Registry Editor the yellow folder icon really denotes a separate and distinct key. Since the right hand pane is reserved for values only there are no folders displayed in that pane.

Each of the five main keys can be expanded to reveal additional keys or what some refer to as sub-keys. Many sub-keys have sub-keys below them, in some cases the amount of sub-keys becoming almost unbelievably long, but in the same manner that Windows Explorer works, registry locations are defined by a path. Just remember that any reference to a registry location begins with one of the five root keys.

Think of the left side as Key Pane and the right side as Values Pane
Fig. 01

Notice at the bottom of Registry Editor that My Computer\HKEY_CLASSES_ROOT is displayed. This display will change as you navigate down through the registry structure; very handy for keeping track of where you are rather than having to scroll upward if the mind momentarily goes blank while you are editing.

Types of Registry Backups

It's critical that before you do any editing you make a backup of the current registry. The temptation to make 'one little change' without backing up is great. It can also be deadly. I speak from experience here, and most likely you're going to ignore this warning just like I did, but hopefully you'll be a little bit smarter than I was. That said, there are different ways of backing up so let's look at each one individually.

Backing up is simply exporting information from the registry into a file that is saved on your system. When you invoke the export function you are given a choice of different file types that can be saved.

Fig. 02

Each one of the different file types above plays an important role in how the data you export is saved. Choosing the wrong type can give you unexpected results. Understanding each type and when to use it is essential.

• Registration Files: The Registration Files option creates a .reg file. This is probably the most well known file format used for backing up the registry. The Registration File can be used in two ways. As a text file it can be read and edited using Notepad outside of Registry Editor. Once the changes have been made and saved, right clicking the file and using the [Merge] command adds the changed file back into the registry. If you make additions to the registry using regedit and then merge the previously saved Registration File, anything that you've added via regedit will not be removed, but changes you make to data using regedit that previously existed in the saved Registration File will be overwritten when it is merged.

• Registry Hive Files: Unlike the Registration Files option above, the Registry Hive Files option creates a binary image of the selected registry key. The image file is not editable via Notepad nor can you view its contents using a text editor. However, what  the Registry Hive Files format does is create an image perfect view of the selected key and allow you to import it back into the registry to ensure any problematic changes you made are eliminated.

• Text Files: This option does just as the name suggests. It creates a text file containing the information in the selected key. It's most useful purpose is creating a record or snapshot of a key at a particular point in time that you can refer back to if necessary. It cannot be merged back into the registry like a Registration File.

• Win9x/NT4 Registration Files: This option creates a .reg file in the same manner used by the Registration Files option. It's used by previous Windows versions and serves no purpose in XP unless you want to merge a key from XP into a previous version of Windows.

Considering the four choices above, the most effective and safest method of backing up the registry is to use the Registry Hive Files option. No matter what goes wrong in your editing, importing the image of the key will eliminate all changes, additions, or other things that might have occurred.

If you want to edit outside the confines of regedit, or if you are sure you want your additions to the registry to remain even if you have to merge, use Registration Files for your backup.

If you just want a copy of the key that can be referenced using a text editor, but want to eliminate any chance of the file being accidentally merged back into the registry, use Text Files.

The Actual Backup Process

The actual process of backing up the registry is quite simple once you've decided the file type for the backup and whether you want to back up an individual key or the entire registry. In the left hand pane of regedit, select the key to be backed up, right click and select [Export] to open the Export Registry File Property Sheet. From there, it's merely a matter of assigning the backup a descriptive filename and selecting the type of  backup file you want based on the discussion above. To be on the safe side, it certainly wouldn't hurt to make a backup in both Registry Hive Files and Registration Files formats.

There are two notes you should be aware of regarding what can be backed up using specific file types.

• If My Computer is selected in the left pane of regedit, you will not be allowed to make a backup using the Registry Hive Files format. This is equivalent to backing up the entire registry. XP requires you to use the System State backup in this instance. (Backing up the System State is discussed further down in this article)

• If My Computer is selected in the left pane of regedit, you may select Registration Files as the backup file format but this is not the recommended method for a complete registry backup.

In the following sections I'm going to refer to this screen capture frequently to help illustrate the different methods of backup.

Fig. 03

--Backing Up Individual Values--

Take a quick look at Fig. 03 and you'll note it displays the HKEY_CURRENT_USER\Control Panel\Desktop key. In the Values Pane you'll see the WaitToKillAppTimeout value that is currently set to 4000. It will be the subject of backing up individual values.

It's important to remember that the registry is really just a big compilation of data and settings that sits there waiting to be accessed by XP itself or by an installed application. By itself it does nothing. At first glance that may not seem to be of much importance, but it can be useful when you consider that the truly useful information in the registry is stored in the values. Look at the majority of registry edits and you'll see they involve changing values, not adding or removing keys. Combine that knowledge with the fact that XP or an application has to be programmed to access the values or else they are useless and that provides a quick, easy way to back up individual values.

Fig. 04 illustrates how the previous information is applied to backing up values of keys that might be modified. It's important to note that this section applies to values, not keys. For this example I have decided to modify the value of the string WaitToKillAppTimeout. The WaitToKillAppTimeout string value highlighted in red is the original string value with a value of 5000 that I'm going to modify. Once I modify the value I might forget what the original value was (5000) before I decide if the change I make is appropriate. To guard against the original value being forgotten, I've created the string value TEG_WaitToKillAppTimeout that's shown highlighted in green. For this tutorial I've used TEG_ before the real value name but you can use anything convenient. If your dog was named Fido, you might use Fido_ before the real value name.

Fig. 04

Now, looking at the screen capture below, I can go back to the original string value (the one highlighted in red) and make the change to the new (4000) value. At this point the question is often asked why having the two values listed in the registry doesn't cause a conflict. Remember what was said previously; XP or an application has to be programmed to access the values or else they are useless. There is no application or part of XP that is programmed to look for a string value named TEG_WaitToKillAppTimeout so it can happily co-exist with WaitToKillAppTimeout, providing a journal or record of what changes have been made to the registry. For a more detailed record you can add a date to the prefix which might look like TEG08252003_WaitToKillAppTimeout that is shown highlighted in blue.

Fig. 05

If the change doesn't work out all you have to do is reference the backed up entry (the one highlighted in green or blue) for the original value and change the value that was modified (the one in red) back to the original value. An easier way to revert back to the original value is to delete the modified string (the one in red) and then right click the backup strings (green or blue) and select Rename. Eliminate the prefix that was added to return the string to its original configuration.

If you do a lot of registry tweaking and modification of existing values this is an excellent method because it provides a visual record of any modifications that have been made to the registry values. Two months from now if I want to know if I made a modification to the WaitToKillAppTimeout value, all I have to do is open Registry Editor, navigate to the HKEY_CURRENT_USER\Control Panel\Desktop key and compare the WaitToKillAppTimeout with the backup entries. By using the dated prefix I can not only tell what change was made but what date it was modified. After the value modification has been tested you can go back and remove the new prefixed values that were created if it bothers you having them remain in the registry. I always leave them as a permanent record and have never noticed any problems or system performance penalty.

-- Backing Up Individual Keys --

Prefix Method

One of the first questions that always comes up after reading the previous section --Backing Up Individual Values-- is what happens if the prefix method is used to back up keys rather than just individual values. It's a good question and I'll go through another example to try and explain one possible scenario.

In the previous section we were working in the HKEY_CURRENT_USER\Control Panel\Desktop key so lets apply a prefix to the Desktop key and see what happens.

• Open Fig. 06 to see HKEY_CURRENT_USER\Control Panel\Desktop before any changes are made. Note that HKEY_CURRENT_USER\Control Panel\Desktop also has a sub-key WindowMetrics.
• Open Fig. 07 to see the change made to HKEY_CURRENT_USER\Control Panel\Desktop. Nothing has been altered other than adding the TEG_ prefix to the Desktop key. No changes were made to the sub-key WindowMetrics.

What do you think happened when the change was made and the user logged off and back on?

• Open Fig. 08 and you'll see that XP automatically recreated the HKEY_CURRENT_USER\Control Panel\Desktop key that is shown with the green highlight. However, it's a far cry from what the original HKEY_CURRENT_USER\Control Panel\Desktop key looked like before it was modified to TEG_HKEY_CURRENT_USER\Control Panel\Desktop. There is only one entry in the Values Pane and that is Default, plus there is no sub-key for WindowMetrics. You can also see that the default Bliss background is also missing from the desktop.

         
  Fig. 06                    Fig. 07                     Fig. 08

So, what does this tell us about adding a prefix as a method of backing up keys? First and foremost it shows that while it yields some interesting results it's not a suitable method for backing up registry keys. The results are unpredictable at best and when you're dealing with the registry you want a method that's rock solid. That's not to say though that the procedure is totally without merit when it comes to keys. As a troubleshooting tool it can be handy to rename a key with a prefix and then see if XP  or even an application will recreate the basic key. In effect the prefix hides the registry key from XP so you can see what effect deleting the key would have while still giving you a method of restoring the key that was hidden by the prefix.

The bottom line is; play around with this method but make sure you have another proven backup in place first.

.REG File Method

Unlike the previous methods discussed, using .reg files to back up individual keys and entire branches of the registry is a well established, proven method that is used daily by millions of registry tinker er's. Refer back to Fig. 03 and the HKEY_CURRENT_USER\Control Panel\Desktop key that is highlighted in the Key Pane.

The actual backup procedure is simple. In the Keys Pane, right click on the individual key (in this case Desktop) you want to back up, click [Export], assign the backup a descriptive filename and select the type of  backup file being created. In Fig. 09 I used the file name Desktop and because we are discussing .reg backups I selected Registration Files [*.reg] as the file type.

Fig. 09

Notice the radio button by [Selected Branch] that details what key is actually being saved. A quick check of this information can help prevent ending up with a backup of the wrong key that might not be discovered until it's too late. Once [Save] is clicked the key will be saved to a file named Desktop.reg in the location you specify. Some additional points;

• When the key entry point for the backup is determined, in this case HKEY_CURRENT_USER\Control Panel\Desktop, all the sub-keys beneath that point will also be backed up. In this example, that means that in addition to HKEY_CURRENT_USER\Control Panel\Desktop you will also be backing up HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics.
• Often times users accidentally move higher up in the registry hierarchy when backing up than is necessary. In this example, if I'd set the key entry point for HKEY_CURRENT_USER\Control Panel, the intended key HKEY_CURRENT_USER\Control Panel\Desktop would be backed up, but in addition many other unnecessary keys would also be a part of the backup. Keep specific key backups as compact as possible by not traveling up the key hierarchy further than is necessary. To illustrate how the .reg file can quickly increase in size if an incorrect entry point is selected take a look at the table below. It's quickly apparent that the last choice highlighted in red is the way to go. Not only will it require less disk space to save, it can be merged quickly and is easier to edit, if necessary, with less chance of error.

Restoring a .REG File Backup

There are four ways of restoring a .reg file backup. I want to look at the methods in a bit more detail.

• Method One - From the Registry Editor menu bar select File > Import... and then navigate to where the .reg file is saved. Select the file and click Open. The contents of the .reg file will be merged into the current registry followed by a confirmation dialog stating the information in the file has been successfully entered into the registry. This is a low risk method because it forces you to consciously select the .reg file you want to import. Hopefully your mind is focused on the task at hand and the proper .reg file is selected.
• Method Two - By default, Windows XP is configured so that when a .reg file is double-clicked it's automatically merged into the registry. To my way of thinking this is a rather high risk method, especially if you happen to double-click the wrong .reg file. Fortunately, this method does present a dialog box that states the name of the .reg file and asks if you're sure you want to add the contents of the file to the registry, then waits for your Yes or No confirmation. A Yes response will generate a confirmation dialog stating the information in the file has been successfully entered into the registry. Clicking No will end the process with no information being entered in the registry.
• Method Three - Navigate to where the .reg file is saved and right click the file to open the context menu. Select Merge and a dialog box appears that states the name of the .reg file and asks if you're sure you want to add the contents of the file to the registry, then waits for your Yes or No confirmation. A Yes response will generate a confirmation dialog stating the information in the file has been successfully entered into the registry. Clicking No will end the process with no information being entered in the registry.
• Method Four - Navigate to where the .reg file is saved and right click the file to open the context menu. Select Open With > Registry Editor and a dialog box appears that states the name of the .reg file and asks if you're sure you want to add the contents of the file to the registry, then waits for your Yes or No confirmation. A Yes response will generate a confirmation dialog stating the information in the file has been successfully entered into the registry. Clicking No will end the process with no information being entered in the registry.

The Downside of the .REG File Backup Method

I touched briefly on this information in the Types of Registry Backups section at the beginning of this tutorial but it bears a repeat visit. The basic weakness in a .reg file backup boils down to a two word war; Merge versus Replace. Assume for a moment you've made a .reg backup and safely tucked it away. You go ahead and edit the registry using Registry Editor, but unfortunately your changes don't work as planned. You turn to the .reg backup file and expect that running it will restore the registry to the way it was prior to your edits. Will it really do so or are your expectations about to be dashed?

The answer is; Maybe, depending on what edits you made. This is where Merge versus Replace comes into play. let's look at some If/Then statements.

• [If] a value exists in the .reg file and also exists in the modified registry [Then] the value will be changed in the registry.
• [If] a value exists in the .reg file but not in the modified registry [Then] the value will be added to the registry.
• [If] a value does not exist in the .reg file but does exist in the modified registry [Then] the value will not be removed or changed in the registry.
• [If] a value does not exist in the .reg file and does not exist in the modified registry [Then] there is no action to be taken in the registry.

The third item above, highlighted in red, is where the trouble or weakness with .reg backup files occurs. As long as the modifications made to the registry don't stray outside the bounds of what was included in the .reg backup things are fine. But if you've added a new key or value during the editing process there can be trouble. Importing the .reg backup file does not replace or remove additions to the registry that are not referenced in the .reg backup file.

Ultimately, it's up to you to determine if the .REG File Method will be suitable for the particular changes you're going to be making. Unless you're 100% certain you're only going to be modifying existing values and not creating any new keys or values you're better off using Hive File Backups that will be discussed in the next section.

Hive File Method

Hopefully you just read the section above about using .REG Files for registry backups. Except for a couple of weak points they do an admirable job of registry backup. The Hive File Method, while very similar to the .REG File Method, eliminates the weak points and should be your preferred method of backing up the registry. I'm still using Fig. 03 as the basis for this discussion.

Like .reg files, the actual backup procedure for creating hive files is simple. In the Keys Pane, right click on the individual key (in this case Desktop) you want to back up, click [Export], assign the backup a descriptive filename and select the type of backup file being created. In Fig. 10 I used the file name Desktop and because we are discussing hive file backups I selected Registry Hive Files [*.*] as the file type. When creating hive file backups you need to supply an extension for the file being created. The two most common extensions used are .dat and .hiv. As shown below I opted to use the .hiv extension, making the file name Desktop.hiv.

Fig. 10

Notice the radio button by [Selected Branch] that details what key is actually being saved. A quick check of this information can help prevent ending up with a backup of the wrong key that might not be discovered until it's too late. Once [Save] is clicked the key will be saved to a file named Desktop.hiv in the location you specify. Some additional points;

• When the key entry point for the backup is determined, in this case HKEY_CURRENT_USER\Control Panel\Desktop, all the sub-keys beneath that point will also be backed up. In this example, that means that in addition to HKEY_CURRENT_USER\Control Panel\Desktop you will also be backing up HKEY_CURRENT_USER\Control Panel\Desktop\WindowMetrics.
• Often times users accidentally move higher up in the registry hierarchy when backing up than is necessary. In this example, if I'd set the key entry point for HKEY_CURRENT_USER\Control Panel, the intended key HKEY_CURRENT_USER\Control Panel\Desktop would be backed up, but in addition many other unnecessary keys would also be a part of the backup. Keep specific key backups as compact as possible by not traveling up the key hierarchy further than is necessary. To illustrate how the hive file backup can quickly increase in size if an incorrect entry point is selected take a look at the table below. It's quickly apparent that the last choice highlighted in red is the way to go. Not only will it require less disk space to save, it can be imported quickly.

Restoring a Hive File Backup

To restore a hive file backup

• Open Registry Editor
• Navigate to the location in the Key Pane (left pane) where the hive file backup is to be imported. This is an absolutely critical step. Do not ignore it or the hive file backup will be imported to the wrong location.
• Click File > Import...
• Make sure [Files of Type] is set to Registry Hive Files [*.*]
• Navigate to the location where the hive file backup is saved, click the file, then click Open.
• The dialog box shown in Fig. 11 will be displayed.

Fig. 11

• Verify the information in Confirm Restore Key dialog is correct and click Yes. If it's incorrect, click No.
• A Yes response will generate a confirmation dialog stating the information in the file has been successfully entered into the registry. Clicking No will end the process with no information being entered in the registry.

There's a lot of red cautionary text in the restore instructions above, and with good reason. Look at Fig.11 again and note the line The Key Will Be Restored On Top Of Key: Desktop. Now look at Fig.12 below. Notice the same line now reads The Key Will Be Restored On Top Of Key: Control Panel. If you're thinking to yourself, big deal, click here and look at the comparison registry screen captures with an explanation of how the disaster occurred.

Fig. 12

Restoring a Hive File Backup to the wrong location can wipe out substantial chunks of the registry and virtually ensure the system will not function. I don't know if there is a 'best' way to protect against this happening, but I can tell you how I minimize the possibility. Whenever I create a Hive File Backup I always give it a descriptive file name based on its intended restore location. A good choice in this example might be HKCUControlPanelDesktop.hiv. I also store each backup file in a separate folder and include in the folder, along with the file, another small text file created in Notepad that details when and why I created the backup file and the registry path where the file should be imported. Is my method overkill? Probably, but then I've yet to import a hive backup to the wrong location so for now I'll stick with overkill.

-- Backing Up the System State --

Backing up the System State includes the registry, the COM+ Class Registration Database, and boot files. Windows XP comes with Backup Utility accessible via [Start] [All Programs] [Accessories] [System Tools] [Backup]. In the Advanced Backup Wizard there is a setting to back up the System State either to one of the hard drives or a different media of your choosing. If the registry does become corrupt, the System State backup is used to restore the system.

12/29/2004 - I received a note from TEG visitor Dave stating "The backup utility is not included in the initial install of xp, you have to add it from the disk yourself." What Dave says is true in the Home Edition of XP as backup isn't installed by default. In the Professional Edition of XP the backup utility can be accessed as I stated above. If the backup utility is missing from your installation I suggest reading through The Backup Utilities in Windows XP section here. Dave also included a link to a page that gives more info on how this is accomplished. Thanks for the reminder Dave.

-- System Restore --

The last method of backing up the registry is using System Restore, another utility that is included with Windows XP. System Restore is best likened to a camera taking a complete snapshot of your computer system at one point in time and storing that image in what is called a restore point. This restore point can then be recalled at some point in the future, effectively overwriting any changes that have been made to the computer since the restore point was created. A more complete description of System Restore is available here.

Which Backup Method is Best?

Truthfully, I think it's a matter of personal preference, and since this is my site I'll take the liberty of giving you my choice and the reason why. All of the methods are good and offer some level of protection against disaster. None of the methods require an undue amount of time to complete and are well worth the security and peace of mind they supply. Bearing that in mind, I'd recommend using as many methods as time and practicality allow before editing the registry.

If I was limited to only one choice of backup before editing the registry I'd probably choose the Hive File method, but System Restore would also be a contender. The changes that occur when you edit the registry can be far reaching, well beyond just the particular key that is edited, and may not show up immediately. For that reason alone, System Restore affords protection to the entire system rather than just a single key, and if I do notice a side issue hours or days later after an editing session I can restore to a well tuned system.

Now that you've formulated your own best plan and methods for backing up the registry just in case things don't go as you'd planned, it's time to move onward to:

Registry Edits for Windows XP

Enjoy !