Deeper into the Windows Registry


The Windows registry is doubly obscure as it is both unknown to most of us and hard to understand. This is as it should be. The registry is a fundamental part of the Windows Kernel and its operations are relatively complex. If Windows is working properly then we, as users, should never see the Registry or any of its components. This article is not written for registry beginners, nor those wanting to edit the registry. Instead it provides a deeper understanding of the organization and management of the registry.

This article is work in progress so don't rely on it being completely correct. The format of some sections is likely to dramatically change to clarify and simplify the content. There will also be further work added to bring it up to Windows 8. I am publishing it now to give people the opportunity to ask questions and suggest improvements.


What is the Windows Registry?

The complete registry only exists in memory

The registry is commonly described as a hierarchical database. But you may not have realized two important facts:

  1. The registry database is only ever complete when loaded into your computer's memory.
  2. The registry is the sum of two parts, the data and the processes that create it and provide access to it.
Diagram 1 - Windows assembles the registry in memory
Some in-memory Registry hives do not have on-disk hive files

In other words, the registry hive files stored on your disk are not the complete registry. The complete registry is created during the startup process and assembled in memory.

This is so important so I'll repeat it. At the heart of the registry is a database that exists in two main forms:

  • Some registry hives are stored on disk even when Windows is not running.
  • All the registry hive structures only exist in memory. This includes a set of volatile hives that only exist when Windows is running.

The registry can only be accessed  through the Registry Configuration Manager

The other Windows components that allow the registry data to be accessed are in the Windows kernel. The Registry Configuration Manager is the most dedicated but other kernel components like the Object Manager provide further essential capabilities. These are discussed in more detail in How is the registry managed? but here's a preview so you can picture it.

Diagram 2 - Windows kernel components provide access to the registry

Windows Configuration Manager manages changes to the Registry

What this means is that when your computer is turned off the registry does not exist even though most of the registry data is stored on disk.

The beehive references started as a joke

In reading about the registry you may have noticed the references to hives, bees and cells. They are a long running joke. Apparently, one of the developers hated bees and another developer took the opportunity to introduce many references to bees. It is also relevant that the registry database is indexed using binary trees or B-trees (pronounced "Bee-trees"). That's why the primary database structures are called hives.

You can see registry database structure by running the registry editor, RegEdit. It shows one hierarchical tree but the Windows registry is not one big database file. The primary data structure is the hive of which there are several. Each hive is indentified by a root key which provides access to all sub-keys in the tree up to 512 levels deep.

Each hive has a root key

There are six pre-defined root keys which are used to access all other keys or sub-keys. In other words, the binary tree is traversed from the root downwards. So new keys are added through these root keys and all existing keys have to be found through the root keys. One disadvantage of this approach is that a problem with a higher key may prevent access to lower keys. In practice this does not occur very often.

The following table lists the root keys with the abbreviations that will be used in the remainder of this article.

Table 1 - Registry root keys
Root Key
Root Key Name Component data is stored for
HKCR HKEY_CLASSES_ROOT Classes (types) of documents and registered applications
HKCU HKEY_CURRENT_USER Current logged-on user
HKLM HKEY_LOCAL_MACHINE The system hardware, software and security
HKU HKEY_USERS User profiles

Registry HKEYS are handle keys used to access the registry objects

As shown in Diagram 2, programs gain access to the registry by using the Registry Application Programming Interface (API) which provides a standard set of functions for the Windows sub-systems and application programs to access and update the Registry. This is how the Registry editor (RegEdit) and other utilities work. When a program uses the API to access the registry the Windows Object Manager will return a handle for the object identified by a key. That is why the "HKEY" in the root keys means "handle key".

Although the handles are valid in any registry they can be used differently in different versions of Windows. Also, some registry handles are not provided from the registry hives. HKPD, for example, is diverted by the API to the Windows performance management sub-systems. That is why you cannot find HKEY_PERFORMANCE_DATA when you use the Registry editor.

The registry structure is like a file storage structure

