3.1 Getting to Know the Registry Editor

Although the Registry is stored in multiple files on your hard disk, it is represented by a single logical hierarchical structure, similar to the folders on your hard disk. The Registry Editor (Regedit.exe) is included with Windows XP to enable you to view and manually edit the contents of the Registry.

Don't confuse the Registry with the Registry Editor. Regedit.exe is just another application; most of the access to the Registry is performed behind the scenes by the applications that you run, as well as by Windows settings and other information are read from and written to the Registry constantly.

When you open the Registry Editor, you'll see a window divided into two panes (as shown in Figure 3-1). The left side shows a tree with folders, and the right side shows the contents of the currently selected folder. Now, these aren't really folders it's just a convenient and familiar method of organizing and displaying the information stored in your Registry.

Figure 3-1. The Registry Editor lets you view and change the contents of the Registry.

Each branch (denoted by a folder icon in the Registry Editor) is called a key. Each key can contain other keys, as well as values. Values contain the actual information stored in the Registry, and keys are used only to organize the values. Keys are shown only in the left pane; values are shown only in the right pane (unlike Explorer, where folders are shown in both panes).

To display the contents of a key (folder), just click the desired key name on the left, and the values contained therein will be listed on the right side. To expand a certain branch to show its subkeys, click on the plus sign [+] to the left of any folder or double-click on the folder name.

Editing the Registry generally involves navigating down through branches to a particular key and then modifying an existing value or creating a new key or value. You can modify the contents of any value by double-clicking it.

To add a new key or value, select New from the Edit menu, select what you want to add, and then type a name. You can rename any existing value and almost any key with the same method used to rename files in Explorer: right-click on an object and click Rename, click on it twice (slowly), or just highlight it and press the F2 key. Lastly, you can delete a key or value by clicking on it and pressing the Del key or by right-clicking on it and selecting Delete. Note, however, that you can't drag-drop keys or values as you can with files in Explorer.^[1]

^[1] There is very little reason to drag a key or value from one place to another in the Registry, as the settings are highly location-dependent. A value in one key may have a different meaning than the same value in a different key. The exception is when you want to duplicate a key and all its contents (such as a file type key). See the discussion of Registry patches, later in this chapter, and the discussion of file types in Chapter 4, for more information.

You can search for text in key and value names as the contents of values by selecting Find from the Edit menu. See Section 3.2.3, later in this chapter, for tips on using this deceptively simple function. Lastly, select Refresh from the View menu to refresh the displayed portion of the Registry, in case another running application has changed, added, or removed a key or value since the Registry Editor last read the data.

Similar to Explorer, though, is the notion of a path . A Registry path is a location in the Registry described by the series of nested keys in which a setting is located. For example, if a particular value is in the Microsoft key under SOFTWARE, which is under HKEY_LOCAL_MACHINE, the Registry path would be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft. Elsewhere in this book, when a setting is changed in the Registry, this type of Registry path is always provided. If you find that you're viewing the same Registry path often, you can use the Favorites menu to bookmark the item, allowing you to return to it easily (similarly to the operation of the Favorites menu in Internet Explorer).

3.1.1 The Structure of the Registry

There are five primary, or "root," branches, each containing a specific portion of the information stored in the Registry. These root keys can't be deleted, renamed, or moved, because they are the basis for the organization of the Registry. They are:

HKEY_CLASSES_ROOT

This branch contains the information that comprises your Windows file types. See the discussion of file types in Chapter 4 for details on the structure of most of the entries in this branch. A few special keys here, such as CLSID (short for Class ID), contain "registered" components of Windows and your installed applications. The contents of HKEY_CLASSES_ROOT are generally easy to edit, but it's best not to mess with anything in the CLSID branch, because almost none of it is in plain English.

This entire branch is a symbolic link,^[2] or "mirror," of HKEY_LOCAL_MACHINE\SOFTWARE\Classes, but is displayed separately in this branch for clarity and easy access.

^[2] A symbolic link is different from a Windows shortcut you'd find on your hard disk. Information in a linked branch appears twice and can be accessed at two different locations, even though it's stored only once. This means that Find may stop in both places if they contain something you're looking for and, as you might expect, changes in one place will be immediately reflected in the mirrored location.

