Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 198
  • Last Modified:

how does NT handle the registry files?

I know the importance of the registry keys/files to NT operation and all applications loaded.  But just not so sure about the exact way they are handled.

Are they loaded up into the system memory during boot?  Or they are only accessed/loaded into the RAM like most of files when system need to access them.  

Can someone give me a bit details please?

Many thanks in advance.
  • 3
  • 2
1 Solution
Hi Frankf,

The registry is just some files.
These are the files found on the Emergency Repair Disk Created by Windows NT.

Each application read the registry database when they need a registry information.

Some infos may be read or write at application loading or when needed.

It is like the use of .ini files in Windows 3.1
The difference is all these .ini are now in the registry database.


Not true Longbow!


On disk, the Registry isn't simply one large file but a set of discrete files called hives. Each hive contains a Registry tree, which has a key that serves as the root (i.e., starting point) of the tree. Subkeys and their values reside beneath the root. You might think that NT stores each root key you see when you run one of the Registry editors (regedit or regedt32) in a separate hive, but such is not the case. In fact, none of the root keys correlate to hives, and the regedit names don't have extensions. The absence of corresponding files signifies that logical root keys are objects with no on-disk representation. The Configuration Manager creates the root keys, linking hives together to build the Registry structure you are familiar with and that regedit displays.

When you take a good look at the Win2000 registry, you'll find that some hives are volatile and don't have associated files. The system creates and manages these hives entirely in memory; the hives are therefore temporary in nature. The system creates volatile hives every time the system boots. An example of a volatile hive is the HKEY_LOCAL_MACHINE\HARDWARE hive, which stores information regarding physical devices and the devices' assigned resources. Resource assignment and hardware detection occur every time the system boots, so not storing this data on disk is logical.

The heart of the Registry is the HKEY_LOCAL_MACHINE\SYSTEM hive. In particular, this hive's subkey \CurrentControlSet\Control contains settings that the Configuration Manager uses to initialize the Registry. When the Configuration Manager is initializing hives and needs to locate the hives' files, the Configuration Manager refers to the value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist.

A special type of key known as a symbolic link makes it possible for the Configuration Manager to link hives to organize the Registry. A symbolic link is a key that redirects the Configuration Manager to another key. Thus, the key HKEY_LOCAL_MACHINE\SAM is a symbolic link to the key at the root of the SAM hive.

Hive structure is important to just how well Windows 2000 operates. The Configuration Manager logically divides a hive into allocation units called blocks in much the same way that a file system divides a disk into clusters. By definition, the Registry block size is 4096 bytes (4KB). When new data expands a hive, the hive always expands in block-granular increments. The first block of a hive is the base block. The base block includes global information about the hive, including a signature?regf?that identifies the file as a hive, updated sequence numbers, a timestamp that shows the last time a write operation initiated on the hive, the hive format version number, a checksum, and the hive file's full name (e.g., SystemRoot\CONFIG\SAM).
The hive format version number specifies the data format within the hive. Hive formats changed from NT 3.51 to NT 4.0, so if you try to load an NT 4.0 hive in earlier NT versions, you'll fail.

NT organizes the Registry data that a hive stores in containers called cells. A cell can hold a key, a value, a security descriptor, a list of subkeys, or a list of key values. A field at the beginning of a cell's data describes the data's type. Table 3 describes each cell data type in more detail. A cell's header is a field that specifies the cell's size. When a cell joins a hive and the hive must expand to contain the cell, the system creates an allocation unit called a bin. A bin is the size of the new cell rounded up to the next block boundary. The system considers any space between the end of the cell and the end of the bin free space that it can allocate to other cells. Bins also have headers that contain a signature, hbin, and a field that records the offset into the hive file of the bin and the bin's size.

By using bins, instead of cells, to track active parts of the Registry, NT minimizes some management chores. For example, the system usually allocates and deallocates bins less frequently than it does cells, which lets the Configuration Manager manage memory more efficiently. When the Configuration Manager reads a Registry hive into memory, it can choose to read only bins that contain cells (i.e., active bins) and to ignore empty bins. When the system adds and deletes cells in a hive, the hive can contain empty bins interspersed with active bins. This situation is similar to disk fragmentation, which occurs when the system creates and deletes files on the disk. When a bin becomes empty, the Configuration Manager joins to the empty bin any adjacent empty bins to form as large a contiguous empty bin as possible. The Configuration Manager also joins adjacent deleted cells to form larger free cells.

