The Registry & the File System
What is it?
Windows keeps its state in two places. The registry is a central hierarchical database of configuration settings — organized into root hives (like HKEY_LOCAL_MACHINE for the whole machine and HKEY_CURRENT_USER for the logged-on user), then keys and values, much like folders and settings. The file system is where actual files live, in a tree of drives and folders with well-known locations (C:\Windows for the OS, C:\Program Files for installed software, C:\Users for each person's profile).
Why it matters
Nearly every administrative and troubleshooting question is really 'where does this live?' — a setting is in the registry, a file is on disk. Knowing the layout lets you find configuration and files fast, understand what installing or changing something actually did, and recognise when something is in a place it should not be.
Where you see it
The registry in the Registry Editor (regedit) and registry queries from the command line/PowerShell; the file system in Explorer and directory listings. Software installs, group policy and user preferences all write to one or both.
What normal looks like
OS files under C:\Windows, applications under C:\Program Files, each user's data under C:\Users\<name>; machine-wide settings under HKLM, per-user settings under HKCU. Autostart entries, installed programs and system config in their expected keys and folders.
What suspicious looks like
For troubleshooting/security: an executable in a user's profile or a temp folder rather than Program Files, an autostart registry value pointing at an odd path, or configuration changed outside the normal channels. 'Right kind of thing, wrong location' is the recurring signal.
How analysts investigate
By deciding first whether a question is about a SETTING (look in the registry — which hive: machine-wide HKLM or per-user HKCU?) or about a FILE (look on disk — is it in an expected location?), then navigating the relevant hierarchy to the exact key or folder.
Common beginner mistakes
- Confusing the registry with the file system. Settings live in the registry; files live on disk. Looking for a configuration value among files (or a file among registry keys) wastes time and misses the point.
- Ignoring which hive a setting is in. A value under HKLM affects the whole machine; the same-looking value under HKCU affects only one user — mixing them up leads to changes that apply too broadly or not at all.
When Aldar's help desk installs an application on WS-041, two things happen. Files are copied onto disk — usually into C:\Program Files. And settings are written into the registry — how the app should behave, where its data is, whether it starts automatically. If you only ever think 'files', half of what Windows does is invisible to you. The registry is the other half: the central database where Windows and applications store configuration.
TWO PLACES WINDOWS KEEPS STATE
REGISTRY (settings) FILE SYSTEM (files)
HKEY_LOCAL_MACHINE (HKLM) C:\
SOFTWARE\... Windows\ (the OS)
SYSTEM\... <- whole machine Program Files\ (installed apps)
HKEY_CURRENT_USER (HKCU) Users\
Software\... <- this user only a.hakim\ (a.hakim's profile)
...\Run (autostart for user) Downloads\
AppData\ (per-user app data)
Setting? -> registry (which hive?) File? -> disk (which folder?)The registry is organized like a tree: root hives at the top, then keys (like folders), then values (the actual settings). Two hives matter most at this stage. HKEY_LOCAL_MACHINE (HKLM) holds machine-wide settings that apply to everyone on the computer. HKEY_CURRENT_USER (HKCU) holds settings for the user who is logged on right now. The same conceptual setting can exist in both — and which hive it is in decides its scope. The file system mirrors this idea of scope in folders: C:\Windows and C:\Program Files are shared by the machine, while C:\Users\<name> is that one person's private space. So the two big questions when you're hunting something are always: is it a setting or a file, and is it machine-wide or per-user?
Where does a program that runs at login live?
On WS-041, a program launches automatically every time a.hakim logs in, but not for other users. You need to find BOTH what runs and the file it runs. Where do you look, and in which order?
Decide: setting or file, and what scope?
'What runs at login' is a SETTING — an autostart entry — so it lives in the registry, not on disk. And because it affects only a.hakim, not everyone, it must be in the per-user hive HKCU, not the machine-wide HKLM. A beginner might start browsing folders on C:\; but files don't decide what auto-runs — a registry value does. The scope (one user) points straight at HKCU.
Read the autostart value to get the target file.
In the per-user Run key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run) you find a value whose data is a path — say C:\Users\a.hakim\AppData\Roaming\updater.exe. That single value answers 'what runs' AND points you to the file on disk. This is the registry and file system working together: the setting names the file, and the file lives at the path the setting gives.
Judge the target by its location.
Now assess the file: it lives in AppData\Roaming inside a user profile, not in C:\Program Files. For a normal installed application that is unusual — legitimate software generally installs machine-wide under Program Files. A per-user autostart pointing at an executable in a user's AppData is the classic 'right kind of thing, wrong location' pattern worth a closer look. Decision: you found both the setting and the file quickly BECAUSE you asked 'setting or file, and what scope' first — and the location of the file is itself a finding.
Quick check
You need to change a configuration SETTING (not a file) that should apply to every user on a machine. Where does it belong?
A quick self-check — it doesn't affect your XP or progress.
Quick check
Under normal circumstances, where would you expect a properly installed business application's program files to live?
A quick self-check — it doesn't affect your XP or progress.
Sign in to save your progress on the server.