Introduction to the Windows registry

[ I wrote this article in 2001 for the University of Victoria Computer Help Desk. It was actually based on a presentation I developed for another employer a few years earlier. Despite its focus on versions of Windows that are no longer in common use, much of it is still accurate and useful. The registry hasn’t changed much since Windows 2000, so you can safely assume that references to that O/S apply to Windows Vista, XP, 7 and 8.x. ]

Nothing produces more fear and confusion for Windows users and support staff than the registry. Its sheer size on most systems is overwhelming.

Complex, yet surprisingly easy to work with, it can be a support worker’s best friend or their worst enemy. One false move in the registry can render Windows unstartable, but one small edit can revive it from the dead. The information that follows will hopefully help you become at home with the registry and turn it to your advantage.

This discussion will focus on the Windows 98 registry and tools. Key differences between the Windows 95, 98 and NT/2000 registries and tools will be described towards the end of the document.

Background/History

The Windows Registry: WHY ?!

The registry was introduced in Windows 3.x, not, as is commonly believed, in Windows 95.

In Windows 3.x, the registry was limited in total size to only 32K! Exceeding this limit caused GPFs (General Protection Faults), and sometimes worse, as there was no proper error handing. Gradually, applications designed for Windows 95 but ‘compatible’ with Windows 3x, began to seriously tax the Win3x registry. Some of the worst offenders were Microsoft applications, such as Office 95, which used massive amounts of registry space and used the registry in undocumented ways.

But why was the registry created in the first place? What did it replace, if anything? It turns out that OLE (Object Linking and Embedding) is the key. OLE was introduced in Windows 3.1 when Microsoft began to embrace the principles of object oriented development.

Microsoft needed to be able to represent complex OLE properties within Windows in a manner that reflected their structure – in other words, hierarchically. Up until that point, configuration information in Windows was stored in INI files, which don’t lend themselves to representing hierarchical information at all well. Thus the registry was born, and the problems of storing complex, multiply-nested, often binary information was resolved.

Later, the registry was used for storing all configuration information in Windows. This started unofficially in Windows 3.x with certain applications, and became official MS policy with the advent of Windows 95. At that point, the day of the INI file was essentially over.

However, it is interesting to note that the contents of an exported registry branch look a lot like those of an INI file. Also, the critical SYSTEM.INI and WIN.INI files are still around in Windows 98 and are updated in parallel with the registry, to some extent, “for compatibility with 16-bit applications.”

The Windows Registry: WHY NOT ?!

Unfortunately, the registry seems, at times, like a giant garbage can. Stuff goes in, never comes out, and the registry just keeps growing. This, of course, slows down system response. More about this later.

The registry files themselves are binary and not viewable or editable except via REGEDIT or programmatically. This makes dealing with registry problems rather difficult at times. In fact, until Windows 98, there was no useful way to repair the registry at all. One tool that was available early on was REGCLEAN, but it only analyzed and repaired CLASS data. As you will soon see, this represents only a small portion of the entire registry. Users of Windows 95, upon seeing the infamous ‘Registry is corrupt’ message, were basically out of luck.

While things did improve with Windows 98, there was still no coherent strategy for reducing registry clutter until Windows 2000.

[ Aside: At one point I developed a registry optimizer for Windows 3.x in response to client complaints about registry errors. It worked by exporting the entire registry to a file, deleting everything in the registry, then importing the exported file. ]

Registry Files and Structure

Physical location of the Registry

The registry is normally stored in two hidden files in the main Windows folder. If Windows is configured for multiple users, each user has a file in their Profile folder as well.

SYSTEM.DAT contains information specific to the computer’s hardware that is the same for all users of the computer, regardless of whether Windows is configured for multiple users.

USER.DAT contains user-specific information for Windows and applications.

[As noted below, later versions of Windows store the registry data elsewhere.]

Building Blocks