You may find it easier to relate to the registry terminology by referring to tree formats or file storage. The analogy of files is particularly apt because Windows used to be configured from .INI files. More particularly, the keys themselves use file-naming conventions. This is a handy feature because Windows can manage registry objects just like file objects. Registry hives have symbolic links which are like virtual paths mappings in file system. Registry subkeys also have owners and permissions just like directories and folders.

Table 2 - Relating to Registry terminology
Registry Other trees File storage
Hive Tree File-system
Key Node Directory or folder
Subkey Subnode Subdirectory or subfolder
Value Key File
Type Type File type
Data Value File content

Note that a key can contain subkeys or values. A subkey can have another subkey so key and subkey are usually interchangeable in the same way as directory and subdirectory or folder and subfolder. A key with no value can still store data in what is called the default value.

You might have noticed that I haven't explained what cells are here.  I mentioned them when discussing hives and bees. The reason that they aren't here is that cells are part of the in-memory structure for the hives and are not visible anywhere outside the kernel. They will only be explained if I add a section on the internal workings of the Registry Configuration Manager.

The registry is kernel-based for speed

The registry is an integral part of Windows so it is based in the Windows kernel for the best performance and access to the most important components of Windows.

The registry is designed to save space

The registry stores configuration settings in a hierarchy to minimise the size of the registry. System-wide settings are used first then the user settings are added on top. This means that the user settings only have to store those settings that differ from the default. The user settings then supercede the equivalent system-wide settings.

The same applies for programs and hardware. Programs normally have settings for the system, e.g. installed components, and settings for each user, e.g. recently-opened files. Likewise multiple hardware profiles can be used.

Another advantage of only storing differences from the system or default settings is that different users can easily use the same computer with the same system configuration. They only need the settings in their profile to customize the system to suit them.

The minimized size of the user settings also makes it easier to transmit those settings when you are roaming and log onto a different computer on the same local area network (LAN) or wide area network (WAN).

Diagram 3 - User settings override system-wide settings

Specific differences


User-specific differences
e.g. HKCU\User SID
System-specific difference
e.g. HKCU\Software\Classes



User defaults
e.g. HKU\.default
System-wide defaults
e.g. HKLM\Software\Classes


Diagram 3 is oversimplified. Just remember that the differences usually override the defaul settings. An example of system-wide default is the user profile defaults found in HKU\.default which are superceded by per user settings in HKCU\user account SID.

Some of the registry complexity is to maintain backward compatibility

Originally Windows 3.1 only had the REG.DAT file. Windows 95 to ME and NT had the SYSTEM.DAT and USER.DAT. Every major release of Windows introduces further complexity to the files and the internal structure. So some hives are retained purely for backwards compatibility. This leaves us with three main categories of hive:

  • Windows 9x (and 3.1) software classes to maintain compatibility with 16-bit applications, OLE and the Component Object Model (COM) for developing applications.
  • Windows 2000 has Standard hives which are maintained to alllow users to roam with a standard configuration. Windows 2000 largely moved to the current registry files.
  • Windows latest versions.

Further complicating this are other major changes:

  • The emulation of Windows 32-bit on Windows 64 (WOW64) to allow 32-bit and 64-bit registry entries to coexist in the registry
  • The introduction of the .NET Framework and web-based software which is superceding the old COM framework.


What activities change the Windows Registry?

Windows installs and upgrades

Windows setup copies a prototype version of the Registry from the install media.

Diagram 4 - Setup uses a prototype registry to setup Windows

Windows setup copies prototype Registry hive files

OEM versions of Windows can have a customized prototype which can invalidate standard recovery methods if a Windows install fails. This was an issue with Windows XP but I'm unsure if it still applies given the registry improvements in Vista.

If you have an option to upgrade then Windows installs the new registry formats and then copies or converts the existing keys as appropriate.

Diagram 5 - Windows upgrades merge the existing registry hives into the prototype

Windows upgrade installs new Registry hive files and updates from the existing

The Custom install option is an indirect upgrade because your data is copied out to another disk and then applied after the new install.

Windows startup

The Windows startup sequence is quite complex so it is discussed separately in How does Windows startup use the registry?.

