skip to content

In Windows, what is the registry, and how do the HKLM and HKCU root keys differ in scope and in where each is physically stored?

level: juniorimportance: must knowfreq 76%

answer

  1. one database, two real roots
  2. machine-wide versus one user
  3. binary hives under System32
  4. NTUSER.DAT sits in the profile
  5. loaded at logon, gone at logoff

basics

~10 s

The Windows registry is the OS's hierarchical configuration database. HKLM holds machine-wide settings backed by hive files in %SystemRoot%\System32\config; HKCU holds the currently logged-on user's settings, backed by NTUSER.DAT inside that user's profile folder.

solid answer

~40 s

The registry is a hierarchical key/value database the kernel's configuration manager maintains on behalf of the OS, drivers and applications. Keys are containers, values are named typed data, and every key carries its own security descriptor, so access is permission-checked like a file. `HKEY_LOCAL_MACHINE` is machine-wide and lives in binary hive files under `%SystemRoot%\System32\config` — `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY` — and normally needs administrator rights to write. `HKEY_CURRENT_USER` is not a separate store at all: it is a link to the subkey of `HKEY_USERS` named for the calling account's SID, backed by `NTUSER.DAT` in the user's profile, loaded at logon and unloaded at logoff. That split matters operationally: a service running as LocalSystem does not see a desktop user's HKCU, and a per-user setting written while nobody is logged on goes nowhere useful.

code

powershell · 6 lines
powershell
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\W32Time' |
    Select-Object ImagePath, Start, ObjectName

Get-ChildItem -Path 'HKU:\' -ErrorAction SilentlyContinue
New-PSDrive -Name HKU -PSProvider Registry -Root HKEY_USERS | Out-Null
Get-ChildItem HKU:\ | Select-Object -ExpandProperty Name

go deeper

for a junior

Be able to say plainly that HKLM is machine-wide and HKCU is the current user's, and that HKCU comes from NTUSER.DAT in the user's profile while HKLM hives sit under System32\config.

for a middle

Explain that HKCU and HKEY_CLASSES_ROOT are links or merged views rather than real stores, that keys carry their own security descriptors, and that a profile hive is only mounted while that user is logged on.

for a senior

Show you reason about it operationally: a LocalSystem service does not see a desktop user's HKCU, WOW6432Node redirection hides keys from mismatched-bitness tools, and fleet-wide settings belong in Group Policy or config management rather than hand edits.

for a principal

Own the policy question — where configuration truth lives, how registry drift is detected and remediated across a fleet, and when to move settings out of the registry into managed policy or an application-owned store entirely.