The registry is arranged hierarchically into branches, keys and values. Individual settings are called values and each consists of a value name and its data. Each value is limited in size to 16 KB. Values can be of three basic types: Text, Binary and DWORD (double word).

  • Text
    • Variable length
    • Null terminated
    • Some numbers are stored as text
  • Binary
    • Series of hexadecimal bytes
  • DWORD
    • Binary value limited to 4 bytes
    • Shown in both hexadecimal and decimal formats in REGEDIT

Root Keys

The topmost level of the registry, as seen in REGEDIT, is separated into several root keys. Each of these is designated as an HKEY, meaning that it is a handle to a key.

HKEY_CLASSES_ROOT (HKCR)

HKCR is essentially the vestigial Windows 3.x registry. In fact, it is just a pointer to HKEY_LOCAL_MACHINE\Software\Classes. It exists mainly for compatibility with older, Windows 3.x (16-bit) software.

HKCR contains filename extension keys, each of which consists of a file extension specification and a pointer to a class definition key elsewhere in HKCR. All registered file extensions have an entry here. Filename extension keys are identified easily as they all start with a period, for example .DLL.

Also in HKCR are the class definitions. Each class definition corresponds to one unique object, such as a file type or an OLE (Object Linking and Embedding) object. Class definitions here are typically backward-compatible with Windows 3.x and many provide support for DDE (Dynamic Data Exchange), including all of the file types.

Classes associated with a file type typically have a Shell subkey, which contains Verbs, such as open and print, each of which are actions that may be taken on files of that type.

ActiveX objects are defined in the Classes\CLSID branch. Think of ActiveX as ‘OLE lite.’ ActiveX objects include such things as QuickViewers, Property sheet handlers and copy hook handlers. Each ActiveX object is identified with a unique 16-byte ID.

HKEY_CURRENT_USER (HKCU)

This key is just a pointer to the subkey of HKEY_USERS that corresponds to the current user. Note that while value names here may be duplicated in HKEY_LOCAL_MACHINE, values here take precedence over those in HKLM.

HKEY_LOCAL_MACHINE (HKLM)

HKLM is contained in the SYSTEM.DAT file. It contains hardware-specific information along with Windows and application settings common to all users.

  • Config branch – Subkeys of Config exist for each hardware configuration. Each of these configurations corresponds to an entry in the list found on the Hardware Profiles tab of the System Properties dialog. The root key HKEY_CURRENT_CONFIG is a pointer to the entry here that represents the currently-active configuration.
  • Enum branch – Based on information obtained during the bus enumeration process, which builds the hardware tree, this branch contains information about hardware attached to the computer. Entries here are vendor and device-specific, and include device type, hardware ID, manufacturer and some driver information. Each entry also includes a pointer (the Driver key) to an entry in the HKLM\System\CurrentControlSet\Services\Class branch where more driver details are located.
    • BIOS – Plug and Play components of the BIOS (e.g. Timers, DMA, controllers)
    • ESDI – Hard drives
    • ISAPNP – Plug and Play devices on the ISA bus
    • Root – Legacy devices, including network adapters (these devices appear at the root of the Device Manager)
  • Software branch – This branch contains Class definitions, discussed above in HKCR. Application settings that are specific to the computer are also in this branch. A typical application entry consists of a subkey of this form: HKLM\Software\<Company>\<Product>\<Version>. All Microsoft products are found under the HKLM\Software\Microsoft subkey.
  • System branch – This branch is organized into Control Sets. The active Control Set is in the subkey CurrentControlSet. This branch controls system startup, device driver loading and Windows services.
    • Control – this branch contains the following:
      • Computer name
      • FileSystem – file system settings
      • IDConfigDB – a pointer to HKLM\Config\…
      • Keyboard layouts – keyboard language information
      • Resources – driver and other information for multimedia components
      • NetworkProvider – network provider information
      • Nls – national language support
      • PerfStats – System Monitor stats
      • Print – printer and printer environment settings
      • SessionManager – global variables and application compatibility
      • TimeZoneInformation
      • Update – Windows update vs. clean installation flags
      • VMM32 Files – list of VXD files combined into VMM32.VXD
    • Services – this branch contains the following:
      • <agents> – Microsoft Network Monitor, SNMP, backup agents, etc.
      • Arbitrators – hardware resource management (I/O, IRQ, DMA, etc.)
      • Class – static descriptions of hardware to which drivers can be attached; entries here are grouped by device class, each class corresponding to a device type that the O/S supports; specific devices have entries under the appropriate classes and include driver details; devices in the Enum branch point here
      • MSNP32 & NWNP32 – network information, including security
      • VxD – virtual device drivers, including disk drivers, network components, disk caches, etc.
