Registry data: How it is stored and used
Now that you know more about the registry’s structure, let’s
take a look at the actual data within the registry. Understanding how
registry data is stored and used is just as important as understanding
the registry structure.
Where registry data comes from
As mentioned previously, some registry data is created
dynamically during the startup of the operating system and some is
stored on disk so that it can be used each time you boot a computer.
The dynamically created data is volatile, meaning that when you shut
down the system, it is gone. For example, as part of the startup
process, the operating system scans for system devices and uses the
results to build the HKEY_LOCAL_MACHINE\HARDWARE subkey. The
information stored in this key exists only in memory and isn’t
stored anywhere on disk.
On the other hand, registry data stored on disk is persistent. When you shut down
a system, this registry data remains on disk and is available the
next time you boot the system. Some of this stored information is
very important, especially when it comes to recovering from boot
failure. For example, by using the information stored in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet, you can boot using the
Last Known Good Configuration. If the registry data was corrupted,
however, this information might not be available and the only way to
recover the system is to try repairing the installation or
reinstalling the operating system.
To help safeguard the system and ensure that one section of
bad data doesn’t cause the whole registry to fail to load, Windows Server 2012 has
several built-in redundancies and fail-safe processes. For starters,
the registry isn’t written to a single file. Instead, it
is written to a set of files called hives. There are six main types of hives, each
representing a group of keys and values. Most of the hives are
written to disk in the %SystemRoot%\System32\Config directory.
Within this directory, you’ll find these hive files:
-
DEFAULT, which corresponds to the HKEY_USERS\.DEFAULT
subkey -
DRIVERS, which corresponds to the HKLM\Drivers
subkey -
SAM, which corresponds to the HKEY_LOCAL_MACHINE\SAM
subkey -
SECURITY, which corresponds to the
HKEY_LOCAL_MACHINE\SECURITY subkey -
SOFTWARE, which corresponds to the
HKEY_LOCAL_MACHINE\SOFTWARE subkey -
SYSTEM, which corresponds to the HKEY_LOCAL_MACHINE\SYSTEM
subkey
The remaining hive files are stored in individual user-profile directories with the default name of
Ntuser.dat. These files are, in fact, hive files that
are loaded into the registry and used to set the pointer for the
HKEY_CURRENT_USER root key. When no user is logged on to a system,
the user profile for the default user is loaded into the registry.
When an actual user logs on, this user’s profile is loaded into the
registry.
Note
The root keys not mentioned are HKEY_CURRENT_CONFIG and
HKEY_CLASSES_ROOT. The on-disk data for HKEY_CURRENT_CONFIG comes from the subkey
from which it is built: HKEY_LOCAL_MACHINE
\SYSTEM\CurrentControlSet\Hardware Profiles\Current. Similarly,
the on-disk data for HKEY_CLASSES_ROOT comes from
HKEY_LOCAL_MACHINE \SOFTWARE\Classes and
HKEY_CURRENT_USER\SOFTWARE\Classes.
Every hive file has associated log files—even Ntuser.dat.
Windows Server 2012 uses the log files to help protect the registry
during updates. When a hive file is to be changed, the operating
system writes the change to a log file and stores this log file on
disk. The operating system then uses the change log to write the
changes to the actual hive file. If the operating system were to
crash while a change is being written to a hive file, the change log
could later be used by the operating system to roll back the change,
resetting the hive to its previous configuration.
Types of registry data available
When you work your way down to the lowest level of the
registry, you see the actual value entries. Each value entry has a name, data type, and value associated with it. Although
value entries have a theoretical size limit of 1024 KBs, most value
entries are less than 1 KB in size. In fact, many value entries
contain only a few bits of data. The type of information stored in
these bits depends on the data type of the value entry.
The data types defined include the following:
-
REG_BINARY
Raw binary data without any formatting or
parsing. You can view binary data in several forms, including
standard binary and hexadecimal. In some cases, if you view the
binary data, you will see the hexadecimal values as well as the
text characters these values define. -
REG_DWORD
A binary data type in which 32-bit integer values
are stored as 4-byte-length values in hexadecimal. REG_DWORD is
often used to track values that can be incremented, 4-byte
status codes, or Boolean flags. With Boolean flags, a value of 0
means the flag is off (false) and a value of 1 means the flag is
on (true). -
REG_LINK
A Unicode string specifying a symbolic link to
another registry value. -
REG_NONE
Data without a particular type that is displayed
in Registry Editor in hexadecimal format as a binary
value. -
REG_QWORD
A binary data type in which 64-bit integer values
are stored as 8-byte-length values in hexadecimal. REG_QWORD is
often used to track large values that can be incremented, 8-byte
status codes, or Boolean flags. With Boolean flags, a value of 0
means the flag is off (false) and a value of 1 means the flag is
on (true). -
REG_SZ
A fixed-length string of Unicode characters.
REG_SZ is used to store values that are meant to be read by
users and can include names, descriptions, and so on, as well as
stored file system paths. -
REG_EXPAND_SZ
A variable-length string that can include
environment variables that are to be expanded when the data is
read by the operating system, its components, or services, as
well as installed applications. Environment variables are
enclosed in percentage signs (%) to set them off from other
values in the string. For example, %SystemDrive% refers to the
SystemDrive environment variable. A REG_EXPAND_SZ value that
defines a path to use could include this environment variable,
such as %SystemDrive%\Program Files\Common Files. -
REG_MULTI_SZ
A multiple-parameter string that can be used to
store multiple string values in a single entry. Each value is
separated by a standard delimiter so that the individual values
can be picked out as necessary. -
REG_RESOURCE_LIST
A value that stores a series of nested arrays and
that was designed to store a resource list for hardware device
drivers or a physical device a driver controls. The value is
displayed in Registry Editor in hexadecimal format as a binary
value. -
REG_RESOURCE_REQUIREMENTS_LIST
A value that stores a series of nested arrays and
that was designed to store a list of hardware resources for
device drivers or a physical device a driver controls. The value
is displayed in Registry Editor in hexadecimal format as a
binary value. -
REG_FULL_RESOURCE_DESCRIPTOR
A value with an encoded resource descriptor, such
as a list of resources used by a device driver or a hardware
component. REG_FULL_RESOURCE_DESCRIPTOR values are associated
with hardware components, such as a system’s central processors,
floating-point processors, or multifunction adapters.
The most common data types you’ll see in the registry are REG_SZ and
REG_DWORD. The vast majority of value entries have this data type. The most important
thing to know about these data types is that one is used with
strings of characters and the other is used with binary data that is
normally represented in hexadecimal format. And don’t worry, if you
have to create a value entry—typically, you do so because you are
directed to by a Microsoft Knowledge Base article in an attempt to
resolve an issue—you are usually told which data type to use. Again,
more often than not, this data type is either REG_SZ or
REG_DWORD.
|
