How the Registry Is Architected

Windows IT Pro

- Advertise

How the Registry Is Architected

Author:	Darren Mar-Elia
Published:	July 2000
Copyright:	2000
Publisher:	Windows IT Library

Abstract
In this chapter, I review the basics: how the Registry is structured and what function each subtree performs, pointing out along the way some new features of the Windows 2000 Registry that you should know. I present the Registry value data types and the Registry hives. I then consider in the discussion of HKEY_CURRENT_USER how one important element of Win2K, the user profile — which has been the source of many problems within Windows — uses the Registry. I explore Registry security, which can have a significant impact on both a user’s and an application’s ability to make changes to a Win2K system. Finally, I briefly cover how the Registry uses memory in Win2K.

REGISTRY SUBTREES

The Registry is often seen as a mystical piece of Windows NT. When you find the Registry key or value that fixes a problem, you feel like you have found the final prize in a great treasure hunt. Ironically, the Registry was originally intended as a behind-the-scenes part of NT that would make life much easier than the much maligned .ini files of Windows 3.1. The reality, of course, has ended up being much different. Today, it is almost imperative for a well-armed systems administrator to have a good working knowledge of the Registry and how it interacts with both the operating system (OS) and installed applications. Understanding the underlying structure and function of any technology helps you effectively troubleshoot problems that may arise. The Registry is no exception.

You can think of the Registry as a kind of database of information about your Win2K system and the users who log on to it. The database metaphor, however, only goes so far. The Registry lacks many of the characteristics of a modern database — it isn’t relational, indexed, or organized by rows and columns. It does, however, have a schema of sorts that describes the organization of its data, and you can search the Registry for specific data, as you would a normal database.

What you see when you start up one of the several tools that lets you view and manipulate the Registry is a set of "subtrees" that represent different aspects of a workstation or server’s configuration. To see the structure I describe, log on to your Win2K workstation as an administrator, and from the Start Menu, select Run and type in regedt32. When you click OK, the Win2K Registry Editor tool appears (Figure 1). You notice five windows, or subtrees, which appear as follows:

HKEY_LOCAL_MACHINE
HKEY_CURRENT_USER
HKEY_CURRENT_CONFIG
HKEY_USERS
HKEY_CLASSES_ROOT

Note: You often see Microsoft documentation refer to these subtrees as the "root keys" as well. I prefer the term subtree.

Despite the subtrees’ cryptic names, there is a meaning behind the HKEY moniker. If you are familiar with Microsoft programming conventions, you will recognize that the H in HKEY refers to a "handle" for that particular subtree. A handle is an easy way of referring to a particular structure without having to constantly call it by name. It is strictly a programming convention, and its use further illustrates Microsoft’s original intention that NT users should not have to manipulate the Registry directly to configure their systems.

Within each subtree are sets of keys, subkeys, and values. For example, if I maximize HKEY_LOCAL_MACHINE from Figure 1, we can examine it in more detail. Figure 2 shows only the HKEY_LOCAL_MACHINE (HKLM) subtree. On the left-hand pane, you can see that I have expanded HKLM to display a number of keys beneath the top level.

Specifically, I’ve drilled down into the Software key, to the subkey called Microsoft, and then further into the highlighted subkey, called DirectMusic. For this particular machine, the DirectMusic key corresponds to the name of an application that has been installed on this copy of Win2K. In the right-hand pane, you can see a value, called GMFilePath, that has been assigned to DirectMusic. Further, GMFilePath is of a variable type REG_EXPAND_SZ (I discuss the different variable types available to Registry data later in this chapter). GMFilePath contains the data %systemroot%\system32 \drivers\GM.DLS.

In general, the five Registry subtrees can be categorized as either machine-specific or user-specific. Machine-specific entries correspond to configuration information that is present regardless of which user is logged on to the machine; user-specific entries are only relevant and valid when a given user is logged on. For example, the type of video driver a workstation has loaded is machine-specific information — in this case, part of HKLM. Of the five subtrees above, HKLM, HKEY_CURRENT_CONFIG (HKCC), and HKEY_CLASSES_ROOT (HKCR) are all machine-specific subtrees. HKEY_USERS (HKU) actually has elements of both when a user is logged on, but is generally machine-specific. HKEY_CURRENT_USER (HKCU) is user-specific and only exists when a user is logged on to a workstation.

