The Windows Registry is a centralized hierarchical database used by the Windows operating system to store configuration settings and options for the system, hardware devices, and installed software applications. It serves as a critical component of the Windows ecosystem, facilitating the management and retrieval of essential system and application-related data. Understanding the Windows Registry is essential for system administrators, power users, and developers alike. Here's a complete guide to the Windows Registry:
1. Hierarchical Structure:
- The Registry is organized into a hierarchical structure similar to a file system, consisting of keys, subkeys, and values.
- Keys are like folders that contain subkeys and values.
- Subkeys are nested within keys, allowing for the organization of related configuration data.
- Values are used to store the actual configuration data and can be of different types, such as strings, binary data, integers, or multi-string values.
2. Hives:
- The Registry is divided into several logical sections called "hives," each of which contains specific types of configuration data.
- The main hives are:
- HKEY_CLASSES_ROOT (HKCR)
- HKEY_CURRENT_USER (HKCU)
- HKEY_LOCAL_MACHINE (HKLM)
- HKEY_USERS (HKU)
- HKEY_CURRENT_CONFIG (HKCC)
- Each hive contains keys and subkeys that store configuration settings relevant to that hive's scope.
3. Usage:
- The Windows Registry is used extensively by the Windows operating system and applications to retrieve configuration data during system boot-up, program execution, and runtime operations.
- Configuration settings stored in the Registry include user preferences, system settings, device configurations, application data, and more.
- Applications can access the Registry using the Windows Registry API, which provides functions for reading, writing, and manipulating registry keys and values.
4. Access Control and Security:
- The Registry supports access control mechanisms to regulate which users and applications can read, write, or modify specific registry keys and values.
- Access control lists (ACLs) are used to define permissions for registry keys, ensuring that sensitive configuration data is protected from unauthorized access or modification.
5. Backup and Recovery:
- Windows provides utilities for backing up and restoring the Registry to prevent data loss in case of system failures or corruption.
- Users can manually export specific registry keys or hives to backup files (.reg), which can be imported later to restore the Registry to a previous state.
6. Registry Editor:
- The primary tool for viewing and editing the Registry is the Registry Editor (regedit.exe), a built-in Windows utility.
- Registry Editor allows users to navigate through the registry hierarchy, view and edit registry keys and values, create new keys and values, and perform other registry-related operations.
7. Best Practices and Precautions:
- Users should exercise caution when editing the Registry, as incorrect changes can lead to system instability, application errors, or other undesirable consequences.
- Before making changes to the Registry, it's recommended to create backups and export relevant registry keys to safeguard against data loss or corruption.
8. Advanced Topics:
- Advanced users may explore topics such as registry optimization, registry monitoring, registry scripting, and more to enhance their understanding and utilization of the Windows Registry.
The Windows Registry
Every operating system and application needs a place to store configuration settings and user preferences. As computers have become more complex, so have the methods of storing this data. The few settings needed by MS-DOS were stored in the plain text file CONFIG.SYS. DOS programs had to make their own arrangements for storing user settings.
Windows originally used INI files - text files organised in a simple format that could be read and written using special routines available to Windows programs. Windows had one configuration file, SYSTEM.INI, which was used for all the internal settings plus another, WIN.INI, for user preferences. Each application had an INI file, too, usually named after itself.
This system worked pretty well, and is still used by some Windows programs, but it turned out to have a few disadvantages. INI files were slow to access and limited in size to 64Kb. There was also just one INI file per program per computer, making it difficult to have different settings for each user of a computer.
So for Windows NT and Windows 95 Microsoft introduced the Registry. You can think of the Registry as a database for storing and accessing configuration data. Like all good databases the Registry can store different types of data. It is organised for fast and efficient access. Data is stored in a hierarchical manner rather like the folders on a hard disk. Registry data that is currently in use is cached in memory to provide better performance.
Benefits of the Registry
The Registry offers a number of benefits over other schemes for storing configuration data. All the data is stored in a single logical place, which makes it is easy to back up and restore. (Actually, the Registry consists of two or more separate files, as we shall see later.) The physical location of the Registry is unimportant and transparent to the user: it could either be stored locally or accessed over a network. Storing it on a remote server is useful in a business environment because it allows people to log in using different PCs but still have their own personal user settings.
Backing up and Restoring
Restoring from a backup is the only way to reverse changes made to the Registry that are found to have undesired effects. Therefore the Registry should be backed up before performing any operation that might result in undesirable changes. Strictly speaking this includes things like installing or removing an application, as well as more obvious things like running clean-up tools or having a session with Regedit. It's up to you to decide what risk you're running and what level of precautions are justified.
If you're using Windows 98 or later your Registry is automatically backed up for you. A program called the Windows Registry Checker (SCANREGW.EXE) runs every time at start-up. It checks the Registry and makes a backup of it the first time it is run each day. You can also force a backup at any time by running SCANREGW manually. The backups are stored as cabinet files - a special type of compressed archive used by Microsoft - named RBxxx.CAB in the Windows SYSBCKUP folder. By default, five generations of backups are kept in a rolling sequence. The number of backups that are kept can be changed by editing the file SCANREG.INI in the Windows folder.
To restore from one of these backups you must boot or exit to MS-DOS (in Windows 98) or Safe Mode (Windows Me) and then run the command SCANREG /RESTORE. You will then be presented with a menu from which you can select and restore a backup. Windows NT/2000 users are assumed to be professionals who take regular system backups to tape so they aren't provided with SCANREG or SCANREGW and will have to do their backups and restores the hard way.
If you're confident of your ability not to wreck the entire Registry you can save time by creating a backup of just the branch you're about to change. To do this, select the key whose contents you want to back up in the left-hand pane of the Registry Editor and choose Export Registry File from the Registry menu. Check that “Selected branch” is chosen. Name the file you are about to create and click Save. This will create a copy of the contents of the branch as a REG file.
To restore the contents of a REG file at any time just double-click it. Note that importing a REG file in this way actually merges its contents with the existing Registry. So although it will restore anything you deleted and overwrite any changes you made, it won't remove any keys or values that you added to the Registry after the backup was taken.
A disadvantage of everything being in one place is that it's hard to back up individual program preferences so that they can be transferred to a new computer after the software has been reinstalled. It's not advisable to try restoring an entire Registry to another PC because so much of the information in it is system-dependent.
Although the Registry can be considered to be a nested hierarchy of folders, the term “folder” isn't often used when referring to the location of data. The “path” that identifies a specific Registry “folder” is more correctly called a “key”. However, this term is more appropriate if you're a programmer and understand the way programs access information in the Registry.
To access a particular folder a program opens it, specifying the path and the type of access required (for example read-only, or read/write), and receives a key. This key is a kind of token that is used in subsequent program commands to read or write data values stored in that key and to access sub-keys of it. When a program has finished with its Registry accesses it closes and releases the key. This mechanism helps Registry access to be made efficient. It also allows Windows to implement access controls and prevent one application from changing Registry data while another has it open. (Windows 9x doesn't support these access controls, however, which is one of several subtle differences between the Registries of the two Windows families.)
Another characteristic that the Registry has in common with databases is that it is not editable using a text editor. It is a binary file and can only be read and modified using programs designed specifically to do so. A few people have attempted to make changes to the Registry using tools like Norton DiskEdit (including, famously, columnist and science fiction writer Jerry Pournelle who actually described the attempt in his column in the late lamented Byte magazine manyyears ago) but the result will almost always be disaster. Hackery of this sort should, most emphatically, never be attempted.
Unfortunately, Windows isn't perfect. Things go wrong, and the only way to fix them may be to make manual changes to the Registry. Fortunately, Microsoft has provided a tool specifically designed for the purpose. It is called, surprisingly enough, the Registry Editor. Its filename is REGEDIT.EXE under Windows 9x and REGEDT32.EXE under Windows NT.
The Registry Editor presents a graphical, Explorer-like view of the Registry. It has two window panes. The left-hand pane contains a collapsible tree view of the key hierarchy. When a key is selected in the left hand pane, the right hand pane displays the values it contains and any sub-keys. We shall use the Registry Editor as our principal exploration tool in the course of this article.
A significant failing of the Registry Editor that you should always bear in mind is that it has no “undo” facility to reverse any changes you might make. It is all too easy to accidentally modify or delete something which could have fatal consequences for Windows or an application. So it's always advisable to back up your Registry files before using the editor. See the sidebar Backing up and Restoring for information on how to do this.
Categories of data
The data that is recorded in the Registry falls into two distinct categories: system information and user information. System information is that which relates solely to the computer itself. It includes information about the hardware and peripherals, their drivers and so on. It may also include information related to software that has been installed on the machine.
User information is all the settings that relate to a user of a computer, including their personal preferences. A Windows 98 computer may only have one user, but Windows NT/2000 supports multiple users and insists that you log on to the system to use it. Windows 9x/Me also permits the use of user profiles. Remember, too, the requirement that a user can access their personal settings when logged on using a different computer on a network. To cater for this, system and user information are stored in separate files, and the Registry will use a different user information file depending on the user name or profile.
Under Windows 9x/Me, system information is kept in the file SYSTEM.DAT. This file lives in the Windows folder. If you want to make your own arrangements for backing up the Registry, this file is one of those that should always be backed up. Because the information it contains is computer-specific, it should never be restored to a computer other than the one it came from.
User information is kept in the file USER.DAT. By default this also lives in the Windows folder, and holds the data for the system's default or only user. If user profiles have been enabled, there will also be a USER.DAT for each user, stored in the folder C:\Windows\Profiles\<username>. When a new profile is set up the default USER.DAT is used as a starting point. When backing up the system manually you need to ensure that everything under C:\Windows\Profiles is backed up if you want to preserve each user's personal settings. Again, it is not advisable to attempt to restore this file to a freshly reinstalled system.
Under Windows NT/2000 the physical storage of the Registry data is very different from that used under Windows 9x. System information is kept in a number of different files, most of which are only accessible by the system administrator for security reasons. Most of these files are stored in the System32\Config folder. User information is kept in files named NTUSER.DAT, which are stored in the Profiles subfolder of the main Windows folder. To back up the Registry manually the contents of both the Config and Profiles subfolders must be backed up. It is recommended that you use NTBACKUP.EXE or some other Windows NT/2000 compatible backup program.
How the Registry is stored is of little interest, except for backup purposes. It is more useful to understand the logical view of it as seen by Windows and by applications, and as presented to you by the Registry Editor. In the remainder of this article we will explain what you can see and what use you might make of this information.
Root Keys
As you can see when you start the Registry Editor, the Registry has six major branches or “root keys.” Each branch is used to hold a distinct class of information.
HKEY_LOCAL_MACHINE is the branch that contains information relating specifically to the computer itself. Examples of this include the installed hardware and software, drivers for the hardware and configuration data for the software. The contents of this branch are stored in the file SYSTEM.DAT in the Windows 9x Registry.
Among the software-related data stored in this branch is information about file types and the actions (Open, Print and so on) that can be performed on them. For example, when you install an application that allows TIFF image files to be viewed, information linking this file type (with a .TIF extension) with this application will be stored here.
Also stored here is information about software components installed in the computer. Windows supports an object-based architecture that allows software components to be used by any application. This technology has evolved since it was introduced in Windows 3 and has been known as Object Linking and Embedding (OLE), ActiveX and Component Object Model (COM). Components installed on the computer are registered in the Registry so that other programs know they are there and are able to make use of them. An example of this is Internet Explorer, whose browser component can be used by any program that needs to display web pages or other HTML-formatted data.
HKEY_CLASSES_ROOT contains information relating file types to the actions which can be performed on them (Open, Print and so on) and information about installed software components. In fact, it is a mirror of the corresponding sub-branch of HKEY_LOCAL_MACHINE which is made accessible by itself as a root key for compatibility reasons. Microsoft first introduced a Registry in the 16-bit Windows 3, but it contained only this information. HKEY_CLASSES_ROOT allows program code written for Windows 3 to work without modification, but it also provides a convenient way for today's software to access a frequently used class of Registry data.
HKEY_CURRENT_CONFIG is another mirror of a sub-branch of HKEY_LOCAL_MACHINE. In this case, it contains the current hardware configuration of the computer. Windows supports hardware profiles which allow you to enable or disable the drivers for different hardware devices according to whether they are present. (An example of this is a notebook PC which can use certain devices only when it is plugged in to a docking station.) All the profiles are stored in separate branches under HKEY_LOCAL_MACHINE and HKEY_CURRENT_CONFIG provides a direct route to the current one.
HKEY_USERS is the root key for information that relates to users of the computer, not the machine itself. It holds user preferences such as the display settings, the desktop appearance, system sounds, lists of recently opened files and so on. Applications also store user-settable options here. The contents of HKEY_USERS is stored in files named USER.DAT (or NTUSER.DAT under Windows NT/2000).
HKEY_USERS contains user configuration data that relates to the default user as well as to named users (if user profiles have been enabled in Windows 9x). However, applications always access user settings via the root key HKEY_CURRENT_USER, which as the name suggests, gives access to the settings for the current user. This root key is created when the user logs in. Changes made to this data are written to a USER.DAT file stored in the user's subfolder of the Windows Profiles folder.
HKEY_DYN_DATA is a key that provides access to performance and status information about components of the system. This data is not stored anywhere: it is constantly-changing data that is held in locations in Ram and updated by software drivers or the Windows kernel. The Registry merely provides a convenient interface for programs wishing to access it. Software utilities that display information about CPU usage, memory usage, network data transfer rates and so on simply read this information from HKEY_DYN_DATA and display it in an attractive graphical form. However, it's difficult to interpret this data by inspecting it in the Registry Editor.
File types and actions
As we mentioned earlier, HKEY_CLASSES_ROOT contains information that relates file types to the actions which can be performed on them (Open, Print and so on). The easiest way to add and delete file types and change the actions that can be performed on them is using the Folder Options dialog box (File Types tab) of Windows Explorer. However, it can be useful to understand how file type associations are stored in the Registry.
If, using Registry Editor, you expand HKEY_CLASSES_ROOT, you'll see an array of subkeys with names starting with a dot. If you think they look like file extensions then you're right, they are! Inspect some of these keys and you'll see that they have a default value containing a name. For example, the “.txt” key normally has a default name of “txtfile”. This name is called a “ProgID” and it links to a key of that name containing the associated actions for that file type.
Well-known file types also have a value named “Content Type” which contains an entry such as “text/plain”. This is a MIME (Multi-purpose Internet Mail Extensions) content type value. This is not the place to go into details about MIME content types, but in essence they are the method used on the Internet to indicate what the data in a file actually is. File extensions are just a DOS/Windows thing and not universally applicable to other platforms.
Scroll the left hand pane until you pass the file extension keys. Here, you'll see keys with dotted names like “COMCTL.ImageListCtrl” intermingled with ones like “cplfile”. Many of the former contain registration data for COM (ActiveX) components. These entries are created by Setup programs when the components they relate to are installed. The structure of the data is complex, and all we will say about it here is “leave well alone.” You can mess up Windows quite comprehensively by tinkering with these entries.
It's the keys with names corresponding to the ProgIDs found in the file extension keys that we're interested in. Examples are “txtfile”, “htmlfile” and “Word.Document.8”. The default name value of these keys is the description of the file type that appears in the “Type” column of an Explorer window when it is showing the contents of a folder in details view.
Expand one of these keys and you'll find a sub-key named “shell” and very often one named “DefaultIcon”. DefaultIcon, if present, contains the name of a program or DLL containing the icon that is used to represent files of this type in Explorer. If the program or DLL name is followed by a comma and a number, this number points to a specific icon within the file.
If you expand the “shell” key you'll see some subkeys with names like “Open” and “Print”. These names are the actions that appear on a context menu when you right-click a file of this type in Explorer. Expand an action key and you'll see a subkey named “command”. The value of this key is the path to the program that is run to perform the action on the file. When Windows executes the action it appends the name of the file to the command unless “%1” appears in the command string, in which case the file name is inserted at that point.
Comparing the data that can be accessed from the Folder Options dialog box with the corresponding registry entries may help gain a clearer understanding of how it all works. It's easier and safer to use this dialog box to manage the file type associations on your system, but sometimes a problem may occur for which the Registry Editor offers the only hope of a solution.
Recovering stolen associations
Suppose that you install a new application - for example, an image editor. You then find that GIF files now open in this application when you would prefer to continue using the image viewer you used before. If you are lucky, all that has happened is that the new application has created an entry at HKEY_CLASSES_ROOT\.gif specifying a new ProgID, overwriting the original entry. It will then have created a new key at HKEY_CLASSES_ROOT\newprogid. The original actions at HKEY_CLASSES_ROOT\oldprogid may still exist. If so, the change is easy to reverse.
Using the Registry Editor's Search function, locate the key containing the command for opening GIF files using the original program. (Search for the program name as data.) The name of the key at the root of this branch may be the original ProgID. If this seems to be the case, all you need to do to restore the original actions is to edit HKEY_CLASSES_ROOT\.gif and change its default value back to the original ProgID.
Using the Registry Editor's Export function you can save the current file associations for specific file types so that you can restore them if another program changes them. This is what you would do, using GIF files as an example. Select the “.gif” key in HKEY_CLASSES_ROOT. Then select Registry, Export Registry File from the menu, and save the file with a name such as “gif-1”. Next, select the key named after the “.gif” ProgID, which may be “giffile”. Export this to a file named “gif-2” using the same steps. The current associations for GIF files can now be restored at any time by double-clicking these two files.
Adding document templates
When you right-click a folder in Explorer and select New, a sub-menu pops up showing a list of document types. Choose one, and a blank document is created in the folder. Using the Registry Editor you can easily add an entry for a document type that isn't currently listed. As an example, we'll add an entry to create a new HTML document.
First, create a blank web page using your HTML editor of choice. Save it to the Windows ShellNew folder with a name like “dummy.html”. You'll see that this folder already contains dummy documents of other types. In the Registry Editor select the key HKEY_CLASSES_ROOT\.html . Right-click this key and select New, Key. Name the new key “ShellNew”. Select the new “ShellNew” key to display its contents (currently just a blank default value), then right-click the right-hand pane and select New, String value. Name the new value “FileName”. Then double-click the value to edit its contents and enter “dummy.html” or whatever you called your dummy file. Close the edit box. Now right-click in an Explorer folder view and select New and you should see a new entry for “Microsoft HTML Document.”
For some document types (for example, text files) an empty document is literally an empty file. In this case you don't need to create a dummy new file in the Windows ShellNew folder. In the ShellNew registry key don't create a FileName value. Create a new string value called “NullFile” instead, and leave its data as an empty string.
Software settings
Not all applications stick strictly to this recommendation. Microsoft breaks its own rules by storing Windows configuration settings under Software\Microsoft\Windows\CurrentVersion. Many software vendors omit the version number level altogether. A few omit the vendor name and start with the name of the product. But you should always find application settings stored under the Software subkey. This makes it easy to locate the registry data relating to any application on your system. Registry keys that were clearly used by programs you have long since uninstalled may safely be deleted.
When reinstalling Windows or transferring to a new computer it can be annoying that your software configuration settings are lost. Even if the Registry is backed up, it is inadvisable to restore it to a new computer since much of the information in it is system-dependent and would be inappropriate for the new machine. However, knowing where application settings are stored, it is possible using REGEDIT to export them to a .REG file from where they can be imported to the new system's Registry.
If you try this, however, caution is advisable. Applications can store just about anything in the Registry and there is no guarantee that you wouldn't be restoring something that was invalid on the new system. Usually, though, it will be safe to restore the application's user settings from the HKEY_CURRENT_USER\Software branch. However, the application should be installed properly using the Setup program first. This will create the right settings under HKEY_LOCAL_MACHINE as well as installing and registering any COM or ActiveX components, setting up file associations and so on. It's impractical to try to do this by restoring data from another Registry.
Search Paths
Windows user preferences and settings for Windows components like Explorer are stored under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion. System-wide Windows settings are stored under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion. “App Paths” is a system-wide setting. It contains keys named after applications, for example “Iexplore.exe”. Each key contains a default string set to the full path of the named program, and a key named Path that contains a path string. It performs much the same function as a DOS search path.
If you click Start, Run and type a program name without a full path (or a program tries to execute another program by name only) and Windows can't find the program using its normal search path it will look in the App Paths subkey. If it finds a key that matches the program name, it executes the program named in the default value string. The Path string is added to the normal Windows search path and used when searching for other executable files (DLLs etc.) used by the program.
One way to exploit this knowledge is to create short names for programs by creating “App Paths” entries for the short name. For example, programmers often need to execute the program REGSVR32.EXE with command line parameters. To save typing the whole name each time you could create a subkey of “App Paths” called “RS.EXE” and set its default value to the full path “C:\Windows\System\regsvr32.exe”. (Note: to take advantage of this you should run the program using Start, Run… and not from an MS-DOS window.)
The key HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Fonts contains information about all the installed TrueType fonts. The value names are the font name as it is displayed, and the value data is the filename (and path if the font file is not in \Windows\Fonts). Knowing this you can change the names of fonts, get Windows to ignore a font by deleting its entry or relocate your font files by editing the path. But be careful, because invalid font entries can cause problems for Windows.
Startup Tasks
You'll undoubtedly be familiar with the StartUp folder of your Start menu and how shortcuts can be placed into it to make Windows launch programs automatically at startup. You'll probably also be aware that Windows usually starts many other programs at startup which don't appear here. Windows has another mechanism for starting programs that is hidden away to inhibit tampering. Unsurprisingly, this method uses data that is stored in the Registry.
Under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion you'll find keys named Run, RunOnce, RunServices and RunServicesOnce. Open the Run key. In here you'll see several named values containing paths to programs. The exact contents will vary from system to system but a few are created by Windows Setup such as the “ScanRegistry” entry. This contains the value “C:\WINDOWS\scanregw.exe /autorun” which causes the automatic registry check and backup to be performed each time Windows starts.
To prevent a program from being launched automatically at start-up using this mechanism you can simply delete the value containing its path. To add a new startup task right-click the right hand pane and create a new string value, name it appropriately and enter as its value the path (and command line arguments, if any) of the program you want to start.
The other keys mentioned earlier serve a similar purpose. RunOnce will be empty, but it can contain entries for programs that are to be run once at startup. After the program has been run Windows deletes its entry from the Registry. This key would typically be used by a Setup program to perform some configuration task that can only be done right after a restart. RunServices is similar to Run. It is used to start special tasks called “services”. Services are programs that run as part of the system. Under Windows NT they have extra privileges compared with normal tasks.
Programs may also be started automatically by adding values to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run and RunOnce. As you can see, this key is part of HKEY_CURRENT_USER and not the system-wide HKEY_LOCAL_MACHINE. Programs that use this mechanism run when the user logs in (or when the default desktop loads if user profiles aren't enabled under Windows 9x.) This means that different users can have different programs start automatically when they log in. This is more closely comparable to the function of the StartUp folder, which is also unique to each user.
An easy way to temporarily prevent programs from being started automatically is to run the System Configuration Utility MSCONFIG, select the Startup tab and clear the check box beside the program's entry in the list. If you do this, Windows moves the corresponding value from the Run key to a new key called “Run-“. This allows the entry to be reinstated by simply re-checking the check box. If you don't ever want to reinstate a disabled program you can delete its entry from the “Run-“ key.
