Components Guide: Registry

At the heart of Windows is the registry. It is a binary tree of data used as a repository of information that all Windows programs, and including Windows, use. This means configuration information for your programs is stored in a single place that is both fast and secure, so each program does not have to implement its own information storage system. This makes it easier to write a program, and it makes the storage model much cleaner, which helps when it is time to perform a backup. It also creates a single point of failure because if the registry gets corrupted then your computer will not work, or at least won't work correctly. And it also is more complex then, for example, a text file that contains the configuration information for a program.

• History
• Location
• Permissions
• Structure
• Value Types
• Information Registration Editor
• NT Information Configuration Editor
• Services in the Registry
• Special Locations

History

The registry was first implemented into Windows in the 95 release, or at least the registry as we know it. The true beginning of the registry was in Windows 3.1, where it was a single file used almost exclusively for Microsoft products. These few programs used it mainly as a source for object linking and embedding (OLE, pronounced as Oh-Lay) so that programs could share object classes, which is a complicated way of saying programs used it as a way to communicate with eachother. It was also used for file associations. This registry was named reg.dat and it was stored in the Windows folder. The registry at this point worked similarly to how it does in later versions of Windows, but the scope was much smaller. The file gets built on the installation of Windows by a setup.reg file that can be found in the Windows' system folder after installation, and is maintained by the regedit.exe. Only four versions of Windows used the reg.dat file, and the concept was revamped in Windows 95 to include a divided hive that was useful to more than just Microsoft products.

Return to top.

Location - Finding the Registry Components

The registry itself is a composite of multiple files, and these files vary depending on the version of Windows. The files that make up the registry are known as hives. They are very important to the operation of Windows, and without them the operating system will not operate. The hives are set in groups known as handle keys (HK).

Location: Windows 95, 98, Me

The registry is easier to locate in Windows 9x then it is in Windows NT. The registry is split between two different files, the User.dat and the System.dat. These are both found in the Windows folder, which is most generically located at c:\windows. The User.dat represents the hive known as the Current User, and the System.dat represents the hive known as the Local Machine hive. Backups of these files are created with a DA0 extension instead of DAT. So, the User.da0 and the System.da0 files are complete backups of the registry, created at the last successful load of them. This means if they get corrupted you could just rename the backups and you'd lose very little. If multiple logins were configured are enabled on Windows 9x through the passwords control panel then the user.dat will be stored in c:\windows\Profiles\<username>\USER.DAT, where <username> is replaced by the name used to login. Windows Me also contains a classes.dat file in addition to the user and system dat files.

Location: Windows NT4, 2000, XP, Longhorn

In Windows NT it is a bit trickier to locate the hives than it is in Windows 9x. The current user hive is located in the user profile folder and is named NTUSER.DAT. On Windows 2000, XP and Longhorn the user profile folders can be found in C:\Documents and Settings by default, but in Windows NT4 the default path to the user profiles is in C:\winnt\profiles.

The local machine hive though is split between several different files. These can be found in the Windows folder under the system32\config directory, so these would by default be in C:\windows\system32\config for Windows XP and Longhorn and c:\winnt\system32\config for Windows NT4 or 2000. The files default, SAM, SECURITY, software, system and userdiff are the local machine hive components.

Return to top.

Structure

The registry is laid out as a tree structure. The registry is built from hives that are registry roots, keys and subkeys, which are directories and subdirectories (folders), values, which are items contained within keys and are much like files, and data which are the contents of the values. There are several main roots called handle keys (HK) that branch out to form the Windows registry.

The first main component is called the current user handle. The items contained in this handle represent settings valid for the loaded user profile, so they apply for the user that is actively logged in. So this handle is loaded when a user logs in, and is unloaded when a user logs out. This handle is represented in group policy as user configuration.

The second handle is called the dyn data handle and should only exist in Windows 95, 98 and Me (and to some degree on Windows NT4). It is used for storing computer configuration information into memory. The system creates it on startup and alters it when computer devices are updated. It is also responsible for gathering network statistics.

