Section 8.3. Organization of the Registry

8.3. Organization of the Registry

The Registry is enormous and complex; a full Registry might easily contain 15,000 keys and 35,000 values. Entire books have been written about it, and we can't do it justice here. Our purpose in this section is to arm you with a basic understanding of how the Registry is organized, not to document individual values in detail or suggest changes you might want to make with Registry Editor.

David A. Karp's book Windows Me Annoyances provides many tips and tricks that rely on the Registry. If you can still find Ron Petrusha's out-of-print book, Inside the Windows 95 Registry , you'll find lots of useful information there. While aimed primarily at software developers and covering Windows 95, it contains several chapters aimed at experienced users. In particular, see Chapters Chapter 1 to Chapter 3, which give a good overview of the Registry and a detailed description of how to use Registry Editor. Also see Chapter 8.

The top level of the Registry is organized into five main root branches. By convention, the built-in top-level keys are always shown in all caps, even though the keys in the Registry are not case-sensitive. (For example, HKEY_CURRENT_USER\SOFTWARE\MICROSOFT\Windows is identical to HKEY_CURRENT_USER\Software\Microsoft\Windows .) Their purposes and contents are listed in the following summaries. Note that the root keys are sometimes abbreviated for convenience in documentation (although never in practice); these abbreviations are shown in parentheses. Subsequent sections go into the contents of the root keys in more detail.

HKEY_CLASSES_ROOT (HKCR)

Contains file types, filename extensions, URL protocol prefixes, and registered classes. The information in this branch can be thought of as the "glue" that binds Windows with the applications and documents that run on it. It is critical to drag-and-drop operations, context menus , double-clicking, and many other familiar user interface semantics. The actions defined here tell Windows how to react to every file type available on the system.

This entire branch is a mirror (or symbolic link) of HKEY_LOCAL_MACHINE\SOFTWARE\Classes , provided as a root key purely for convenience.

HKEY_CURRENT_USER (HKCU)

Contains user-specific settings for the currently logged-in user. This entire branch is a mirror (or symbolic link) of one of the subkeys HKEY_USERS (see below). This allows Windows and all applications to access and store information for the current user without having to determine which user is currently logged in.

An application that keeps information on a per-user basis should store its data in HKEY_CURRENT_USER\Software , and put information that applies to all users of the application in HKEY_LOCAL_MACHINE\SOFTWARE . However, it is somewhat arbitrary what Windows applications seem to consider user-specific and what is for all users on the machine. Like many aspects of Windows, the Registry provides a mechanism for applications to store configuration data, but does little to enforce any policies about how and where it will actually be stored.

HKEY_LOCAL_MACHINE (HKLM)

Contains information about hardware and software on the machine not specific to the current user.

HKEY_USERS (HKU)

Stores underlying user data from which HKEY_CURRENT_USER is drawn. Although several keys will often appear here, only one of them will ever be the active branch. See the discussion of HKEY_USERS , below, for details.

HKEY_CURRENT_CONFIG (HKCC)

Contains hardware configuration settings for the currently loaded hardware profile. This branch works similarly to HKEY_CURRENT_USER , in that it is merely a mirror (or symbolic link) of another key. In this case, the source is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\XXXX , in which XXXX is a key representing the numeric value of the hardware profile currently in use. On a system with only a single hardware profile, its value will most likely be 0001 .

8.3.1. HKEY_CLASSES_ROOT (HKCR)

At first glance, Windows XP seems very object-oriented. Files, folders, and devices are represented by icons that respond differently to various actions such as single or double-clicks, right-clicks, and left-clicks. But in a true object-oriented system, the object itself contains the knowledge of how to respond to events such as mouse clicks.

By contrast, Windows XP performs much like the Wizard of Oz, not with true object-oriented magic, but with a complex machinery hidden behind a screen. The knowledge of how the Explorer should treat each object is stored in the Registry in a complex chain of interrelated keys.

