Windows Registry Internals: Hives, Keys, and How Settings Actually Persist

Almost every piece of persistent configuration on Windows — from a driver’s startup parameters to a user’s desktop wallpaper path — lives in the registry, a hierarchical database that replaced the tangle of .ini files Windows 3.x relied on. Understanding its actual on-disk structure, rather than just clicking through regedit, is what makes registry-related troubleshooting predictable instead of guesswork.

The logical structure: hives, keys, and values

The registry is organized as a tree. At the top are five root keys (often still called hives, though technically a hive is the underlying file):

HKEY_LOCAL_MACHINE (HKLM)   — system-wide configuration
HKEY_CURRENT_USER (HKCU)    — the logged-in user's settings
HKEY_USERS (HKU)             — every loaded user profile, keyed by SID
HKEY_CLASSES_ROOT (HKCR)     — file associations and COM registration
HKEY_CURRENT_CONFIG (HKCC)   — the active hardware profile

Below a root key, keys nest like folders, and each key holds zero or more values — a name, a type, and data. Value types matter for correctness: REG_SZ (a string), REG_DWORD (a 32-bit integer), REG_BINARY (raw bytes), and REG_MULTI_SZ (a list of strings) are the ones you’ll hit constantly.

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations"

Hive files: where this actually lives on disk

HKEY_LOCAL_MACHINE isn’t one file — it’s an umbrella over several hive files on disk, each independently loaded by the kernel at boot:

%SystemRoot%\System32\config\SYSTEM     → HKLM\SYSTEM
%SystemRoot%\System32\config\SOFTWARE   → HKLM\SOFTWARE
%SystemRoot%\System32\config\SAM        → HKLM\SAM
%SystemRoot%\System32\config\SECURITY   → HKLM\SECURITY
C:\Users\<user>\NTUSER.DAT              → HKEY_CURRENT_USER (per user)

Each hive file uses its own internal format — a sequence of fixed-size bins containing variable-size cells, the actual key/value records — with a header holding a sequence number used to detect a hive that wasn’t cleanly unloaded (a classic sign of an unclean shutdown corrupting registry state).

Why some keys need elevation and others don’t

Registry security works exactly like NTFS file permissions — because under the hood, keys carry the same kind of access control list (ACL) that files do. HKLM\SYSTEM requires administrator rights to modify because its ACL says so; HKCU is writable by the owning user because its ACL grants that user full control. regedit and Get-Acl both expose this directly:

Get-Acl "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" | Format-List

Live editing: regedit and PowerShell

regedit.exe remains the default GUI, but PowerShell’s registry provider treats keys as a filesystem-like drive, which makes scripted changes far more auditable than manual GUI editing:

New-Item -Path "HKCU:\Software\MyApp" -Force
Set-ItemProperty -Path "HKCU:\Software\MyApp" -Name "FirstRun" -Value 0 -Type DWord
Remove-ItemProperty -Path "HKCU:\Software\MyApp" -Name "FirstRun"

.reg files are the portable, double-clickable format for distributing a set of changes, and they’re just a text serialization of exactly this same key/value structure:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\MyApp]
"FirstRun"=dword:00000000

Backing up before a risky change

Because a bad registry edit can render a system unbootable, the standard precaution is exporting the affected key (or a full hive) before editing:

reg export "HKLM\SOFTWARE\MyApp" C:\Backups\MyApp.reg
reg import C:\Backups\MyApp.reg

For system-wide changes, a System Restore checkpoint captures registry state alongside system files, and is the more complete rollback mechanism when a change touches more than one isolated key.

Where autostart programs actually register

A concrete, frequently-useful example: every “program that starts automatically” mechanism on Windows ultimately writes to one of a small set of well-known Run keys, which is why malware analysis and startup-cleanup tools all check exactly these locations:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run"

Where the registry came from, and what it replaced

Windows 3.x configuration lived in a scattered collection of plain-text .ini files — WIN.INI, SYSTEM.INI, and a separate .ini file for practically every installed application — with no consistent schema, no security model, and no straightforward way to enumerate “everything a given application has configured” short of finding and parsing each file individually. The registry, introduced with Windows NT 3.1 and Windows 95, replaced this with a single, hierarchical, typed store: one consistent API (RegOpenKeyEx, RegQueryValueEx, and the rest of the Reg* family) for reading and writing configuration regardless of which application or OS component owns it, ACL-based security instead of relying on filesystem permissions over loose .ini files, and atomic, transactional-enough updates to individual values instead of an application needing to rewrite an entire text file to change one setting. The tangle of per-application .ini files never fully disappeared — GetPrivateProfileString and friends still work today for legacy compatibility — but new Windows and application configuration has overwhelmingly used the registry ever since.

Registry virtualization: how old software still runs under UAC

A subtler mechanism than the ACL model already described is registry virtualization, aimed specifically at older, pre-UAC 32-bit applications that assume they can freely write to HKEY_LOCAL_MACHINE\SOFTWARE without administrator rights — a completely reasonable assumption on Windows XP, and a broken one under UAC’s standard-user-by-default model. Rather than simply failing those writes, Windows transparently redirects them: an unelevated legacy application writing to HKLM\SOFTWARE\... actually gets its data silently written instead to HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software\..., and subsequent reads present a merged view where the redirected per-user value is returned instead of (or layered over) whatever’s actually in the real machine-wide key.

Get-ItemProperty "HKCU:\Software\Classes\VirtualStore\Machine\Software\SomeOldApp"

This virtualization only kicks in for 32-bit applications lacking a manifest that declares UAC awareness (a modern, properly-manifested application never gets virtualized, elevated or not), and it’s silently disabled for a specific set of sensitive locations — HKLM\SOFTWARE\Classes, HKLM\SOFTWARE\Microsoft\Windows, and HKLM\SOFTWARE\Microsoft\Windows NT are all explicitly excluded from virtualization regardless of the calling application’s manifest state, since transparently redirecting writes to core OS configuration keys would undermine the exact protection UAC is meant to provide. Understanding this explains a specific, recurring category of confusion: an old application that appears to save its settings successfully, but where those settings are nowhere to be found in the actual HKLM location a fresh reinstall or a different user account would expect to see them.

Why understanding this matters in practice

Most “Windows troubleshooting” that looks mysterious from the GUI becomes mechanical once you know it’s ultimately a key/value lookup with an ACL check: a setting that “won’t stick” is usually being overwritten by Group Policy re-writing the same key on a refresh interval; an application that “forgot” its license is usually reading from a HKCU key that a different user profile never populated; a piece of malware that “keeps coming back” is usually re-registering itself in a Run key a cleanup tool didn’t check. The registry isn’t inherently fragile — it’s just an unglamorous, ACL-protected key-value store, and treating it that way is what makes it debuggable.

Related:

Sources:

Registry Virtualization — Microsoft Learn