The third handle is called the local machine hive. This hive contains the settings that are applied to the operating system while it is booting. Therefore the settings in this hive affect all users that log into the computer, as well as the settings before a user logs in and after a user logs out. This hive is represented in group policy as computer configuration.

The fourth handle is the classes root handle, that most registry editors will show. This handle does not actually exist as a file, but is rather two separate hives. In fact, it is a combined listing of the current user and local machine classes, found under the Software keys. This allows for a single place to view all the classes keys so you don't have to search two places. However, when a program writes to the classes root they are really choosing to either write to the current user or local machine handle under Software\Classes.

The fifth handle is the users handle . Once again this represents a mount point of several different files. Under this handle there will be a .default key and normally at least one other key. The .default key contains the template settings used when a user logs in for the first time. In Windows NT the .default profile represents the file named default explained in the locations section. Also, in Windows NT the extra keys in this handle show all the user hives the system has loaded, but they will be masked by security identifiers (SIDs) instead of having the user names. So one of these keys will be an alias to the current user hive. But, additional hives of other users can be loaded so their profiles can be edited even while those users are not logged in. There should also be another key under users, and it should be named by the SID, but it should end with _Classes. This is an alias to the current user Classes under Software. So if you update it here it will also update it there, and the changes will also show up in the classes root handle. For your information, internally users are recognized as a string of hyphenated letters and numbers that begins with the letter S, and they are called SIDs. This allows users to be renamed without the pointers to the account going stale. This also means that once a user is deleted you can't recreate that user, because the name is just a visual display name.

The sixth handle is the current config handle, and it is just a pointer to HKLM\System\CurrentControlSet\Hardware Profiles, and it should only exist in Windows NT4, 2000 and XP. So if you updated the current config hive it would actually update the items under the hardware profiles key.

Return to top.

Value Types

As explained in the structures section there are values that can store data. But, there are several different types of values, and as such they store different types of data. This allows the registry to be efficient...

The first value type I will explain is the string, recognized as the type of REG_SZ. These simply contain text of a fixed length. This means it can contain numbers, letters and symbols.

The second value type is the double word (dword), recognized as the type of REG_DWORD. In computer terms a word represents the most amount of data that can be transferred in a single clock cycle across a parallel design. Most modern day computers communicate using 32bits, but some use 64bits. However, the registry was designed in Windows 3.1, and as such as the registry's definition of word is based on a time when the operating system was only 16bit. So a double word of that would only be 32bit. The dword contains a number as data, and must be 0 or a positive number. Since computers use binary (base 2 math) this means that the largest value a dword can contain is 2^32, or a decimal value of 4,294,967,295. In hexademical the highest value would be 0xffffffff (base 16 math). If this confuses you then don't let it bother you, the basic concept to understand here is that a dword value contains a number of limited size. It should be noted though that most dwords contain only 0 (off) and 1 (on) because they're used as toggle switches for program features.

Another string type exists and is known as an expandable string, or REG_EXPAND_SZ. These are like strings, except they are variable in length. Plus the data in this value can contain environment variables, which are filled in at the time of use. An example would be a expandable string that contains the path to the system root, which is normally C:. Since is stored in Windows NT as %SystemRoot%, so if the string of this type contained that, then anything that accessed this registry value would be returned the drive letter followed by a colon.

A third string type exists and is known as a multiple string, or REG_MULTI_SZ. These are values that contain, as the name suggests, multiple strings. So these types are basically a list of text lines.

Another value type is the binary type, or REG_BINARY. This is a pretty raw format, and as such most system component information is stored using this type. This type is also the least human friendly type. However, since binary is a waste of visual space these values are displayed normally as hex values. This is because binary is only base 2, so a number like 250 in decimal would be 11111010 in binary.

A seldom used value type is the quadruple word (qword), displayed as the type REG_QWORD. This value type was first introduced in Windows 2000, and then was carried over into Windows XP and Windows Longhorn. The concept here is that the data can be twice that of a double word, or 64bit. This means that it can contain a decimal value of 18,446,744,073,709,551,616 (2^64). Most registry tools do not properly represent these value types, and they will be shown as a REG_BINARY.

The registry also contains symbolic links, known as REG_LINK. These are just points that look to another location in the registry.