HKEY_USERS (HKU)

Contained in the file USER.DAT, this branch includes information about all users of the computer. If Windows is not configured for multiple users, only one subkey appears: .Default, and this key contains settings for all users. If Windows is configured for multiple users, the .Default subkey will still appear, but it will only be used to create default settings for new users.

HKEY_CURRENT_CONFIG (HKCC)

This root key is actually a pointer to HKEY_LOCAL_MACHINE\Config for the current hardware configuration.

  • Display branch – specifies screen fonts and resolutions
  • Enum branch – specifies Plug and Play BIOS settings
  • System branch – contains information about configured printers
HKEY_DYN_DATA (HKDD)

Information in this branch is dynamic; it only exists in the RAM copy of the registry. It is never written to disk and can therefore be updated very quickly. In this branch is the Config Manager subkey, which is also known as the Hardware Tree. The Config Manager contains current devices and their status, including resource allocation, problems, and so on. The Config Manager shows the same information you see when you look at the Windows Device Manager. HKEY_DYN_DATA also contains performance and network counters.

Registry Map

\WINDOWS\SYSTEM.DAT                   \WINDOWS\USER.DAT
---------------------------------     -----------------------------
         
HKEY_LOCAL_MACHINE                    HKEY_USERS
|                                     |
|-Config                              |-.Default
| |-0001                              |-User1
| |-0002 <-- HKEY_CURRENT_CONFIG      |-User2 <-- HKEY_CURRENT_USER
| |-etc.                                | 
|                                       |-Control Panel
|-Software                              |-Network
| |-Classes <-- HKEY_CLASSES_ROOT       |-Software
|   |-CLSID                             |-AppEvents
|                                       |-InstallLocationsMRU
|-Enum                                  |-Keyboard layout
|-Hardware                              |-Remote Access
|-Network
|-Security
|-Software
|-System

Working with the Registry

Tools: SCANREG

New in Windows 98, SCANREG has both a real-mode (DOS) version and a Win32 version. The Win32 SCANREG runs at Windows startup and checks the integrity of the registry. It can also be run on-demand. If SCANREG detects a problem in the registry, it offers to restore from a backup.

If a previous copy of the registry cannot be restored, SCANREG offers to repair the registry. The registry can also be repaired with the DOS SCANREG, using the /FIX argument.

When SCANREG detects no problems, it backs up the registry to a compressed file in \WINDOWS\SYSBCKUP. Unless otherwise instructed, SCANREG makes only one registry backup per day. Note that SCANREG does not handle registry backups properly if Windows is configured for multiple users. The USER.DAT file for each user in this case is stored in their profile folder, rather than in the main Windows older, and SCANREG does not take this into account.

Another useful feature of SCANREG is its ability to monitor the amount of empty space in the registry. When a certain threshold is reached, SCANREG will automatically rebuild the registry, eliminating the empty space. This reduces the tendency for the registry to grow to an unwieldy size.

The operation of SCANREG is controlled by SCANREG.INI, in the main Windows folder. The most useful parameter in SCANREG.INI is MaxBackupCopies. This controls the number of backups SCANREG keeps.

The DOS version of SCANREG can be used to manually restore a backup of the registry. So even if Windows won’t start, it’s possible to go back to a previous version of the registry. Note that if the value of MaxBackupCopies is greater than 5 and there are more than five backups, SCANREG is unable to display or restore some of the backups.

