Windows Architecture – Registry 101

When I first started in the IT industry (back in the Windows for Workgroups 3.11 days), one of my team leads told me at least once every other day, “If you ever decide to start editing the registry directly, you’d better be sure you know what you’re doing.”  That may have been one of the most valuable pieces of advice I ever received.  Making changes to the registry is something that should be done carefully, however, it is surprising how many Systems Administrators we work with on a daily basis are so afraid of the registry that it borders on paranoia.  So today, we’re going to start exorcising those demons, and peel away some of the mystique that surrounds the registry …

Let’s get started by explaining what exactly the registry is.  The registry is a hierarchical database that contains the value of variables in Windows and in the applications and services that run on Windows.  During the setup of the Operating System, the Registry is built from template files.  The Operating System and application programs store the following system configuration and user data in the registry:

  • Profiles for each user
  • Installed applications and the file extensions associated with each application
  • Property settings for folders and program icons
  • System Hardware
  • Ports used for I/O Communications

OK, now that you know what it is – let’s talk terminology.  The diagram below shows you the key areas & terms used when talking about the registry.

A registry hive is a set of discrete files.  Each hive contains a key that serves as the root of the tree.  The pathnames of all the hives, with the exception of user profiles are coded into the configuration manager.  OK – so we know that we’re dealing with files – where are they located?  Below is a list of Hive Registry paths and their corresponding file locations:

  • HKEY_LOCAL_MACHINE\SYSTEM: %SystemRoot%\system32\config\SYSTEM
  • HKEY_LOCAL_MACHINE\SAM: %SystemRoot%\system32\config\SAM
  • HKEY_LOCAL_MACHINE\SECURITY: %SystemRoot%\system32\config\SECURITY
  • HKEY_LOCAL_MACHINE\SOFTWARE: %SystemRoot%\system32\config\SOFTWARE
  • HKEY_LOCAL_MACHINE\SYSTEM\Clone: Volatile hive
  • HKEY_USERS\UserProfile: <profiles folder>\NTUSER.DAT
  • HKEY_USERS.DEFAULT: %SystemRoot%\system32\config\DEFAULT

The Configuration Manager creates the root keys, linking the hives together to build the registry structure.  When you launch the Registry Editor, you will see the root keys as shown in the image below:

Now, let’s take a quick look at what each root key contains, beginning with the HKEY_CLASSES_ROOT key (or HKCR for short).  There are two types of information within HKCR – the file extension associations, and COM class registrations.  The data in HKCR comes from two sources.  At the system level, class registration data is stored in HKEY_LOCAL_MACHINE\Software\Classes.  There is also a set of class registration data that is user specific.  This is stored in HKEY_CURRENT_USER\Software\Classes.  Below you can see the default system-wide file extension association for a .doc file, which on my system is associated with Word 2007.  A quick word on registry navigation here – note that at the bottom of the Registry Editor window, the application displays the current location of the key I am examining.  You should always ensure that you are in the proper location before you make any changes!

Let’s move on to the HKEY_USERS & HKEY_CURRENT_USER hives.  HKEY_USERS contains the user-profile hives of logged-on accounts and the root of all user profiles on the computer.  As you can see below, there is a subkey named HKU\.DEFAULT that is linked to the default workstation profile.  There are also subkeys for each loaded user profile and user class registration database on the system.  The HKEY_CURRENT_USER hive contains the user specific information for the user who is logged on.  This is a symbolic link to a key under HKEY_USERS that represents a user’s profile hive. 

OK – quick shortcut / troubleshooting tip here, because this is a question we’ve been asked a few times.  Is there is a way to map the GUID to a username within the registry itself?  The answer is, yes there is!  Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Under this key, you will see all the GUID’s for the various user profiles. The ProfileImagePath value under the appropriate GUID will point you to the user’s profile path – so now you know how to figure out which GUID belongs to which user.

It’s time to talk about HKEY_LOCAL_MACHINE (aka HKLM) which is where most of our system troubleshooting is performed. HKLM contains other keys that are hives and the configuration information particular to the machine. All the system-wide configuration subkeys are contained in HKLM as listed below:


  • HARDWARE – maintains descriptions of the system’s hardware and all hardware device-to-driver mappings.
  • SAM – holds local account and group information.
  • SECURITY – stores system-wide security policies and user-rights assignments.
  • SOFTWARE – stores system-wide configuration information not needed to boot the system.
  • SYSTEM – contains the system-wide configuration information needed to boot the system.

When we troubleshoot issues, we spend quite a bit of time reviewing configuration parameters in the registry.  For example, if you think back to our post on Preparing to Troubleshoot, we talked about capturing a full system memory dump.  Most people know how to find and configure the computer settings to capture a full dump via the Computer Properties GUI below:

The HKLM\System\CurrentControlSet\Control\CrashControl key contains all the settings that are available in the GUI – as shown below:

  • Write an event to the System Log checkbox = LogEvent
  • Automatically Restart checkbox = AutoReboot
  • Write Debugging Information drop-down = CrashDumpEnabled
  • Dump File text box = DumpFile
  • Overwrite any existing file checkbox = Overwrite

So as you can see, the Registry gives us far more granular control and insight into how systems are configured than the traditional GUI interface methods.  Hopefully, our overview of the Registry has helped clear up some of the mystique and apprehension that many administrators feel when confronted with the registry interface for the first time.  Just remember that in most cases, configuring the system with via the GUI interface is the best way to do things because the GUI can protect you from entering invalid information, or accidentally deleting something important – like … the Print Spooler Service!  However, there are times when it will be absolutely necessary to start making changes in the registry, so I leave you with the immortal words of my old team lead, “If you ever decide to start editing the registry directly, you’d better be sure you know what you’re doing.”

Until next time …

 – CC Hameed