skip to content

Registry and Services

4 roadmaps6 questions

The registry is Windows' configuration database and the Service Control Manager is its init system, with start types, recovery actions, and service accounts to choose between. Both surface the moment an interview turns to deploying or hardening a Windows service.

on this pageshow

explore

questions

6

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…

open as a page

In the Windows Service Control Manager, how do the Automatic, Automatic (Delayed Start), Manual and Disabled start types differ, and what problem does delayed start solve?

level: middleimportance: must knowfreq 68%

basics

~20 s

Automatic starts a service during boot, Manual only when something requests it, and Disabled blocks starting at all. Automatic (Delayed Start) still starts unattended but after the automatic wave, at lowered priority, so it stops slow services from delaying logon.

open as a page

A Windows service must run unattended and also reach a file share on another server. How do LocalSystem, LocalService, NetworkService and a virtual account differ, and how would you choose between them?

level: seniorimportance: should knowfreq 56%

basics

~20 s

LocalSystem is fully privileged locally and authenticates on the network as the computer account. NetworkService has low local privilege but the same computer-account network identity. LocalService is low privilege and anonymous on the network. A virtual account gives a per-service identity with the computer account's network access and no password to manage.

open as a page

On Windows, why is write access for a non-administrator to a service's key under HKLM\SYSTEM\CurrentControlSet\Services treated as a privilege escalation, and what related weaknesses are checked alongside it?

level: seniorimportance: should knowfreq 36%

basics

~20 s

That key defines which binary the service runs and which account runs it. Anyone who can write it can point ImagePath at their own executable and have the Service Control Manager launch it as LocalSystem at the next start, turning a registry permission into full machine control.

open as a page

A Windows service fails to start with "Error 1053: The service did not respond to the start or control request in a timely fashion." What does the Service Control Manager expect from a service process, and where do recovery actions fit in?

level: seniorimportance: should knowfreq 44%

basics

~20 s

Error 1053 means the process never reported back to the Service Control Manager in time. A service must connect to the SCM and report its status within roughly 30 seconds, reporting start-pending with a wait hint if initialisation is slow — an ordinary console program run as a service always fails this way.

open as a page

Windows registry values are typed. What is the difference between REG_SZ and REG_EXPAND_SZ, and what must code reading the latter do differently?

level: juniorimportance: nice to knowfreq 34%

basics

~20 s

REG_SZ is a plain string stored literally. REG_EXPAND_SZ is a string that still contains unexpanded environment-variable references such as %SystemRoot%, so the reader must expand it before use — otherwise it gets a path that does not exist.

open as a page