Tools: REGEDIT

REGEDIT is the main tool for editing the registry. There are real mode (DOS) and Win32 versions of REGEDIT.

The Win32 version of REGEDIT has a GUI interface and allows importing, exporting, deleting and editing on any part of the registry. It also includes a rudimentary search feature, but there is no search and replace.

The DOS version of REGEDIT allows importing, exporting and deleting portions of the registry, but does not allow direct editing. A special argument (/C), replaces the entire registry by completely overwriting it with the contents of a specified REG file. The DOS REGEDIT is useful in situations where Windows will not start.

Approved Methods for Changing the Registry

According to Microsoft’s documentation, the only approved method for users to effect changes in the registry is to use the Control Panel. Needless to say, this limits the user’s reach to a very small portion of the registry. Microsoft is always very careful to explain that use of REGEDIT is extremely dangerous.

Editing the registry with REGEDIT

REGEDIT should always be used with a high degree of caution. Changes made in REGEDIT are immediate and irreversible (unless you have a backup). An entire branch of the registry can be deleted with no special warning other than a single confirmation, the same displayed when deleting one value. In other words, one false move can render Windows useless – you may get an immediate lockup, or simply be unable to restart Windows.

As mentioned above, REGEDIT has a rudimentary search function. Key and value names can be searched, as well as value data. There is no way to exclude branches from a search; because some of the root keys point to other areas of the registry, you end up searching some areas more than once. This explains why searching always seems to turn up the same information multiple times. Third party tools do a much better job in this area. Many allow search and replace and some allow for limited search scope.

Particularly dangerous areas of the registry include those related to Plug and Play and other hardware devices, specifically HKLM\Enum, and HKLM\System\CurrentControlSet.

Backing up and restoring

In Windows 98, the entire registry can be backed up using SCANREG, as outlined above. In Windows 95, a Resource Kit utility called CFGBACK provides a similar function. The registry can also be backed up and restored by copying the physical files SYSTEM.DAT and USER.DAT.

Windows 95 keeps one backup of the registry that it creates on each startup; the backup files are SYSTEM.DA0 and USER.DA0. All Windows 9x versions create a backup of the initial system registry called SYSTEM.1ST, but this file reflects the earliest state of the registry and contains no corresponding user information.

REGEDIT has the ability to export and import selected portions of the registry. Exported files are given the .REG extension and contain human-readable text. Exporting a section of the registry that you are about to modify is always a good idea. An exported registry key looks a lot like an INI file: settings are grouped under square-bracketed headings, and each value is shown as a value name, followed by an equals sign and the value data. Note that a value name of ‘@’ in a REG file corresponds to the <default> value name as displayed in REGEDIT.

When an exported REG is imported, the file is merged with the registry. Values specified in the REG file overwrite matching values in the registry. Unspecified values are left intact. By default, double-clicking on (opening) a REG file from Windows Explorer causes the file to be imported.

Registry Questions

How big is the Registry?

One way to answer this question is to count the number of values (name and data). To do this, you can export the entire registry to a REG file, load the file into a text editor and count the number of equal signs. A typical Windows 98 registry will have upwards of 80,000 values. Ouch!

How big can the Registry be?

The registry in Windows 98 is limited in size only by physical memory and disk space. In other words, it can become gigantic.

When do Registry changes take effect?

Registry changes are made to the current, active copy of the registry in system RAM. Whether a specific change has an immediate effect depends on the affected component. If the setting is only used during component initialization, the change will probably only be noticeable when Windows is restarted.

When is Registry data written to disk?

Registry changes are saved to the physical registry files within a few seconds of being changed, or when an application explicitly requests flushing the registry to disk.

The Registry as a Garbage Can

While the registry does have some redeeming features, the lack of enforced installer standards, combined with general sloppiness on the part of software makers (including Microsoft), has led to the tendency for the registry to become gradually filled with garbage.