The True Subtrees and Their Aliases
Of the five subtrees, only two — HKLM and HKU — are "real." What I mean by "real" is that they are the only two subtrees backed by files, the only two that exist regardless of whether someone is logged on to the machine. Two of the other subtrees — HKCC and HKCR — are "aliases" or links to individual subkeys within HKLM. When I say links, I mean that the keys and values shown in HKCC and HKCR are really keys and values in HKLM. If you make a change to one, that change is reflected in the other. If you’re familiar with Unix-based file systems, you recognize that HKCC and HKCR are really symbolic links to their true location within HKLM. Placing them within their own subtree makes it easier to navigate directly to the information you need in each area.

Note: You may also have heard about a subtree called HKEY_PERFORMANCE_DATA. This subtree is normally accessible only via API call, and it provides applications with access to the same data that Win2K’s Performance Monitor tool uses to view and log performance data.

The fifth subtree, HKCU, is actually the "Settings" portion of a logged-on NT or Win2K user profile and an alias of a special subkey that is loaded into the HKEY_USERS subtree at user logon — based on the user’s Win2K Security Identifier (SID).

The following list describes the relationship of the five subtrees:

HKEY_LOCAL_MACHINE = HKEY_LOCAL_MACHINE
HKEY_USERS = HKEY_USERS
HKEY_CURRENT_CONFIG = HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current
HKEY_CLASSES_ROOT = HKEY_LOCAL_MACHINE\Software\Classes (and HKCU\Software \Classes)
HKEY_CURRENT_USER = HKEY_USERS\<SID VALUE>

As you look at the subtrees, note that three of the five are subkeys of HKLM and HKU that have been "exploded" for easier viewing.

HKCU: A Special Case
When users log on to a Win2K workstation, the part of the user profile that stores personal preferences and application configuration information — namely the ntuser.dat file — is temporarily loaded into the Registry as HKCU. You notice that if you connect to a remote Win2K Registry using a tool like regedt32, HKCU — and HKCR — are unavailable. HKCU and HKCR are only available if you are physically at the machine. However, you can view HKCU indirectly through its root subtree, by expanding HKU\<SID Value> for the logged-on user (Figure 3).

The long numbers, beginning with S-1-5-21, are the currently logged on user’s SID. The reason there are two keys for a given user, one suffixed by _Classes, involves a new feature in Win2K that I discuss later in this chapter. For each user logged on to the system, you see these two keys loaded under HKU, prefixed by the user’s SID.

Note: In some cases you may see multiple pairs of SIDs under HKU, which would seem to indicate multiple users logged on to the machine at once. Although you may not think this possible, it is indeed. What you see is a Win2K service, running under the context of a valid Win2K user account. In this case, when the service starts, the user account running that service is, in effect, logging into the system.

THE FUNCTION OF THE FIVE SUBTREES

Now that you are familiar with the five subtrees, let’s talk a little bit about the role of each.

HKEY_LOCAL_MACHINE
As its name implies, HKLM is a machine-specific subtree. It holds most of the configuration information related to your Win2K installation — both installed hardware and installed OS parameters. It also contains the local Security Accounts Manager (SAM) database, encrypted user password information, and the security policy for Win2K workstations and member servers. And it is where most 32-bit Win2K applications store their configuration information when you install them on your system. Figure 4 shows the main keys under HKLM on a Win2K workstation.

The following sections describe the function of each key.

Hardware
The Hardware key is a unique one in the Registry. This is because Win2K itself creates and fills all of the keys and values under Hardware when it first boots up. The Hardware key contains dynamic information related to the hardware configuration of the system — as it exists when the system is started. The kind of information included in the key includes things like the current processor type, the Hardware Abstraction Layer (HAL) that Win2K loaded, the parallel and serial port interrupts in use, and the raw device names for various Win2K resources. Raw device names are the way that Win2K refers to the I/O devices with which you are familiar. For example, Win2K calls your COM1 serial port "\device\serial0."