Much of the system's behavior depends on filename extensions. A filename extension , the string of letters that appear after the last dot in a filename, is the primary mechanism Windows uses to determine a file's type. Therefore it's essential that each filename extension accurately reflect the file type. For example, a file named stuff.txt will be treated by Windows as a text file. If one were to rename the file to stuff.old , it would still be a text file, but Windows would treat it differently: it would have a different icon in Explorer, a different description in Explorer's Details view, and a different action when double-clicked. (The exceptions are certain Microsoft Office documents, which are handled by Windows in a consistent manner regardless of the filename extension.) This illustrates how fragile and fallible Windows' file types system is, how some applications can so easily register themselves as the default for any given file type, and how stupid it is that filename extensions are hidden in Explorer by default.

When you open HKEY_CLASSES_ROOT , the first thing you'll see is a very long list of file extensions known to the system, from something like .ai (Adobe Illustrator Document) to .zip (Zip archive). What follows is a list of document type keys , which typically contain the actual file type information. These two sets of keys make up the file types in Windows XP.

Here's how it works: a file extension key (one which has a dot at the beginning of its name) has its default value set to the name of a document type key (and thus "points" to that key). For example, HKEY_CLASSES_ROOT\.txt , which corresponds to all files with the .txt extension, has its default value set to txtfile . Lower down, the HKEY_CLASSES_ROOT\txtfile key contains several keys that describe files of this type, and instruct Windows how to handle double-clicks, right-clicks, and other operations.

You also may notice that HKEY_CLASSES_ROOT\.log key also has its default value set to txtfile ; in this way, many extension keys can point to a single file type key, and hence, a single file type can encompass several different filename extensions.

Applications frequently add new file types to the Registry, registering themselves with certain filename extensions. In the case of the txtfile file type, Notepad is registered as the default application when Windows XP is first installed; thus, when one double-clicks on a .txt file or a .log file, the file is opened in Notepad.

A common conflict occurs when two or more applications find themselves fighting to be the default application. For example, should a file with the . htm extension be opened by Netscape Navigator or Microsoft Internet Explorer? If you use Navigator, the .htm key might have the value name (Default) with the data NetscapeMarkup . If you use Internet Explorer, the value name (Default) will have the value data htmlfile . If you then look at either of those two class definition keys ( NetscapeMarkup or htmlfile ), you'll see a different chain of subkeys. While both Navigator and Internet Explorer know how to handle HTML files, they use a different set of internal instructions for figuring out how to display or edit the files, which icon to display for the file, and so on.

The detailed subkeys and values that appear under the class definition and document type keys start to get really confusing. (See Windows Me Annoyances for an in-depth examination of file types.)

Because each program may record and retrieve different keys, it's very hard to generalize about them. The best we can do is mention some of the kinds of keys you might see associated with a particular file extension subkey or class definition subkey . Here are some of the most common keys and values you may find in HKEY_CLASSES_ROOT , sorted alphabetically :

CLSID