There is also a type with no value type that is known as REG_NONE. It is represented as a binary value, and is displayed normally as hex.

Each key also has a default value assigned to it, which basically means each key is basically a special value that marks a branch in the tree. This value is always of type REG_SZ (string), and it will normally appear in registry editors as the first item with the name of (Default). The true name of is blank, and sometimes these will be referenced with the @ symbol.

Return to top.

Permissions

Since the registry needs to operate on a multi-user computer, where each user has different attributed privileges, the registry requires the ability to differentiate access control based on users and group membership. These permissions are accomplished through access control lists (ACL), but you should read the chapter on that if you want to understand them better. It should be noted here that this does not apply to Windows 95, 98 or Me, as they are not multi-user operating systems. In the registry only keys can have permissions applied to them, so you can't apply permissions directly to the values. Instead, the values of a key inherit the permissions of the key. Often there are keys you will not be able to alter, and you will need to take ownership of them or give your username, or a group you are a member of, read/write permissions to that key. Of course, this requires administrator access.

Return to top

Information Registration Editor

The normal way to modify or view the registry is through the information registration editor, which is executed from a file stored in the Windows folder called regedit.exe. This program provides a visual interface to the large and complex registry. It allows you to create keys, delete keys, add values, set or change the data for a value, delete values, view the data of values, import registry settings, export registry settings, and generally just view the structure of the registry.

Also, the information registration editor can alter the access control lists on keys, so you can set permissions through it. However, this only works on Windows XP. In Windows 2000 or Windows NT4 you have to use the information configuration editor (see the next section) instead. Remember also that you cannot set permissions on the registry in Windows 95, 98 or Me as those operating systems do not recognize access control lists.

In Windows 95, 98, Me and NT4 the information registration editor will not display the type of value set, and instead only represents the values with icons. For string based values they will say "ab", and for binary based values they will say "011110". This is exceptionally confusing, and luckily there was a new information column added for the type of value in Windows 2000. But, if you happen to use older versions of Windows then you have to be careful about what values types you are editing.

In Windows NT4 and 2000 the information registration editor will display and allow you to edit REG_EXPAND_SZ and REG_MULTI_SZ values, but they will display those values to binary. And if edited they will corrupt the values as they will be saved in REG_SZ format, which will corrupt their string data. To edit these types of values on Windows 2000 and NT you will need to use the information configuration editor (see the next section).

Return to top.

NT Information Configuration Editor

In Windows NT4 there were many additional features added to the registry that Windows 95 did not have. But, Microsoft, instead of updating the Windows Information Registration Editor (regedit), decided that it would make more sense to create another registry editor. They call it the Windows NT Information Configuration Editor, and the filename is regedt32.exe. The program looks a lot like a 16bit Windows application, straight from Windows 3.11. So this means the interface is not only ugly (see the picture on the left), but it also doesn't feel like the typical Windows program. Once you get passed the superficial differences though, the program is still easy to use.

The largest difference between regedit and regedt32 is the ability for this one to set permissions on keys. This is extremely useful because Windows NT is based on the fact that users can have different security levels based on the username and password they log in with. But, all users need to access the registry no matter how little access they have because programs rely on the registry in order to run. So the permissions allow the system to limit the type of access the user has to specific sections of the registry.

The configuration editor also lets you set value types that you could not in the registration editor. This applies to REG_EXPAND_SZ and REG_MULTI_SZ values. The normal registration editor will show REG_EXPAND_SZ values, but only as REG_SZ. This means that if you don't use the configuration editor that you could corrupt expanded values by writing back more simplistic data.

In Windows XP and beyond this editor does not exist, and instead the regedt32.exe only servers to initialize regedit.exe. However, the features in this editor now exist in regedit.exe, so this editor has been deprecated.

Return to top.

Services in the Registry

Please read the chapter of this guide on services for information on this topic.

Return to top.

Special Locations

The registry is exceptionally large, and often it is hard to locate specific settings or to understand how powerful the registry actually is. The chart below lists common areas of settings, but most of them will be fairly broad. It should be understood that HK stands for handle key, CU for current user, and LM for local machine.

Return to top.