The first steps of startup are designed to determine the configuration needed to load Windows. But initially the Windows Kernel and the registry are not loaded. So the Boot Configuration Data (BCD) is loaded from its file. Once the Windows Loader is started then the hardware abstraction layer and the kernel image are loaded before the Registry API is available. The System hive is loaded into physical memory to determine the relevant control set to be used to configure Windows properly. The registry is then assembled and from that point further startup processes are accessing the registry and making changes. These changes are made whether there are any further changes to the computer configuration or any problems that may develop.

User logon

When a user logs on, Windows loads hives that are specific to that user. These contain settings that differ from the defaults. How does Windows startup use the registry? also provides further details for this.

Device driver changes

When we install (or uninstall) drivers this changes the registry. We may not even notice this happening because new hardware is normally recognized automatically by Plug and Play so the correct drivers can be loaded without our intervention.

Applications changes

Installing or uninstalling applications is a major source of changes after the initial install of Windows. This almost always involves user intervention.

User interaction primarily with programs

We also have interactions with our application programs and Windows components. These programs modify the registry in many ways and the changes can be to system-wide settings as well as user-specific settings.

Diagram 6 - The registry is changed by driver and application changes or simply using a program

The registry is updated for hardware and software changes and simply using a program


How is the Registry stored on disk?

The Registry files are stored in several locations

The following table lists all the Windows directories where Registry data files can be found. The files are effectively snapshots of most but not all of the Registry hives. Table 3 summarises the main file locations. If you look on your disk, you will see that there are further sub-directories in each of these directories.

Table 3 - Registry hive file locations
File Location Example file location File name Description
%UserProfile% C:\Users\Username\ NTUser.dat User profile configuration
%SystemRoot%\System32\Config\ C:\Windows\System32\Config\ Components
System configuration





NTUser.dat User profile configurations used by Windows
BCD Boot Configuration Data
  Transaction Registry files can be found in the main registry hive folders.


There are several types of Registry file

The primary registry files usually have no file extension (except for NTUser.dat) but there are other files that do. They attach the extension to the entire filename including the original extension. Table 4 indicates most of those file types.

Table 4 - Other files
File Extension Example filenames Purpose
none System
Hive backup created by the Configuration Manager
ALT System.alt Backup for the System key created by the Configuration Manager
BLF NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}.TM.blf TxR transaction files1
LOG, LOGn System.log, System.log1, etc
NTUser.dat.log, NTUser.dat.log1, etc
Transaction log of the key and value changes created by the Configuration Manager
REGTRANS-MS NTUSER.DAT{016888bd-6c6f-11de-8d1d-001e0bcde3ec}
TxR transaction files1
REG no standard names REGistration entry files are created by RegEdit and other programs
SAV System.sav WIndows Vista and 7 initial SYSTEM install file. Windows 2000, XP, 2003 backup copy of the system configuration at the end the text-mode startup before the graphic-mode startup began. If graphics-mode fails the restart loads the .sav file to skip text-mode.

1 Since Vista, the Transactional Registry (TxR) performs transactional updates that are managed by the Windows kernel-mode Transaction Manager (TM). This provides for atomic transactions where all updates are made together or not at all. The Transaction Manager uses the Common Logging File System and stores registry files in the %SystemRoot%\System32\Config\ (e.g. C:\Windows\System32\Config\) folder and the Txr subfolder as well as the other registry folders.


How is the registry stored in memory?

In-memory Registry hives

The registry hives in memory have the same data as the hive file data structures. However the data structure and indexing are different. As I said earlier, these hives form the complete registry because some hives do not exist on disk.

The hives for each user account utilise the Security ID (SID) as the unique identifier. Such variable key names are indicated in italics in Table 5. The list of profiles is stored in HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Profilelist.