HKEY_USERS

This branch contains a sub-branch for the currently logged-in user, the name of which is a long string of numbers, and will look something like this:

S-1-5-21-1727987266-1036259444-725315541-500

This number is the SID (security identifier), a unique ID for each user on your system. See Chapter 8, for more information on SIDs.

While it may sound like a good idea to edit the contents of this branch, you should instead use the HKEY_CURRENT_USER branch described later, which is a symbolic link, or "mirror," of this branch. No matter which user is logged in, HKEY_CURRENT_USER will point to the appropriate portion of HKEY_USERS.

Because Windows only loads the profile (this portion of the Registry) of the currently logged-in user, only one user branch will ever be shown here. However, there will be a few other branches here, such as .default (used as a template when creating new user accounts), and a few other branches that will of little interest to most users.

HKEY_CURRENT_USER

This branch simply points to a portion of HKEY_USERS, signifying the currently logged-in user. This way, any application can read and write settings for the current user without having to know which user is currently logged on.

In each user's branch are the settings for that user, such as Control Panel settings and Explorer preferences. Most applications store user-specific information here as well, such as toolbars, high scores for games, and other personal settings.

The settings for the current user are divided into several categories; among them are AppEvents, Control Panel, Identities, RemoteAccess, Software, and System. The most useful of these branches, Software, contains a branch for almost every application installed on your computer, arranged by manufacturer. Here and in HKEY_LOCAL_MACHINE\SOFTWARE (discussed later) can be found all of your application settings. As though Windows was just another application on your system, you'll find most user-specific Windows settings in HKEY_CURRENT_USER\Software\Microsoft\Windows.

HKEY_LOCAL_MACHINE

This branch contains information about all of the hardware and software installed on your computer that isn't specific to the currently logged-in user. The settings in this branch are the same for all users on your system.

The sub-branch of most interest here is the SOFTWARE branch, which contains all of the information specific to the applications installed on your computer. Both this branch and the aforementioned HKEY_CURRENT_USER\Software branch are used to store application-specific information. Those settings that are specific to each user (even if your computer has only one user), such as toolbar configurations, are stored in the HKEY_CURRENT_USER branch; those settings that are not user-independent, such as installation folders, are stored in the HKEY_LOCAL_MACHINE branch. You'll want to look in both places if you're trying to find a particular application setting, because most manufacturers (even Microsoft) aren't especially careful about which branch is used for any given setting.

HKEY_CURRENT_CONFIG

This branch typically contains a small amount of information, most of which are simply symbolic links, or "mirrors," of other keys in the Registry. There's little reason to mess with this branch.

3.1.2 The Meat of the Registry: Values

Values are where Registry data is actually stored (keys are simply used to organize values). The Registry contains several types of values, each appropriate to the type of data they are intended to hold. There are seven types of values that are displayed in the Registry Editor, each of which is known by two different names (see Table 3-1).^[3] Each type is known by at least two different names, the common name and the symbolic name (shown in parentheses).

^[3] Another type of value, known as REG_LINK, is invisible in the Registry Editor. It facilitates symbolic links; the HKEY_CURRENT_USER branch, discussed earlier in this chapter, is an example.

 

Table 3-1. Value types visible in the Registry Editor

Value type	Icon usedin RegEdit	Can be createdin RegEdit?
String (REG_SZ)		Yes
Multi-String[4] (REG_MULTI_SZ)		Yes
Expandable String (REG_EXPAND_SZ)		Yes
Binary (REG_BINARY)		Yes
DWORD (REG_DWORD)		Yes
DWORD (REG_DWORD_BIGENDIAN)		No
Resource List (REG_RESOURCE_LIST, REG_RESOURCE_REQUIREMENTS_LIST, or FULL_RESOURCE_DESCRIPTOR)		No

 

^[4] Multi-String values are also sometimes called String Array values.

Although the Registry Editor allows you to view and edit all seven types of values, it only allows you to create the five most common (and not surprisingly, most useful) types.^[5] Although each of these value types is explained below, they'll make more sense when discussed in the context of the solutions throughout the rest of this book.