In general, all values found in the Hardware key are fixed — that is, you can’t change the way the system behaves by changing a key or value in this part of the Registry. If you did change a value, it would be reset to the detected value the next time Win2K boots. In NT 4.0, the information found in the Hardware key is used by common NT utilities, such as WinMSD, to provide system configuration information. In Win2K, much of the configuration information about a system is kept in the Web-Based Enterprise Management (WBEM) repository. WBEM is a new industry-standard way of instrumenting and describing a computing device through a common set of interfaces. In Win2K, Microsoft calls its implementation of the WBEM standard Windows Management Instrumentation, or WMI. Win2K uses WMI extensively to get the management information it needs and provide management information to third-party tools.

SAM
The SAM key is found on workstations and member servers only. If you open a Registry tool on a Win2K domain controller, you see the SAM key, but it has only a limited purpose. Specifically, if you boot your domain controller into "recovery console" mode, you still need to authenticate to the system using the local administrator account. Win2K still keeps the administrator account and password for this non-domain controller mode in the SAM key. As you may know, what used to be the SAM is kept in the Active Directory (AD) database in Win2K. That is, the AD is the new repository for storing user accounts, user groups, security rights, and security policy for a Win2K domain. The SAM as we have known it in the NT 4.0 domain world goes away.

Of course, for purposes of downlevel compatibility, Win2K domain controllers emulate the SAM for access by downlevel (e.g., NT 4.0) devices, but user information is no longer kept in this Registry key (with the exception of the recovery administrator account described above). The AD database uses a newer version of Microsoft’s JET database engine to store all of this security information. The AD provides a hierarchical and extensible directory service to Win2K servers and clients — something the NT 4.0 SAM could never provide. In "The Registry and the Active Directory," I discuss further how the AD provides you with better control over the Windows Registry using features such as Group Policy and Software Installation.

On Win2K member servers and workstations, a local SAM is still held in the Registry. User account and user group information is kept in this key. Normally, when you open a Registry editing tool like Regedt32, the SAM (and Security) keys are grayed out (unavailable for drill down). This is because default permissions prevent normal users from accessing these keys. The special LocalSystem account is normally the only user that has access to these keys.

Security
The Security key is closely related to the SAM key. It holds the account policy information for the workstation or member server, as well as the security rights users have against the local SAM. For example, if a workstation has an account policy that enforces bad password lockouts, this setting is kept here. If a member server gives user JSmith the right to log on to the server locally, this user right is also stored in the Security key.

Note: As with the SAM key, the Security key is unused on Win2K Domain Controllers, because security policy is kept within a Group Policy in the AD.

Software
The HKLM Software key ends up holding the lion’s share of information. It is within this key that all Microsoft and most third-party applications write their configuration information. Indeed, it is now a Windows Logo requirement for Win2K that applications keep their configuration and policy information within specific keys in the Registry — and most of those keys reside in the Software key. The general idea is that under Software, an application vendor would place a key — usually the company name — and then under that key, the subkeys and values would be created for the company’s installed application. For example, if you installed software from the ABC Software Company, you should see Registry entries under HKLM\Software\ABCSoftware that pertain to that product’s configuration options. The Software key also contains the Classes subkey, which is the source of HKCR (see the HKCR discussion later in this chapter).

System
The System key holds information related to the configuration of Win2K itself. Most notably, this is where NT devices and services are defined — specifically in HKLM\System/CurrentControlSet\Services (Figure 5). Also notable is HKLM\System\CurrentControlSet\ Control, where global settings for Win2K are kept.

Within HKLM\System\CurrentControlSet\Control, Win2K keeps settings related to its own configuration. That is, it is here that you find Hardware Profiles — a feature first found in NT 4.0. (Hardware Profiles are also kept in the System key, within the CurrentControlSet subkey.) Although Hardware Profiles don’t play as big a role in Win2K as in earlier versions of NT due to new support for Plug-n-Play, they are nonetheless supported. The HKLM\System\CurrentControlSet\Enum key is where plug-and-play devices that were discovered at boot time are enumerated.

Page: 1, 2, 3

ADS BY GOOGLE