Table 5 - Registry hives
Hive key Format Links Hive description
HKCC volatile
Symbolic for 9x Current hardware profile which only includes the differences from the standard configurations.
HKCC is a symbolic key to the current hardware profile under HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles.
HKCR volatile
Symbolic for 3.1 Primarily for backward compatibility with 16-bit Windows, ie back to Windows 3.1. Stores types (or classes) of documents and registered applications.
HKCR is a symbolic key to HKLM\SOFTWARE \Classes (the default settings) and HKCU\Software\Classes (settings for the current user which takes priority over the default settings), combining them into one view.
HKCU\User account SID 2000 standard Symbolic for 9x The preferences of the current (logged-in) user.
This configuration is designed to roam with the user.
HKLM\BCD00000000     Since Vista, Boot Configuration Data for which there is not a hive.
NB: Use BCDedit.exe and not RegEdit.exe to edit the BCD.
HKLM\Hardware volatile   Hardware data created during the boot/startup process.
HKLM\SAM 2000 standard   SAM=Security Accounts Manager.
This is usually empty unless you've been authorized to access another system. Then it will be linked to another SAM database.
HKLM\Security 2000 standard   This is usually empty unless you've been authorized to access another system. Then it will be linked to other security policies.
HKLM\Software     The largest part of the registry. Software settings updated by applications. Primarily set by the software applications apart from Windows settings.
HKLM\System     System configuration
HKU\.Default 2000 standard   Defaults for all user accounts on the computer.
User accounts only store the differences from this profile.
If group policies are set then this is copied to HKCU
HKU\User account SID     User accounts
HKU\User account SID_Classes     Classes for the user account
HKU\Local Service account SID     Pre-defined account used by Windows to run services on your PC with minimum privileges. Used for example if a login process is not found.
Unused since Vista.
HKU\Network Service account SID     Pre-defined account used by Windows to run services on your PC with minimum privileges. Used for example if a login process is not found.
Unused since Vista.

You might have noticed that HKLM does not appear by itself in Table 5 above. That is because it is a placeholder with no corresponding physical hive. HKLM is the same for every user on the computer. But it does contain the keys for the other hives that make up the computer configuration.

Differences between the hives

Apart from the obvious differences in configuration data, there are three main differences between the various Registry hives:

  • Some are symbolic links (also called aliases and clones) that point to other hives.
  • Some are volatile and are not permanently stored on disk.
  • Some retain compatibility with earlier versions of Windows, e.g. the Standard hives that remain unchanged since Windows 2000.

Symbolic keys

Symbolic keys are also called alias or clone links. They redirect the Registry Configuration Manager to another key. In other words they provide a different view of the same data. They function in a similar manner to Windows shortcuts. Any changes to the real keys are cloned to the symbolic keys but not vice versa. This also means that they are not copies.

For example, HKCR is a symbolic link to HKLM\SOFTWARE \Classes (the default settings) and HKCU\Software\Classes (settings for the current user), combining them into one view. Any data contained in HKCU overrides any data contained in HKLM. Therefore any change in HKCR is always "cloned" into HKCU.

Volatile hives

The volatile hives are either created from different information or are different views of information contained in the Registry files:

  • HKCR is a symbolic key to HKLM\SOFTWARE \Classes (the default settings) and HKCU\Software\Classes (settings for the current user which takes priority over the default settings), combining them into one view.
  • HKCC is a symbolic key to the current hardware profile under HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles.
  • HKLM\Hardware is created at startup.

Standard versus Latest hive formats

Latest hives have the most up-to-date format whereas Standard hives retain a format that is compatible with Windows 2000. That means in a mixed Windows computing environment the settings can be used on computers running different versions of Windows and users can roam all those computers.

The Standard hives that remain compatible with Windows 2000 are:

  • HKCU
  • HKLM\Security

Normally HKLM\SAM and HKLM\Security are empty unless a user is authorised to use another computer.


How is the Registry managed?

The kernel-mode Configuration Manager manages the registry

The kernel-mode Configuration Manager is the primary component of the Windows Kernel Image that manages the Registry. It works with several Kernel components such as the Object Manager which handles resource management for Kernel subsystems and the Transaction Manager which ensures transactions are completed or reversed if they partially complete.

The Object Manager integrates Registry hive keys into the Kernel namespace. As I said earlier, Registry keys use Windows file-naming conventions. The Object Manager knows that a name beginning with "Registry" should be handed to the Configuration Manager.

The Configuration Manager manages changes to the Registry Hive

When handed an object by the Object Manager, the Configuration Manager searches the hive tree for the key.