^[5] In previous versions of Windows, the Registry Editor only allowed you to create String, Binary, and DWORD values. The ability to create Multi-String and Expandable String values is new in Windows XP. Note that you'll find little reason to ever create the other two available types shown in Table 3-1.

String values

String values contain strings of characters, more commonly known as plain text. Most values of interest to us will end up being string values; they're the easiest to edit and are usually in plain English.^[6] In addition to standard strings, there are two far less common string variants, used for special purposes:

^[6] Although Windows is available in a wide variety of localized languages, most of the internal Registry data will still be in English, primarily because Microsoft is located in the United States, but also because the programming languages used to write Windows components and applications are all based on American English.

String array value

Contains several strings, concatenated (glued) together and separated by null characters. Although Registry Editor now lets you create these values, it's impossible to type null characters (character #0 in the ASCII character set) from the keyboard. The only way to place a null character into a Registry value is either programmatically or via cut-&-paste from another application.

Expanded string value

Contains special variables, into which Windows substitutes information before delivering to the owning application. For example, an expanded string value intended to point to a sound file may contain %SystemRoot%\Media\doh.wav. When Windows reads this value from the Registry, it substitutes the full Windows path for the variable, %SystemRoot%; the resulting data then becomes (depending on where Windows is installed) c:\Windows\Media\doh.wav. This way, the value data is correct regardless of the location of the Windows folder.

Binary values