## What the registry actually is The Windows registry is a hierarchical, crash-consistent key/value database that the operating system, device drivers and applications use for configuration. **Keys** are containers, much like directories. **Values** are named, typed data items stored inside a key, much like files. It is not a text file you can `cat` — it is a set of binary *hive* files that the kernel's configuration manager mediates access to through the `Reg*` Win32 APIs. Every key has its own security descriptor, so reads and writes are access-checked exactly the way a file's are, and keys can be audited. ## The root keys, and which ones are real Regedit shows five roots, but only two are genuine storage: - **HKEY_LOCAL_MACHINE (HKLM)** — machine-wide state: installed software, driver and service configuration, the security databases. - **HKEY_USERS (HKU)** — one subkey per loaded user profile, named by the account's SID. - **HKEY_CURRENT_USER (HKCU)** — a link to the HKU subkey for the SID of the process making the call. Two processes running as different users see different data behind the same path. - **HKEY_CLASSES_ROOT (HKCR)** — a merged view of `HKLM\SOFTWARE\Classes` and `HKCU\Software\Classes` for file associations and COM registration; the per-user entries win where both exist. - **HKEY_CURRENT_CONFIG** — a link into `HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current`. ## Where the bytes live Machine hives sit in `%SystemRoot%\System32\config`: `SYSTEM`, `SOFTWARE`, `SAM`, `SECURITY`, `DEFAULT`, each with `.LOG1`/`.LOG2` recovery logs the configuration manager uses so a power loss mid-write leaves a consistent hive rather than a corrupt one. One notable exception: `HKLM\HARDWARE` is **volatile** — it is rebuilt in memory at every boot from hardware enumeration and never written to disk. User state is per profile. `NTUSER.DAT` in `C:\Users\<name>` backs the bulk of HKCU; `UsrClass.dat` under `AppData\Local\Microsoft\Windows` backs `HKCU\Software\Classes`. Because a profile hive is loaded at logon and unloaded at logoff, an administrator who needs to edit an absent user's settings must mount it explicitly: ``` reg load HKU\TempHive C:\Users\bob\NTUSER.DAT reg add "HKU\TempHive\Software\Contoso" /v Mode /t REG_SZ /d quiet reg unload HKU\TempHive ``` ## Consequences that show up in real work **Privilege.** Writing under HKLM requires administrator rights; writing under your own HKCU does not. That asymmetry is why user-level persistence and per-user application settings gravitate to `HKCU\Software\Microsoft\Windows\CurrentVersion\Run`, and why an installer that "works when I run it" but not when deployed is usually writing HKLM without elevation. **Services are registry objects.** Every Windows service is a key under `HKLM\SYSTEM\CurrentControlSet\Services\<name>` with values such as `ImagePath`, `Start`, `Type` and `ObjectName`. `CurrentControlSet` is itself a symbolic link to a numbered `ControlSet00n`, which is how last-known-good boot works. **Precedence is per-feature, not global.** There is no universal rule that HKCU beats HKLM. Individual components decide; Group Policy, for instance, reads both `HKLM\SOFTWARE\Policies` and `HKCU\Software\Policies`, with machine policy typically taking precedence for the same setting. **WOW64 redirection.** On 64-bit Windows, a 32-bit process reading `HKLM\SOFTWARE\Vendor` is silently redirected to `HKLM\SOFTWARE\WOW6432Node\Vendor`. A key that "disappeared" is very often just a bitness mismatch between the tool writing it and the tool reading it. ## How you touch it `regedit.exe` for interactive work, `reg.exe` for scripting, and the PowerShell registry provider, which surfaces hives as drives (`HKLM:` and `HKCU:`) so `Get-ChildItem`, `Get-ItemProperty` and `New-ItemProperty` work on them. Exporting a subtree to a `.reg` file before changing it is the cheap rollback, and for anything fleet-wide, Group Policy or configuration management is preferable to hand-edited keys — a manual edit leaves no record of who changed what or why.

  • A service running as LocalSystem writes to HKCU. Which hive does it actually land in?
    LocalSystem's SID is S-1-5-18, so its HKCU resolves to `HKU\S-1-5-18`, which is backed by a profile under `%SystemRoot%\System32\config\systemprofile`. It is emphatically not the desktop user's hive, so per-user settings written by a service are invisible to the logged-on person. Services that must reach a specific user's settings load that user's `NTUSER.DAT` explicitly or impersonate the user.
  • Why does a 32-bit installer sometimes appear to write registry keys that a 64-bit tool cannot find?
    WOW64 registry redirection. On 64-bit Windows, a 32-bit process writing `HKLM\SOFTWARE\Vendor` is transparently redirected to `HKLM\SOFTWARE\WOW6432Node\Vendor`. A 64-bit reader looking at the unredirected path sees nothing. Either use a matching-bitness tool, read the `WOW6432Node` path directly, or open the key with the explicit `KEY_WOW64_32KEY` / `KEY_WOW64_64KEY` access flag.
  • What protects the registry from corruption if the machine loses power mid-write?
    The configuration manager journals changes to per-hive log files (`.LOG1`/`.LOG2`) alongside each hive before applying them, so a hive is either fully updated or recoverable to its prior consistent state at next load. That is why you cannot safely copy a live hive file with a plain file copy — you back it up with `reg save`, VSS, or the backup APIs instead.

Think of HKLM as the building's master wiring diagram kept in the basement, and HKCU as the sticky notes on one tenant's own desk — the desk goes away when that tenant leaves for the day.

saying these in an interview costs you the question

  • Says HKCU holds settings for all users on the machine
  • Claims the registry is one big file on disk
  • Thinks HKEY_CLASSES_ROOT is a hive stored on disk
  • Assumes HKCU always overrides HKLM for every setting
  • Believes any user can write machine-wide HKLM keys

context

resolving links…