The example in Diagram 6 indicates the two forms of the registry keys. The Regedit and API form = HKLM\SYSTEM\CurrentControlSet is translated by Win32 or Win64 to the object namespace form = \Registry\Machine\System\ CurrentControlSet then passed onto the Configuration Manager as \Machine\System\ CurrentControlSet.

Diagram 6 - The Registry Configuration Manager manages access to and changes of the registry hives 

Windows Configuration Manager manages changes to the Registry


The Configuration Manager writes non-volatile hive changes to the hive files

The Transaction Manager, as mentioned already, handles atomic updates of the Registry hive files ensuring that related changes are completed together or rolled-back together if there is an error. You will notice that I have left the Transaction Manager out of the following diagram to keep it simple with the emphasis on the Configuration Manager managing the changes. There is also a registry cache for writes to disk. Writes to hives in memory are made immediately whereas writes to the disk files are grouped together and written in batches.

Diagram 7 - The Registry Configuration Manager manages changes of the registry hives 

Configuration Manager manages changes to the Registry hives and the hive files



How does Windows startup use the registry?

A quick overview

When you boot your computer and start Windows there are several processes that involve the registry. I've summarized them in this diagram. The main points are that:

  • A BCD hive is created in memory but it is not loaded from the hive files. Instead the BCD is loaded from the BCD files stored on disk.
  • The SYSTEM hive is usually a smallish hive because it has to fit into about half the available physical memory during startup. The WIndows Boot Manager temporarily loads the SYSTEM hive into physical memory so Windows can startup before loading the Kernel Image. The Kernel  includes the remaining registry components and supporting systems including virtual memory and the Registry API which are used to load the rest of the hives.
  • Windows Logon also loads user hives. For example, HKCU is loaded when logon is succesful. NB This diagram will be updated to reflect that during a later update.
Diagram 8 - Windows startup processes use the registry

Windows startup reads and loads the Registry hives


More detail on Windows startup steps

I have removed the table containing the startup sequence and how it relates to the registry. I am preparing a separate article on the Windows startup sequence which this article will link to.


Answers to some other common questions

What is the maximum size of a registry element?

It is interesting that a registry value can store up to 1MB but a separate file is recommended if it is more than 1 or 2 KB.


What is the maximum size of a registry hive?

The original Windows 3.1 registry was a single-node flat file REG.DAT. The System registry hive was introduced for Windows 95.

Table 7 - Registry size limits
Windows Version Registry size System registry size
Windows 3.1 16KB na
Windows 9x    
Windows ME 16MB  
Windows NT 4 ~154MB  
Windows 2000 ~296MB
~ 80% of the paged pool
Windows XP ~376MB
~ 80% of the paged pool
Windows Vista, 7,  8 2GB
~ half physical memory1
~75% of the paged pool
400MB x86
1.5GB x64
~ half physical memory

1 The System hive has a maximum size of half physical memory because it is loaded during startup before the paging file is available.


How much of the Registry can be loaded into memory?

Normally the entire registry should be loaded into memory. If it is not then it will be paged to disk and your PC will run noticeably slower.


Related Links
Microsoft articles


Please rate this article: 

Your rating: None
Average: 4.8 (44 votes)


As discussed earlier, the article on Windows 7 Startup is up. There is more detail and an overview diagram to come but I will be updating this registry article first. Remah - Editor
I've actually completed a few diagrams on Windows startup before getting back to this article. See: Windows 7 Components for Startup for diagrams on kernel mode and user mode. Another diagram on support processes (sessions, logon, etc) is coming soon. Windows 7 Startup for the startup overview flowchart Remah - Editor

I'm looking forward to seeing that chart. Transposing a page size to a chart size also sounds appealing. Chart board is 3x3 or so and maybe with a big picture I can wrap my head around how the registry works.
You're doing the whole world a service! I know there will be many people appreciative of your efforts when they see something they can understand. I've been in a fog about the registry since Win3.1. Never got Win3.0 to run and the only help I got with that was "don't mess with the registry"
Maybe there's an end in sight?
Thanks again!

In case anyone is looking for it: the detailed table on the Windows boot sequence has been removed so it can be reworked for a separate article on Windows start-up.

