The Windows Registry: A Deep Dive for VBA Developers

DO NOT TOUCH THE WINDOWS REGISTRY OR YOUR COMPUTER WILL BRICK, NO ONE WILL LOVE YOU, AND YOUR DOG WILL DIE.

That about sums up the general feeling I got from every article I ever read about the Windows Registry as a young developer.  While it's true you shouldn't go changing things in the registry all willy-nilly, as long as you know where you can poke around and where you can't, it's not all that scary.

Editing the Windows Registry warrants a healthy respect, not debilitating fear.

Backing Up the Registry

You may not know this, but if you want to write an article on the internet about the Windows Registry, it must start with a disclaimer about backing up first.

If you don't include this obligatory advice, the Windows Registry police execute a no-knock raid in the middle of the night and seize all the keyboards in your home.  And then–just for good measure–they break all the fingers and wrists of any writing-age occupants.

So, to satisfy the internet gestapo, consider this your warning:

Before making any changes to the Windows Registry, back it up first.

How does one back up one's Windows Registry?  Honestly, I have no clue.  I have never done it.  But, hey, let me Google that for you:

OK, so I just read the article, and I guess it's dead easy to backup the registry.  

Full Registry Backup

When you do back up the registry, you have the option to back up all or only a part of it.

If you plan on tearing through the registry like an '80's rock star trashing a hotel room on day three of a cocaine-fueled bender, then you probably ought to back that whole sucker up and hope for the best.  

To do that:

1. Select "Computer" from the Registry Editor's tree view
2. Go to File > Export...
3. Save the file (it will be big...over 500 MB for my home computer)
4. Transfer it to the cloud or another device, like a USB flash drive
5. Party like the computer nerd equivalent of Ozzy Osbourne or Axl Rose

Of course, I'm not sure how you're supposed to restore that file if you screw things up so badly the computer won't even boot. In my opinion, it's far better to understand what you are doing in the first place than to go thrashing about relying on the (possibly illusory) safety net of your registry backup.  

Another thing to keep in mind is that the contents of the registry change constantly.  Like, several times per second on a typical Windows machine.  If you plan on restoring your registry backup, you should do it as soon as possible after realizing you screwed something up.  

Restoring a months-old full registry backup is likely to do far more harm than good.

Targeted Registry Backup

A more effective approach than a full backup is to export just the part(s) of the registry you plan on changing.

It's the exact same process as above, except instead of choosing "Computer" you select the parent folder of whatever registry value you plan on changing.  And instead of partying like a rock star, you change only the values within the section of the registry that you've backed up.  Like the well-adjusted adult that you are.

Restoring a Registry Backup

A "registry backup" is nothing more than a text file with a .reg extension (i.e., a registry file).

The file includes an entry for every folder and value in the exported folder.  When you import this file using the Registry Editor, it reads through the file and:

• Creates any missing entries
• Updates the value(s) of any existing entries

It's important to note that restoring a registry backup does not remove any registry keys or values that were added since the backup was made.  Adding registry keys and/or values will change the behavior of certain applications and Windows itself.  Restoring a backup does not undo these changes.

This is yet another reason why overreliance on a registry backup can get you into trouble.

To restore a backup, open the Registry Editor and follow these steps:

1. File > Import...
2. Choose the .reg file you backed up earlier
3. Click [Open]

And that's it.

Terminology: Hives, Keys, and Values

• Hives: the top-level keys
• Keys/Subkeys: commonly referred to as folders or subfolders since they share the same icon and hierarchical structure as Windows file folders
• Value Names and Data: the rows of information on the right side of the Registry Editor window

HKLM vs. HKCU

The most important distinction to understand when editing the registry is this one.

• HKLM: HKey_Local_Machine
• HKCU: HKey_Current_User

As the names suggest, HKLM is used to store machine-wide data while HKCU stores user-specific data.

You need admin rights to change HKLM keys and values.

You do not need admin rights to change HKCU keys and values.

Generally speaking, it's difficult to hurt things too badly if you stay within the confines of HKCU.

32-bit vs. 64-bit Registry Keys

I'll assume your computer has 64-bit Windows.  In 2024, nearly all PCs are running 64-bit Windows.  Use the About > Device specifications data from the Settings app to confirm:

HKLM: 32 vs. 64 Bit

To maintain compatibility with existing 32-bit applications when 64-bit Windows was introduced, Microsoft created special sections of the HKLM hive.

• HKLM\Software\: 64-bit application data
• HKLM\Software\WOW6432Node\: 32-bit application data

The "WOW6432Node" stands for "Windows on Windows 64-bit, 32-bit node." It contains 32-bit Windows application data for use on Windows 64-bit.

Never create registry keys (i.e., folders) named WOW6432Node.  Consider it a reserved word.

Similarly, it's extremely rare that you would ever include "WOW6432Node" when looking up a registry value.  The registry API functions automatically look up values from those keys as needed (i.e., when running 32-bit applications on 64-bit Windows).

HKCU: 32 vs. 64 Bit

There is no distinction between 32-bit and 64-bit applications within the current user hive, HKCU.

Aliases

Several top-level keys/hives are actually aliases (or combinations) of other keys/hives within the registry.

• HKCR (HKEY_CURRENT_ROOT): a merger of HKCU\Software\Classes and HKLM\Software\Classes
• HKCU (HKEY_CURRENT_USER): the user profile hive under HKEY_USERS that belongs to the currently logged-in user

Virtual Folders

Earlier versions of Windows allowed non-admins to change almost any value in the registry, including in the HKLM hive.

With the introduction of User Access Control (UAC) in later versions of Windows, Microsoft wanted to restrict access to critical sections of the registry without breaking backward compatibility for thousands of applications.

The ugly compromise?  Registry virtualization.

If a non-admin in a 32-bit application tries to write data to these protected areas of the registry, Windows silently inserts \VirtualStore\ into the registry path.  This allows the process to work as it did before, but without granting access to sensitive registry areas.

When this feature was first introduced, it led to lots of hard-to-diagnose registry-related bugs.  Most newer applications have adopted Microsoft's stricter registry access rules, so this is less of an issue than it once was.  However, it may still crop up from time to time.  Knowing that this issue exists might very well save you hours of troubleshooting some day.

Reading and Writing the Registry from VBA

There are a variety of ways to read and write to the registry from VBA, but I stick to the following two alternatives:

• Built-in VBA functions: GetSetting/SaveSetting/DeleteSetting
• Romke Soldaat's clsRegOp class module

ProcMon: A Tool for Deeper Understanding

If you really want to know what's going on behind the scenes, fire up ProcMon–one of the many venerable SysInternals tools from Microsoft ace Mark Russinovich.