When mentioning the registry, one thing comes to mind – fear.
Seriously! There seems to be a widespread thing about non-GUI components of the system. Even Microsoft advocates it.
“Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.”
What is it with this notion?!? Is 2012 going to be ascertained if we modified the registry?
Another example of mob psychology. An idea is proposed. It spreads like sneezers. Everyone gets infected.
That being said, the registry doesn’t get its notorious reputation without a solid cause. Two factors have contributed to this, namely:
- It’s the target of attack for viruses.
- It’s extremely delicate. (i.e. instruction to repair the registry are not followed. The next bit? Crash. End of that episode.)
Today, I really want to help clear its calumniations, through demystifying the registry in simple terms.
So, let’s get started.
First of all, what is the registry?
To put it simply, it’s a huge database. A database with a repository of values that Windows keeps to help configure applications and hardware.
‘whaaaattt….??’
It’s kinda like a custom record log kept up to date about your PC for your PC. It’s custom because everyone uses their PCs in a different way, so you’ll be hard pressed to find two completely congruent registries. And it’s kept up to date according to how you use it. So if you’ve just changed your desktop background, the next time it starts, it’ll load that background. So it houses values that are actively used in software programs and also by hardware.
That’s all!
So what’s the fuss about registries?
It’s usually okay when you leave it alone. But people get smart (who want to look smart) and try to tamper with it without knowing what they’re dealing with. Then you’re calling a disaster.
You see, there’s a widespread notion about tweaking PC performance online. One of the most popular (really, available) methods out there involves tweaking (euphemism for ‘messing with’) the registry. And when Windows updates your system, and you implement an outdated tip, irregular things start happening, depending on the key you change.
Caveat: If you want to deal with the registry, get educated about it, and you can go about fiddling with it.
Today, we’re going to have a look at the structure of the registry. And give some examples pertaining to that, and the next time (yes, this ain’t gonna be a one time thing – too long!), we’ll have a look at how to modify it and backup/restore.
Here’s a screenshot of the registry:
Now, the registry is what we’d call a flat database. To put that into perspective, if a database isn’t flat, it’s relational. That means there are commonalities between sets of data. So, for instance, a database for a movie club might have customers in both the rentals and the customers tables (a database is made up of tables primarily). The customer is a relationship to both databases.
A flat database has none. So, in other words, it’s just a table, sure, a really large one, but a table with rows and columns of data.
The Windows Registry is also hierarchical. So, you can imagine a tree of values and data, where the top level is the registry, the second level are parent branches, the third level are daughter branches, with the finalities marked by actual values.
Here’s a rough representation:
Here’s an example:
HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\Extensions\jfmjfhklogoienhpfnppmbcbjfjnkonk
“Path” = sz:< C:\ProgramData\Real\RealPlayer\BrowserRecordPlugin\Chrome\Ext\rphtml5video.crx >
…where:
- HKEY_LOCAL_MACHINE = Hive
- Software = Key
- Google = Subkey
- Chrome = Subkey
- Extensions = Subkey
- Jfmjfhklogoienhpfnppmbcbjfjnkonk = Subkey
- Sz = data type
- C:\ProgramData\Real\RealPlayer\BrowserRecordPlugin\Chrome\Ext\rphtml5video.crx = value
This specific key refers to the file path where the real player extension library for Chrome is. Obviously, you couldn’t open it, since it’s encoded (probably written in C++?), but there it is.
We’re going to take a quick look at hives and data types. We won’t cover subkeys and keys in this post, since we aren’t going to explore the registry as in a reference book, but rather, gain a general understanding of how it works.
1. Hives
There are actually 7 hives together: 5 major ones, 1 depleted and 1 hidden in the registry. And we’re briefly going to go over each hive in turn. The letters shown in the brackets are just common abbreviations of the hive names…no biggie.
- HKEY_CLASSES_ROOT (HKCR)
This hive mainly deals with applications on your PC. So, for example, things like file associations (you’d probably see a huge list of keys with common file types, followed by a huge list of application classes under this hive). If a Word file were to be open, Windows would reference the program used to open this type of files (.docx), and the application would launch.
To be more specific, for Windows 2000 and above, the following can be said:
HKCR = HKCU\Software\Classes + HKLM\Software\Classes
In other words, keys in this hive are a compilation of machine and user based settings for application programs!
Many subkeys are common to both subkeys. So if there are clashes, the HKCU\Software\Classes take precedence. Why? That’s simple. You want to see your personal settings on program applications, like what toolbars you enabled in a browser, desktop backgrounds, etc., and not the default settings.
- HKEY_CURRENT_USER (HKCU)
This hive deals with settings that are specific to the current user. You might have noticed yet another overlap, that is, the overlap with HKU. That’s because, again, HKCU is actually a link to the subkey of HKU which corresponds to the current user. So, if John was logged in, the subkeys in HKCU would directly be taken from John’s key under the HKU hive.
On modern Windows versions (NT-based, to be specific), these settings are stored in two files called ntuser.dat and usrclass.dat (you can find them in the Documents and Settings folder in versions below Vista, and in the individual Users folders in Vista and above).
So, an example of a setting under this hive would be deactivating Aero. It’d then be stored under this hive.
- HKEY_LOCAL_MACHINE (HKLM)
As the name suggests, HKLM stores settings that are specific to the local machine. You’d see a couple of overlaps between HKLM and HKCU, but again, when it comes to runtime, HKCU values take precedence because they’re in context.
HKLM houses data on 5 main subkeys: Hardware, SAM, Security, Software, System. Examples of each:
Hardware: BIOS and keyboard settings
Software: software and windows settings
System: Hardware drivers and services
Now, SAM and security are protected hives, so they appear empty. To provide a brief overview, SAM contains user and group account data, and also security data for Windows NT/Server machines for the domain which the workstation belongs to. The security subkeys contains settings such as privileges, permissions and password rights.
That’s why Windows protects these two subkeys. Too important to be viewed by the naked eye.
- HKEY_USERS (HKU)
Again, this is the aggregate of all the users’ individual settings on a local machine. HKCU references settings here.
One thing worth mentioning is that HKU and HKCU both support roaming. Any Windows Server domain with workstations joint to it can load user settings to any station through copying the file to and fro the server machine. And these hives play an important role in enabling the experience – that is, containing the configuration settings for each user.
- HKEY_CURRENT_CONFIG (HKCC)
HKCC is yet another link to another key: HKEY_LOCAL_MACHINE\System\CurrentControlset\Hardware Profiles\Current. This hive deals with configuration data used by the current hardware set. Unlike most hives, this isn’t actually stored on the hard drive, but rather, it’s generated during runtime.
- HKEY_PERFORMANCE_DATA
This key isn’t visible to us, and it deals mainly with performance data gathered from the kernel or running programs.
- HKEY_DYN_DATA
This is the deprecated key. It used to store settings on hardware devices like PnP (Plug and play) devices, but is now unused.
2. Data types
If you haven’t done any programming before, data types is a topic of importance. Some programming languages are what we’d call loosely-typed languages. (e.g. Javascript). Others are what we’d call strongly-typed languages. (e.g. Java) Those who advocate the notion of data types are ‘strongly-typed’, and those which don’t are ‘loosely-typed’.
Simply put, writing a program involves defining variables. Those are properties of an object. For example, color, taste, time, etc. But variables are also required to fit into a specific category of data for the sake of executing algorithms. So, color might be a string, and time might be an integer. This is done so that distinctions are made clear. For example, color + time is an invalid statement because the types are different.
For the purpose of clarification, the Windows Registry also requires values to have a data type.
There are three things to take note of when mentioning data types in the context of the registry.
- Value names have a limit of 16383 Unicode characters
- There is an upper limit of 64K for all values under one key.
- The table of registry accepted variables:
Yes, this is taken directly from Microsoft’s support site.
That about covers it for the ‘what’s’ of the registry. As to the ‘how’s’, that’s for next time.
So, thanks for reading, and come back for the follow up!
Stay tuned for the next post…
Demystifying the Windows registry (II)





