Similarly to string values, binary values hold strings of characters. The difference is the way the data is entered. Instead of a standard text box, binary data is entered with hexadecimal codes in an interface commonly known as a hex editor.^[7] Each individual character is specified by a two-digit number in base-16 (e.g., 6E is 110 in good-ol' base 10), which allows characters not found on the keyboard to be entered. See Figure 3-2 for an example. Note that you can type hex codes to the left or normal ASCII characters on the right, depending on where you click with the mouse.

^[7] See Section 4.2.2 for an example of how a hex editor is used.

The contents of binary values often don't appear in plain English, making understanding their use, not to mention modifying them, that much more difficult. Note also the various Resource List value types (see Table 3-1), which are just special cases of binary values; you'll find very little reason to ever mess with these.

DWORD values

Essentially, a DWORD is a number. Often, the contents of a DWORD value are easily understood, such as 0 for no and 1 for yes, or 60 for the number of seconds in some timeout setting. A DWORD value would be used where only numerical digits are allowed, whereas string and binary values allow anything.

In the DWORD value editor, you can change the base of the number displayed. For values of 9 or smaller, this option won't make any difference. For 10 and larger, however, the wrong selection will result in the wrong value being entered. In most cases, you'll want to select Decimal (even though it's not the default), since decimal notation is what we use for ordinary counting numbers. Note that if there's already a number in the Value data field, it will be instantly converted when you switch the Base, which is a good way to illustrate the difference between the two.

In some circumstances, the particular number entered into a DWORD value is actually made up of several components, called bytes. This way, several values can be represented by a single number. While this notation is often convenient for programmers, it's decidedly inconvenient for lowly users fishing around in the Registry. The REG_DWORD_BIGENDIAN type is a variant of the DWORD type, wherein said bytes are simply represented in the opposite order.

Figure 3-2. Binary values are entered differently from the common string values, but the contents are sometimes nearly as readable.

 

You can create a value (or key) anywhere in the Registry and by any name and type that suits your whim. However, unless Windows or an application is specifically designed to look for the value, it will be ignored, and your addition will have absolutely no effect.

 

Most Registry editing involves modifying existing values, as opposed to creating new ones. This often makes things easier, as the existing value and its contents can be used as an example.

The application that creates each value in the Registry solely determines the particular type and purpose of the value. In other words, no strict rules limit which types are used in which circumstances or how values are named. A programmer may choose to store, say, the high scores for some game in a binary value called High Scores or in a string value called Lard Lad Donuts.

An important thing to notice at this point is the string value named (default) that appears at the top of every key. The default value cannot be removed or renamed, although its contents can be changed; an empty default value is signified by value not set.^[8] The (default) value doesn't necessarily have any special meaning that would differentiate it from any other value, apart from what might have been assigned by the programmer of the particular application that created the key.

^[8] In the more simplistic Registry found in Windows 3.1 and Windows NT 3.x, each key had only one value. Starting in Windows 95, keys could contain any number of values; the default value simply took the place of the lone value from previous versions, allowing compatibility with older applications that were written before the change took effect. In fact, many things you'll find in the Registry are designed with Legacy support in mind.

3.1.3 Hives Are for the Bees

HKEY_USERS and HKEY_LOCAL_MACHINE are, essentially, the only true root keys, because the Registry's three other root keys are simply symbolic links, or "mirrors," of different portions of the first two (see Section 3.1.1, earlier in this chapter). This means that only these two branches actually need to be physically stored on your hard disk.

Since the files in which the Registry is stored are never edited directly, you're likely to never need to know what they're called or where they're located. In fact, they can't even be copied while Windows is running, so you won't even be able to back them up directly. However, sooner or later, you'll run into them, so the following is a list of all of the files, called hives, in which the Registry is physically stored on your hard disk.

HKEY_USERS\ {SID of current user}

This key, which is the same as HKEY_CURRENT_USER, is stored a file named NTUSER.DAT, located in the user's home directory, which is usually \Documents and Settings\{username}. See Chapter 8 for more information on user accounts and the SID.

You may notice a copy of NTUSER.DAT in \Documents and Settings\Default User. However, this is not the template used for creating new users as you might expect. Instead, this is merely a remnant of the installation process, and does not appear to be used by Windows XP. When a new user account is created, the user hive is built using the data in HKEY_USERS\.Default.

HKEY_LOCAL_MACHINE

Each subkey of HKEY_LOCAL_MACHINE is stored in its own file in the folder, \Windows\System32\Config. For example, the contents of HKEY_LOCAL_MACHINE\Software is stored in the file, software (no extension). The only exception to this is HKEY_LOCAL_MACHINE\Hardware, which is a dynamically-generated branch, and therefore not stored on the hard disk at all.

3.1.4 Backing Up the Registry

As described in the previous section, "Hives are for the Bees," the files in which the Registry is physically stored on your hard disk cannot be accessed while Windows is running. This means that there is no direct way to back up or restore your entire Registry simply by copying files (as is possible in some earlier versions of Windows). There are, however, several ways to achieve an effective Registry backup.

Use Registry-enabled backup software

The most painless way to back up your entire Registry is to do so while backing up the rest of your system. Any decent backup software designed for Windows XP, including the Backup utility that comes with it, will be able to include the Registry in the backup. See Chapter 6 for more information.

Make Registry patches

Registry patches are the quick and easy way to store small portions of your Registry, useful for transferring Registry data to other computers or simply backing up a key before you mess with it. This is similar, at least conceptually, to a local anesthetic. See Section 3.2.1 later in this chapter for details.

Go behind Windows' back

The only time when you are permitted to copy or overwrite the hive files is when Windows isn't running. If you have a dual-boot system or wish to use the Emergency Recovery Console (both described in Chapter 10), you'll be able to read and modify the hive files.

The only exception to this is the NTUSER.DAT file (described in the previous section) for users other than the one currently logged on. Say, you have three users: Katie, Cat, and Sara. If Cat is currently logged in, the NTUSER.DAT files in both \Documents and Settings\Katie and \Documents and Settings\Sara will be ripe for the plucking.

The implications of this can be interesting. For example, you can back up or replace your own NTUSER.DAT hive simply by logging out and then logging in as another user (as long as that user has administrative privileges). You can also copy one user's settings to another user's account simply by duplicating the user's hive file, which is a quick and easy way to set the default profiles for a large number of user accounts. See Chapter 8 for more information on the administration of user accounts. Note that if you delete a user's hive, it will be reconstructed from data in HKEY_USERS\.Default the next time the user logs in.

Any way you do it, taking a few minutes to make sure you have a good backup of your Registry data now will save you hours of headaches later. See Chapter 6 for more information on backups and Chapter 10 for more information on the Emergency Recovery Console, which can be used to restore a corrupted Registry.