The problem is, software makers care much more about adding to the registry than they do about removing anything from it. Registry entries that are never used are theoretically harmless, but if enough of them pile up, system performance suffers. As well, the failure of uninstall programs to clean up the registry properly can create conflicts and other problems that are almost impossible to diagnose.

Other registry garbage includes key size abuse. Microsoft’s documentation states that if a key contains more than 64 KB of information, it should be replaced with a pointer to a file. The registry entries for Creative Labs’ Sound Blaster Live audio hardware, for example, do not follow this recommendation.

Another common cause of registry garbage is errors in installation programs. When registry keys are created programmatically, the proper syntax must be used. Otherwise, keys are created incorrectly or in the wrong part of the registry. Common errors include misplaced slashes and backslashes, and specifying the wrong root key (e.g. HKLM instead of HKCU). If you find a Software key under HKCR, HKU or HKLM\Config\xxxx, you have found registry garbage.

Differences between the Win95 and Win98 Registry

  • Windows 98 registry handling code is faster and more robust
  • Windows 95 had a key size limit of 64KB – removed in Windows 98
  • Windows 98 includes tools for detecting and repairing registry problems
  • No SYSTEM.DA0/USER.DA0 in Windows 98 – not needed due to SCANREG

Differences between the Win9x and NT/Win2000 Registry

Besides REGEDIT, Windows NT has a tool called REGEDT32. This tool is similar to REGEDIT, although perhaps more difficult to use. The most important difference between REGEDIT and REGEDT32 is that REGEDT32 allows setting of permissions on arbitrary registry branches. This corresponds to the generally much more security-conscious design of NT as opposed to 9x.

The NT registry keys are organized somewhat differently than those in Windows 9x. While the HKEY_CURRENT_USER branch is basically the same in NT as in Win9x, the HKEY_LOCAL_MACHINE branch has some important differences. Hardware profiles are not stored under HKLM\Config as in Win9x, but under HKLM\SYSTEM\CurrentControlSet\Hardware profiles, and so the root key HKEY_CURRENT_CONFIG points there as well. The device enumeration branch is not found under HKLM\Enum as in Win9x, but under HKLM\SYSTEM\CurrentControlSet\Enum. Hardware class information is not found in HKLM\SYSTEM\CurrentControlSet\Services\Class, but in HKLM\SYSTEM\CurrentControlSet\Control\Class. HKEY_CLASSES_ROOT, in all versions of Windows prior to Windows 2000 (including NT4), was simply a pointer to HKLM\Software\Classes.

In Windows 2000, the information in HKCR is derived from machine information at HKLM\Software\Classes and user information at HKCU\Software\Classes, with duplicate entries in HKCU having precedence over HKLM.

The physical registry files in NT differ from Win9x in both their location and names. The NT registry uses a system of ‘hives’ to store sections of the registry in separate files in \WINNT\System32\Config for machine settings and in the current user’s Profiles directory for user settings. The Profiles directory is under the main WINNT directory in NT4 and under Documents and Settings in Windows 2000. The machine hives include these files: default, SAM, SECURITY, software and system. The user hive consist of one file, NTUSER.DAT.

The size of the NT registry is controlled by system settings; when the maximum is reached, an error message is generated.

Windows 2000 introduced further refinements, including the way registry entries are now considered installable components in the new Windows Installer Service (WIS). This feature reduces the likelihood of garbage being left behind when an application is uninstalled. The Windows 2000 REGEDIT exports Unicode text by default, has a Favorites system, and opens at the last key viewed.

Conclusion

I hope this has helped to de-mystify the Windows registry somewhat. Like it or hate it, it seems clear at this point that we’re stuck with it.

Rants and musings on topics of interest. Sometimes about Windows, Linux, security and cool software.

Close

Ad-blocker not detected

Consider installing a browser extension that blocks ads and other malicious scripts in your browser to protect your privacy and security. Learn more.