The links that create the structure of a hive are cell indexes. A cell index is the offset into the hive file of a cell. Thus, a cell index is like a pointer from one cell to another cell that the Configuration Manager interprets relative to the start of a hive. For example, a cell that describes a key contains a field specifying the cell index of its parent key; a cell index for a subkey specifies the cell that describes the subkeys that are subordinate to the specified subkey. A subkey-list cell contains a list of cell indexes that refer to the subkey's key cells. Therefore, if you want to locate the key cell of a subkey that belongs to a particular key, you must first locate the cell containing the key's subkey list using the subkey-list cell index in the key's cell. Then, you locate each subkey cell using the list of cell indexes in the subkey-list cell. For each subkey cell, you check to see whether the subkey's name, which a key cell stores, matches the one you want to locate.

The distinction between cells, bins, and blocks can be confusing, so let me give you an example of a simple Registry hive layout. Let's take a sample that contains a base block and two bins. The first bin is empty, and the second bin contains several cells. Logically, the hive has only two keys: the root key Root, and a subkey of Root, Sub Key. Root has two values, Val 1 and Val 2. A subkey-list cell locates the root key's subkey, and a value-list cell locates the root key's values. The free spaces in the second bin are empty cells.

The Configuration Manager doesn't access a hive's image on disk every time a Registry access occurs. Instead, NT keeps a version of every hive in the kernel's address space. When a hive initializes, the Configuration Manager determines the size of the hive file, allocates enough memory from the kernel's paged pool to store the hive file, and reads the hive file into memory. The paged pool is a portion of the kernel's address map that NT reserves for device drivers and the kernel to use. NT can move any memory the system allocates from the paged pool to a paging file when the memory isn't in use. If hives never grew, the Configuration Manager could perform all its Registry management on the in-memory version of a hive as if the hive were a file. Given a cell index, the Configuration Manager could calculate the location in memory of a cell simply by adding the cell index, which is a hive file offset, to the base of the in-memory hive image.

**Early in the system boot, this process is exactly what Ntldr does with the SYSTEM hive: Ntldr reads the entire SYSTEM hive into memory as a read-only hive and adds the cell indexes to the base of the in-memory hive image to locate cells.**

Unfortunately, hives grow as they take on new keys and values, which means the system must allocate paged pool memory to store the new bins that contain added keys and values. Thus, the paged pool that keeps the Registry data in memory isn't necessarily contiguous. To deal with noncontiguous memory buffers storing hive data in memory, the Configuration Manager adopts a strategy similar to what NT's Memory Manager uses to map virtual memory addresses to physical memory addresses. The Configuration Manager employs a two-level scheme, that takes as input a cell index (i.e., a hive file offset) and returns as output both the address in memory of the block the cell index resides in and the address in memory of the bin the cell resides in. Remember that a bin can contain one or more blocks and that hives grow in bins, so NT always represents a bin with a contiguous memory buffer. Therefore, all blocks within a bin occur within the same portion of a paged pool.

To implement the mapping, the Configuration Manager divides a cell index logically into fields, in the same way that the Memory Manager divides a virtual address into fields. NT interprets a cell index's first field as an index into a hive's cell map directory. The cell map directory contains 1024 entries, each of which refers to a cell map table that contains 512 map entries. The second field in the cell index specifies the entry in the cell map table that the first index field identified. That entry locates the bin and block memory addresses of the cell. In the final step of the translation process, the Configuration Manager interprets the last field of the cell as an offset into the identified block to precisely locate a cell in memory. When a hive initializes, the Configuration Manager dynamically creates the mapping tables, designating a map entry for each block in the hive, and adds and deletes tables from the cell directory as the changing size of the hive requires.

Keep in mind that none of this allows for namespace issues and API calls, which, like the hives, is loaded at boot.


>the files

That's mean more than only one file.
Sorry if my english is so bad.


Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

Hi Frankf,

Here you will find many infos about the registry.
These are well explained. The better place about the registry.


frankfAuthor Commented:
Thanks very much
Anytime Frank!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now