As 2 others have said, i 3rd the sentiment that i wish i had read this 10 years ago. I've learned a lot (but not all) of this in dribs and drabs as necessary and whilst spending many hours up close and personal with Google (well, before DuckDuckGo arrived ;)

This article will just solidify Gizmo's as THE destination to take care of your computer.

On "What changes the registry" i would like to suggest that you mention that windows and programs change the registry on their own accord quite without user interaction. Sometimes they just write it regularly to keep track of state. And so many programs these days install with auto-start services, or system tray widgets and run constantly, or task scheduler entries that run regularly, and/or include auto-updaters that are always "phoning home" to check for updates (and tell developers something about you). Some of this always-on, behind-the-scenes activity writes the registry.

A program like RegShot demonstrates this (which is why you can't use it blindly to undo registry changes).

I would like to suggest mentioning the phenomena that often when you go into a program's "options" "settings" or "preferences" and change stuff, the program turns right around and changes particular registry setting. You can view this with RegShot also (ignoring the other churn-changes). Windows too.

When thinking about organizing, i have a view of this as a technician. I am interested in things like the API that programs use to access the registry, but to me that is academic, cuz i rarely if ever need to know that specifically to solve a problem. OTOH, how the registry is organized, which are files and which are in-memory only, and which alias write back and which dont, the boot order, etc, are all facts i need to know to solve problems. And A LOT of readers here are technicians, professional or amateur. I'm not sure what to do with this, but i suspect keeping it in mind might inform organization decisions.

I will add that it flowed very nicely for me as is.

I am very interested in these two of your planned updates:

- registry filtering/polling to check what is being done in parts of the registry e.g. by antivirus programs. How this affects performance.

- registry virtualization ie where changes to read-only areas are redirected so that they can still be made. This provides backward compatibility and is used by 32-bit emulation in 64-bit Windows.

And more in general about 32bit vs 64bit changes to the registry.

Do you think that the registry's use of therm "value" is counterintuitive? Just looking at your table comparing to trees and filesystems seems to confirm my suspicion that it is. It certainly has confused me.

I had to read the 2nd paragraph under "symbolic keys" several times. HKCU\Software\Classes *overrides* HKLM\SOFTWARE\Classes. It would have helped me to read this explicitly stated here (even tho you state it elsewhere and i already knew it).

You stated that when you update via HKCR the HKCU changes. Is this true even if HKCU does not currently contain that key/value? Ie if we're using the default in HKLM? Meaning in that case a new key/value is *added* to HKCU? Also, will this "cloned" value get written to NTUser.dat? And will it in both cases: a previously existing HKCU key/value and a new one added using regedit?

Also, to complicate matters even further, isn't HKCU itself an alias for HKU/sid

In fact, now that i think about it, you say "HKCU/sid" in some places, and i think you mean either just HKCU or HKU/sid, right?

typo: "progile"

typo: i think you have asynchronously and synchronously backwards.

So, again, first-rate article. Gizmo's lucky to have you.

johnvk, Thanks again for your input. I've been thinking about what you said and it has led to two decisions: 1. I've decided to create an article on Windows boot sequence that doesn't just focus on the registry. The main reason for doing this is to include information on diagnostics procedures and useful references. They both fall outside of the scope of this registry article. 2. This article needs to more clearly indicate how the various hives relate. To that end I need to change the tables and introduce some different diagrams.

I think you're on to something!
Over 20 years ago, when Win3.1 and AOL were cutting edge I was using a dial-up modem that came with some software that included a list of audio files of the numbers. I played with that list trying, using DOS, to associate the numbers with the boot sequence. I envisioned myself sitting coolly with a cup of coffee while the boot counted down on that old 286.
Not being very smart the idea fizzled but I still think it's a good idea. If not in audio your diagrams could easily serve the same purpose.
If you knew, for instance, that your boot was hanging at Step #18, troubleshooting the hang might be a little easier???
Go for it... great idea!

Remah, I agree with Cuffy, i think an article on the boot sequence would be really useful! You're right, they're two distinct ideas (registry, and boot sequence), altho they overlap in several places. And it would help debug such problems.

And thanks for the work on hive interactions. Yeah, it's not trivial, and confusing for newbies. Your diagram will speed their introduction. For example, in RegScanner (from the Rev. Nirsoft) i only select HKEY_LOCAL_MACHINE and HKEY_USERS under "Scan the following base keys" because i believe all the others are aliases (HKEY_CURRENT_USER, HKEY_CLASSES_ROOT, HKEY_CURRENT_CONFIFG, am i right?)

I treat registry editing like i treat my circular saw: useful but one false move and i could destroy something i need.

Thanks again.

I'm in the middle of drafting a new table and a new diagram that indicate more clearly the relationships between the files, hives and keys. Hopefully it will make it easier to picture those hives that are not stored to disk. But the table will be complex because it merges information which is normally displayed in at least three or four separate tables. Yes, HKCU and HKCC are symbolic links and HKCR is a virtualized or merged view of subkeys in other hives, HKCU and HKLM. HKCR and HKCC hives are only assembled while Windows is running, ie runtime, and are not stored to disk, ie volatile.

Thanks for the feedback - that is helpful to me.

Thanks also for pointing out errors and confusing bits. Most issues arise from the incomplete nature of the article and the need for further editing - it would be a beta version if it were a program. I wrote the first draft a couple of years ago and never found the time to finish it. So this time I quickly tidied up what was there and published it even though I know there's errors in it.

Just on your question about the use of the term "value", it is widely agreed that the terminology is confusing and the link from "registry terminology" takes you to a blog post ( that explains why it is too difficult to fix. [Edited for clarity]

Thanks so much for all the detail.

This is one heck of a lot of information. I will save it to view and review many times in the future.

Thanks so much for all this work.

Thanks for the compliment. There's a lot more info coming in later updates.

Great article with plenty of room for expansion!

I would like to see a block diagram, like with Visio maybe, of the entire registry structure, showing where the diagrams you are using fit into the big picture. Your diagram 8. for instance, detailing startup activities, would be displayed in the big picture as STARTUP with links to other activities as applicable.
Even with a one or two word title in a small box I'm sure a big picture diagram would be huge and would take time and talent!
Perhaps a project for a weekend when there's no one else around and you could swear freely when you discover you have wandered off in the wrong direction with your drawing? just a thought!
Thanks, you're doing a fine piece of work.

Most of the diagrams illustrate changing states for Windows itself: startup, install, upgrade. I might provide an overall block diagram for the normal operation once I've completed more of the smaller diagrams for the kernel sub-systems like the Transaction Manager and Configuration Manager.

Great article. I wish you had written this ten years ago. The registry is one of the reasons I converted to Linux.

Sorry, but that's just bizarre. You mean you would have stuck with Windows if they instead used 1000s of ini files instead of the vastly superior hierarchical database that is the registry??

That would really be painful.

Good looking article Remah, I'm one of those who has learnt bits and bobs about the registry through trial and error and experimentation, miscellaneous reading etc.

This looks to be something I will need to read several times ... I think it will help me to organise and better understand what I know already and fill in a lot of gaps for me too.

Thank you.

Let me know what is easy or hard to understand. As people ask questions I'll get a clearer idea how the article should be restructured. Here's a list of what is yet to be done: - reformat the startup steps and correct a few errors I've noticed including in the startup diagram. - provide more diagrams and clearer examples how system-wide defaults are superceded by user settings. The menus are a good place to start. - add more specific detail on what changes the registry. E.g. which keys are created by application and driver registration - add more detail and diagrams on the work of the Configuration Manager and the internal operation of the registry hives. Look at the issues like the impact of empty space in the memory structures - discuss issues arising from memory management and add another diagram or two e.g. explain the memory pools; why is registry size limited by memory? - registry filtering/polling to check what is being done in parts of the registry e.g. by antivirus programs. How this affects performance. - registry virtualization ie where changes to read-only areas are redirected so that they can still be made. This provides backward compatibility and is used by 32-bit emulation in 64-bit Windows. - I need to have a look at Windows 8 and see what has changed.
The final format of this article is yet to be decided so if you have any suggestions then let me know. It goes deeper into the registry than most articles aimed at users. Remah - Editor
Thanks, let me get myself some free time to read the article :)