Hives, keys, and values

Registry & configuration introduced hives, keys, and values as the registry's basic vocabulary. This chapter is about what a hive actually is, and why the familiar HKLM/HKCU roots in Regedit are more of a convenience mapping than a literal description of storage.

A hive is a persistent store; the editor view is a presentation layer

Each hive corresponds to an actual on-disk file (or, for some hives, structures built dynamically at boot rather than loaded from disk at all), containing a self-contained tree of keys and values. What Regedit shows you — HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER, and the other familiar roots — are logical namespaces, presenting one or more underlying hives in a user-friendly, unified tree, not a direct, literal window into a single physical file each.

HKCU: a mapping, not a fixed location

The clearest illustration of this distinction: HKEY_CURRENT_USER doesn't point at some fixed, universal store called "the current user's settings." It's a runtime mapping to whichever user's profile hive is currently active for the calling process — when a different user is signed in, or when a process is impersonating a different security context, HKCU for that process resolves to a genuinely different underlying hive. This is exactly why two users signed in simultaneously (or a service impersonating different callers in turn) can each see a completely different, correctly-scoped HKCU view, all through the identical, unchanging API path — the mapping, not the API, is what's doing the work of pointing each caller at the right data.

Machine-wide vs. per-user, and why the split exists

HKLM (HKEY_LOCAL_MACHINE) holds configuration meant to apply regardless of who's signed in — service definitions, driver parameters, systemwide policy. HKCU holds configuration specific to the currently active user — desktop preferences, per-user application settings. This split mirrors a distinction that shows up constantly elsewhere in this course: system-wide state that exists independent of any particular session, versus per-session or per-identity state — the same kind of separation Sessions draws between a machine-wide window station concept and a specific user's own desktop.

Values are typed, and the type is meaningful

A registry value isn't just an untyped blob of bytes — it carries an explicit type (a string, an expandable string with embedded environment-variable references, a 32- or 64-bit integer, binary data, and a few others), and the component reading it is expected to interpret it according to that declared type. This matters practically: a value stored as REG_EXPAND_SZ (an expandable string) containing something like %SystemRoot%\System32\drivers isn't meant to be used literally — the reading component is expected to expand the environment-variable reference into the real path first, and treating it as a plain string instead produces a subtly, confusingly wrong result.

A worked example: why editing HKCU can silently affect the "wrong" session

A common, genuinely confusing troubleshooting scenario: an administrator remotely edits HKCU values intending to change a specific user's settings, but does so from a session running under their own identity (or under SYSTEM), and the edit lands in an entirely different hive than the one the target user's own session actually reads from — because HKCU, for the editing process, was never pointing at the target user's profile hive in the first place. Correctly targeting another user's configuration generally means addressing that user's hive explicitly (loaded under a path within HKEY_USERS, keyed by their SID), rather than relying on HKCU's per-caller mapping to somehow resolve to someone else.

A common mistake

Treating the registry's logical roots as physical storage locations, rather than as views resolved per-caller at access time, leads directly to the kind of "my edit didn't do what I expected" confusion described above. HKLM and HKCU are genuinely useful, stable names for "wherever the relevant hive actually is for this caller right now" — not fixed addresses.

Where this connects

• The Configuration Manager covers the kernel machinery actually responsible for loading hives, resolving these mappings, and persisting changes.
• Access tokens is what determines which identity's profile hive HKCU resolves to for a given caller.