Class identifier for an ActiveX component, a unique, 16-bit 16-byte number in the following format: {aaaaaaaa-bbbb-cccc-dddd-ffffffffffff} , in which each letter represents a hexadecimal digit. (That's a sequence of eight, four, four, four, and twelve hex digits, with a hyphen between each group of digits and the whole thing enclosed in curly braces.)

CLSID appears both as a subkey of many file type definition keys and as a class definition key in its own right. That is, the key HKCR\NetscapeMarkup might have a subkey CLSID with the data value {61D8DE20-CA9A-11CE-9EA5-0080C82BE3B6} , but there's also a key called HKCR\CLSID with the subkey {61D8DE20-CA9A-11CE-9EA5-0080C82BE3B6} , which in turn has the data value Netscape Hypertext Document . The first entry is simply a pointer to the second, which contains the actual class data. You must always be on the lookout for this kind of indirection.

CLSID keys don't necessarily correspond to filename extensions or file types. The HKEY_CLASSES_ROOT\CLSID branch, for example, contains a huge list of class ID keys, which each represent a different component. Most of the components are of little interest to mere mortals , but some correspond to visual elements in Windows XP. If you search for "Recycle Bin" here, for example, you'll find the key that describes the Recycle Bin Desktop icon. Try changing the contents of the Default value to "Trash," refresh your Desktop, and see what happens!

Content Type

The data in this value is the Multipurpose Internet Mail Extension (MIME) descriptor for the corresponding file type. This key will typically appear in the file type key for Internet- related file types such as GIF and JPEG. It's used by email programs that support attachments and web browsers, such as Netscape Navigator and Internet Explorer, to help them identify downloaded files.

DefaultIcon

The location (usually a pathname and an optional "icon index" within the file) of the file containing the default icon to use for a file type or CLSID. If you see the value data " %1 ", it means that the file will act as its own icon (a neat effect when used with BMP files).

Note that there may be more than one default icon for a given file type. A good example is the Recycle Bin, which shows a different icon when it is empty and when it is full. In cases like this, the program knows to copy its icon for the appropriate state to the DefaultIcon (Default) value. In other cases, though, a DefaultIcon may be specified in more than one place (e.g., under a document type key and under an associated CLSID key).

Shell

Contains subkeys that define actions (open, edit, print, play, and so forth) appropriate to the object. These actions appear on the context menu for the associated file type, among other things. The easiest way to edit these actions is with the File Types dialog in Explorer (Tools Folder Options File Types), but you sacrifice a pretty interface for increased flexibility.

A common structure that uses the Shell key is Shell\Open\Command , where the default value in the Command key is the executable filename for a registered application. The command line often ends with " %1 " (including the quotes), which represents a command-line parameter passed to the application (familiar to those who use batch files). For example, when you double-click on a .txt file (say, c:\stuff \junk.txt ), Windows replaces " %1 " in the command line with the name of the file, resulting in the following command being run: notepad c:\stuff\junk.txt . If you were to select Run from the Start menu, and type that command, Notepad would appear and open the file. Note that the quotes around the %1 accommodate any spaces in the filename; otherwise , Windows would interpret a single filename with a space as two distinct filenames, and you'd get an error.

You might also find the key, Shell\Open\ddeexec , which contains information necessary for a DDE (Dynamic Data Exchange) conversation. DDE is the mechanism with which Windows communicates with applications that are already open. For example, Windows might send a DDE message to an application to tell it to print a file after opening it. Microsoft insists that DDE is obsolete, but you'd never know it from the important role DDE plays in Windows file types.

You'll see the same split between command-line options and DDE using the Explorer interface to file associations, via Tools Folder Options File Types. Some actions will list a command line; others will use DDE. If you're not a programmer with access to the DDE documentation for a particular application, you may find this difficult to follow at times.

You may find that a particular Shell branch doesn't contain all the actions for a particular file type. This is because these items may be specified in three other places. First, the ShellEx key contains more advanced actions. Second, the HKEY_CLASSES_ROOT\* key contains additional actions that apply to all file types.Third, some actions available to all files, such as the Delete and Properties actions, can't be removed, and therefore don't appear in this key.

ShellEx

This is short for Shell Extensions. These keys contain entries that supplement a file's context menu (via the ContextMenuHandlers subkey), a file's Properties sheet (via the PropertySheetHandlers subkey), and a file's drag-drop behavior (via the CopyHookHandlers subkey). These extra features are too complex to be simple Shell\Command structures; instead, these keys simply point to registered CLSIDs (described earlier) and special programs that perform advanced features. For example, if you install the WinZip utility (http://www.winzip.com), all ZIP files will have extra items in their context menus (click with the right mouse button) and their drag-drop menus (drag with the right mouse button) that handle certain ZIP operations. Also, movie files ( .avi , .asf , and .mpg ) and Word Documents ( .doc ) all have an extra Summary tab in their Properties sheets that displays additional information about the contents of the file.

ShellNew

Defines whether the file type will appear on Explorer's New menu. If the ShellNew key is present inside a file type or file extension key, the file type will appear in the list when you select New from Explorer's File menu. In most cases, this key will be empty, if it exists at all. (Contrast the enormous number of file types defined in the Registry with the much smaller number that appear on the New menu.)

Command

Contains a command line to create the new file, used only for Briefcases and Windows Shortcuts (the .bfc and . lnk extensions, respectively), as well as any other file type that can't be created merely by copying a template (see next ).

Filename

Contains the name of a file "template" to copy to the new location. Its value data may contain a complete pathname, but if it's just a filename (e.g., netscape.html , winword.doc , or winword8.doc ), it will be found in the directory \Windows\ShellNew . If the Filename value is not present, Windows will create an empty, zero-byte file.

Nullfile

If present, instructs Windows not to create the file at all, but instead to launch a program that will create the file when first saved. Some file types (such as .bmp files, which may contain data in any one of a number of related formats, as specified by binary header data within the file itself) are described by the NullFile value. NullFile has the empty string ("") as its value data.

Data

Contains binary data that needs to be written to the new file. This might, for example, be some kind of binary header data.

Before leaving HKEY_CLASSES_ROOT , two other keys are worthy of note.

HKCR\* contains information that will be applied to all files, regardless of their extension.

HKCR\Unknown describes, via its Shell\OpenAs\Command subkey, what will happen to a file whose type is unknown, either because the file has no extension, or because the particular extension has not yet been registered with Windows. By default, if you double-click on a file Windows categorizes as unknown, the Open With dialog appears, allowing you to choose a new association for the filename extension, thereby automatically creating new file type keys in the Registry box. Here you find the rundll32 command line to bring up that dialog box. runndll32 is merely a program that allows a particular function in a .dll or .exe file to be run via a command-line interface.

8.3.2. HKEY_CURRENT_USER (HKCU)

The Registry separates settings specific to individual users from global Windows settings applicable to all users. In the FreeCell example earlier in this chapter, each user of the machine can have his or her own separate won/lost statistics because the program keeps these statistics in the HKEY_CURRENT_USER branch of the Registry. If it instead used HKEY_LOCAL_MACHINE , all users would share the same statistics.

This entire branch is a mirror (or symbolic link) of HKEY_USERS\ .DEFAULT ( see below ) , and its contents always correspond to those of the currently logged-in user.

By default, there are twelve top-level subkeys in HKCU: AppEvents, Console, Control Panel, Environment, Identities, Keyboard Layout, Printers, RemoteAccess, SessionInformation, Software, UNICODE Program Groups, and Volatile Environment.

HKCU\AppEvents

The associations between events and system sounds are kept here. (See "Sounds".) There are two branches: EventLabels and Schemes. EventLabels contains the labels that will be used for the sounds; Schemes contains the pointers to the actual sounds.

Schemes has two main subkeys: Apps and Names .

Applications that use sounds can create their own subkey under Schemes\Apps , or they can add sounds into the default list, which is kept in the subkey Apps\.Default . If they add their own subkey, the sounds will show up in a separate section of the sounds list in Control Panel Sounds. So you might see a subkey such as Mplayer or Office97, since these applications add some of their own sound events in addition to the default sounds. Note that unless Windows or an application is specifically designed to look for an event listed here, any new events you might add will have no effect.

Schemes\Names is where Windows stores the settings for each of the sound schemes, such as Utopia. When you change the sound scheme using the drop-down Scheme list on Control Panel Sounds, the appropriate scheme is copied into .Default .

HKCU\ControlPanel

Data from several of the Control Panel applets is stored here, particularly Accessibility and some of the Display settings. The names don't match up cleanly to the names used in the Control Panel, but you can usually figure out what's what by going back and forth between Registry Editor and the target Control Panel applet. For example, HKCU\ControlPanel\Accessibility maps directly to Control Panel Accessibility, but HKCU\ControlPanel\Cursors maps to Control Panel Mouse Pointers.

As is typical in the convoluted world of the Registry, some entries point somewhere else entirely. For example, HKCU\ControlPanel\International simply defines a Locale value, such as 00000409 , which is the standard code for what the Control Panel calls "English (United States)." If you use Registry Editor's Find function to trace this value, you'll eventually find the scattered locations of many of the individual values that Control Panel Regional Settings brings together in one place.

This example illustrates a key point: there's usually little reason to poke around in the Registry for values that have a convenient user interface in the application. The exception is where the interface has limited which values can be entered, making the Registry a tool you can use for greater control (at the expense of the convenience of a user interface), as well as where there is simply no interface for some of the more obscure settings.

HKCU\Environment

The environment is a small chunk of memory devoted to storing a few system-wide settings, primarily for use with older Windows and DOS applications, but still used by Windows XP. In Windows 9x and Windows Me, information was added to the environment via the AUTOEXEC.BAT file (now obsolete). Like Windows 2000, Environment variables in Windows XP are set via Control Panel System Advanced Environment Variables. The upper section of this dialog box (user variables for username ) is where user-specific variables are entered, and are thus stored in the HKCU\Environment Registry key. The lower box (system variables) is for system-wide, user-independent variables and is stored in HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Environment . Note also the HKCU\Volatile Environment key, which contains temporary environment variables, resets each time Windows is started.

HKCU\keyboard layout

This key is used only if you have installed more than one keyboard layout via Control Panel Keyboard Language. A Preload subkey lists a separate subkey for each installed language, with subkey 1 specifying the default language.

HKCU\RemoteAccess

This key lists various types of information used by Dial-Up Networking, including the default connection to be used by Internet applications. The Implicit subkey lists the UNC path of any shared folders or printers that are accessed over a particular Dial-Up Networking connection. The Profile subkey stores information specific to each connection, such as the saved login name that will be supplied automatically when you make the connection.

HKCU\Software

Probably the most useful key in HKEY_CURRENT_USER , this key contains subkeys for each vendor whose software is loaded onto the machine, and, within each vendor's area, subkeys for each product. The keys stored here are supposed to contain only user-specific settings for each software application. Other settings, which are common to all users of software on the machine, are stored in HKLM\SOFTWARE .

The structure of this branch (and particularly of the Microsoft\Windows\CurrentVersion branch under both) is described later in this chapter, in Section 8.3.4.

8.3.3. HKEY_LOCAL_MACHINE (HKLM)

HKLM contains hardware settings and global software settings that apply to all users. It has five top-level subkeys: HARDWARE, SAM, SECURITY, SOFTWARE, and SYSTEM. Each of these keys is stored in a separate hive file (see Section 8.4, later in this chapter).

HKLM\HARDWARE

The data stored in this branch is used by Windows XP to load drivers and initialize resources for the various hardware components of your computer. All of the settings here are more easily accessible through Device Manager (Control Panel System Hardware Device Manager); there's little need to edit them directly. However, you may find it interesting to snoop around in this branch and see the various pieces of information that are stored for your CD Writer, your scanner, your hard disk, and your processor. The HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0 key tells me that my CPU is "GenuineIntel." I hope the thought police aren't checking this key.

HKLM\SAM

This key stores data for the Security Accounts Manager (SAM), used only if your Windows XP system is providing domain services. You'll find little reason to ever mess with the settings in this branch, and as most of the data is in binary format, you'll have a hard time deciphering it anyway. The information stored in this key is managed primarily through the User Manager for Domains (on NT Server) and User Manager (on NT Workstation). All of the settings here can be accessed through the Local Security Policy Editor ( secpol.msc ).

HKLM\SECURITY

The Security branch is where Windows stores the local security policy, which includes user accounts, permissions, passwords, and group membership information. Like HKLM\SAM , there is little reason to mess with this key. All of the settings here can be accessed through Control Panel User Accounts.

HKLM\SOFTWARE

Probably the most useful key in HKEY_LOCAL_MACHINE , this key contains subkeys for each vendor whose software is loaded onto the machine, and, within each vendor's area, subkeys for each product. The keys stored here are supposed to contain global system settings for each application, common to all users on the machine. Other settings, specific to each user, are stored in HKCU\SOFTWARE .

The structure of this branch (and particularly of the Microsoft\Windows\CurrentVersion branch under both) is described later in this chapter, in Section 8.3.4.

HKLM\SYSTEM

The settings in this branch primarily handle multiple hardware profiles. Windows uses this data together with HKLM\HARDWARE to handle drivers and Plug-&-Play management for all hardware on the system. All of the settings stored in this branch are accessible via Control Panel System Hardware Hardware Profiles.

8.3.4. HKCU\Software and HKLM\SOFTWARE

As noted earlier, both HKEY_CURRENT_USER \ Software and HKEY_LOCAL_MACHINE\SOFTWARE are structured similarly. Each of these areas has a branch for each manufacturer who has software installed on the system, and most vendors will have keys that appear in both areas. In each manufacturer key, there will be one or more subkeys, corresponding to each of that manufacturer's applications that are installed. For example, under the Adobe key, you might see an entry for Photoshop and one for Illustrator, assuming both of those applications are installed on your system.

In theory, the HKCU branch should include information that is configurable on a per-user basis (which is the case, for instance, with a software package with a per-user license or per-user customization). The HKLM branch should include software that is standard for all users. In practice, though, it doesn't seem to be as consistent as that. Some data might seem to be placed in wrong branch, while other data might be placed in both branches. Fortunately, this doesn't pose much of a problem in practice, partly because the vast majority of systems will only have a single user account, but more importantly, because the only practical rule as to the location and organization of data in the Registry is that it is consistent with the application that uses it. For example, since WordPerfect knows where to look for its own settings, it doesn't really matter that they aren't in a place the casual user would expect. Basically, if you're looking for something, look in both branches (HKLM and HKCU).

Because this is a book about Windows XP and not about the third-party applications that might be installed in it, the primary focus of this discussion is on the Microsoft\Windows\CurrentVersion branch, located in both HKCU and HKLM. There is a ton of information in these two areas, and the following keys represent the more useful and intelligible data:

..\Microsoft\Windows\CurrentVersion

This key contains a dozen -or-so values describing some basic Windows settings, such as the folder location for Program Files, and the 20-digit Product ID number. Note the use of REG_EXPAND_SZ values, described earlier in this chapter.

..\Microsoft\Windows\CurrentVersion\App Paths (HKLM only)

This branch lists a path for many application executables (Microsoft and otherwise) that are installed in nonstandard locations (i.e., not in \ , \Windows , or \Windows\Command ). It is the reason why you can successfully type a command name like excel or winword at the Run prompt, but not at the Command prompt, unless you add \Program Files\Microsoft Office\Office to your search path. They have listed their path individually under this key.

If you have an application that installs a shortcut on the Start menu, but doesn't let you type its name at the Run prompt, add a key for it in the App Paths key (using an existing entry as a template). For example, I added a PHOTOSHOP.EXE key, with the values:

 (Default)   "C:\Program Files\Adobe Photoshop\Photoshop.exe" Path   "C:\Program Files\Adobe Photoshop" 

The end result is something like the Path environment variable, except that the target is a specific executable rather than an entire folder.

..\Microsoft\Windows\CurrentVersion\Explorer\ShellFolders

..\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Specifies the locations of many of the standard Windows system folders, including Desktop, Programs, Send To, Start Menu, Startup, and Templates.

This branch really brings home the extent of Windows' mutability. Even the directory names that Explorer relies on, such as \Windows\Desktop , are not hard-wired. So Explorer doesn't know anything about c:\Windows\Desktop . All it knows is that it can get the name of the folder it's supposed to use as the Desktop from the Registry. Most of these values probably shouldn't be changed.

The ShellFolders and User Shell Folders keys each exist in the HKCU and HKLM branches. If you're looking for a particular setting, make sure you look in all four keys; whenever a key seems to be duplicated in more than one place, it's good practice to make changes in both places. Note also the use of the REG_EXPAND_SZ data type (explained earlier in this chapter) is used for some of the values.

..\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace

Contains keys named with the CLSID of system icons that appear on the Desktop such as the Recycle Bin, My Documents, and My Network Places. Since these are simply pointers to objects defined elsewhere in the Registry (like Windows Shortcuts), they can be safely deleted (one method of removing the respective icons from your Desktop).

..\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain

Every time you click the "Don't show me this again" option on some warning dialogs, Windows records your choice in this key. If you'd like to restore a warning you've previously dismissed, you can remove the corresponding value here. Too bad you can't add new values here to get rid of all the annoying Windows messages!

..\Microsoft\Windows\CurrentVersion\Explorer\FindExtensions

Contains keys corresponding to the various entries in the Start menu's Search menu and in the Explorer Search Bar. While you can't indiscriminately add items here (unless you're a programmer), you can remove unwanted entries.

..\Microsoft\Windows\CurrentVersion\Explorer\MyComputer

Contains several keys that relate to the My Computer window. The NameSpace subkey, for example, contains keys pointing to CLSIDs of various optional components that might appear in your My Computer window. To identify any unlabeled CLSID that shows up here or anywhere else, copy the entire CLSID string to the clipboard and paste it into Registry Editor's search box.

..\Microsoft\Windows\CurrentVersion\Explorer\StartMenu (HKLM only)

Contains several keys that relate to the seemingly hardcoded entries that appear in the Start Menu My Computer window. The NameSpace subkey, for example, contains keys pointing to CLSIDs of various optional components that might appear in your My Computer window. To identify any unlabeled CLSID that shows up here or anywhere else, copy the entire CLSID string to the clipboard and paste it into Registry Editor's search box.

..\Microsoft\Windows\CurrentVersion\Internet Settings

Contains a whole slew of settings for Internet Explorer and the Internet Options dialog in Control Panel. You'll find settings in this key for just about everything from Passport settings to the filename of the bitmap used for the background of Internet Explorer's toolbar.

..\Microsoft\Windows\CurrentVersion\Run (HKLM only)

..\Microsoft\Windows\CurrentVersion\RunOnce

In these keys, you'll find a list of programs that Windows loads at start up. Note that these aren't the same as those found in the Startup folder in your Start menu, but they work similarly. The format is simple enough: the data in each value contains the full path and filename of a program to be launched, and the name of the value is merely a reminder as to the purpose of the entry. You can safely add any program you like, or remove entries you'd like to stop loading automatically. Note that values placed in either of the RunOnce keys ( HKCU or HKLM ) will only be run the next time Windows starts, and will be deleted immediately thereafter. There are several advantages of these keys over the Startup folder. For example, they're more concealed, and therefore more tamper-resistant. Also, items placed here (HKLM only) are run before the login screen appears, while items in the Startup folder are run only after a user logs in.

In addition to the previous specific keys, there are a few paradigms that show up again and again, such as the following:

../MRU

Stands for Most Recently Used. Any time Windows shows you a "history" of the last few things you've typed into a field, such as the Start menu's Run dialog, those items are stored in an MRU key in the Registry. A quick search for MRU in the Registry Editor will yield dozens of instances.

Knowing the location and use of a particular MRU list has several advantages. For example, you can write a script to clear a given list to erase your "footprints," so to speak. Or, perhaps you could create a Registry patch that would preload the Find drop-down list with a set of long names you wanted to search for repeatedly.

In MRU keys, the value names are a series of letters; there is also a value called MRUList that specifies the order in which the entries should be displayed. That is, if you've just typed in the filenames *.dll and *.exe into the Find dialog box, they might appear as items h and i in the list. But then, if you picked *.dll again from the list, the MRUList would show ijabcdefgh . The list is updated only when you actually execute a find, not when you type in a new filename to search for or pick an item from the drop-down list. In addition, when you quit Find, value j , which always contains an empty string, rotates to the front of the list.

../Namespace

Keys named Namespace usually contain values or subkeys that point to CLSIDs (16-bit identifiers to registered program components), which, in effect, instructs Windows to load those components. For example, if a CLSID for the Recycle Bin is listed under the Desktop\Namespace key, it corresponds to the Recycle Bin object appearing on the Desktop. Sometimes, removing these entries will have the effect of removing the corresponding objects, but not always. I recommend experimentation with some degree of caution.

8.3.5. HKEY_USERS (HKU)

Despit e its name, this branch does not contain the Registry entries for all users configured on the system. This is because user information is loaded when a user logs in, and only one user can be logged in at any given time. Rather, it contains only information for the currently logged-in user as well as a template for new user profiles. (For those of you familiar with this key in Windows 9x and Windows Me, it does not quite work in the same way in Windows XP.)

This branch contains several keys, although only one of them is mirrored as HKEY_CURRENT_USER (discussed above). Usually, it's the one that looks like S-x-x-xx-xxxxxxxxx-xxxxxxxxxx-xxxx , where the long string of x 's is the Windows serial number. If it's not clear which key is the active one, just create a new key or value in one of the branches called test . Then, move up to HKEY_CURRENT_USER , and press F5 to refresh the view. If the test enTRy you just added shows up here as well, you've found the active key; if not, delete test and try again in a different key.

The .DEFAULT key is used as a template for creating new users, and unless you want to affect new user settings, you should leave this key alone. In fact, there's little reason to ever play with the HKEY_USERS branch, as all applicable settings for the active user are more easily accessible through HKEY_CURRENT_USER .

This design prevents one user from easily viewing or changing another user's settings.

8.3.6. HKEY_CURRENT_CONFIG (HKCC)

A s noted earlier, HKCC is mirrored from the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Hardware Profiles\XXXX , in which XXXX is a key representing the numeric value of the hardware profile currently in use. On a system with only a single hardware profile, its value will most likely be 0001 . This branch contains hardware configuration settings for the currently loaded hardware profile, but there's little reason to edit this branch directly. Instead, go to Control Panel System Hardware Hardware Profiles.