Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
A technician's guide to the Windows registry: what each hive is and which file backs it, how to edit safely with Registry Editor, reg.exe and PowerShell, why policy keys overwrite manual edits, and how to push and audit registry values across a fleet.
Plenty of Windows support tickets end with "change this value in the registry", and plenty start with someone having changed one. The registry looks like a wall of cryptic folders, but it follows a small set of rules once you know where each piece lives on disk and who else writes to it. This guide walks through the Windows registry and Registry Editor from the technician's side: what the hives are, how to edit safely, and how to push and audit a change across a fleet.
C:\Windows\System32\config; each user's sits in NTUSER.DAT in their profile.The registry is a database. Windows reads it at boot to decide which drivers to load and which services to start, and it reads it again every time you open an app, sign in or plug in a device. Applications store their own settings in it too. Microsoft's own registry reference describes it as the central hierarchical database that replaced the old .ini and config.sys files.
The structure has three levels, and the names matter because every guide uses them. A key works like a folder. Keys hold subkeys and values. A value has a name, a type and data: EnableLUA, a DWORD, set to 1. When a support article says "set the value", it means that last level.
At the top sit the root keys, the five folders you see when Registry Editor opens. Two of them are shortcuts into the other three, which is the first thing worth understanding before you edit anything.
A hive is a chunk of the registry backed by a file on disk. That is the whole trick. When you change a value in Registry Editor, Windows writes it to one of these files, and when a profile or a machine breaks, it is usually one of these files that broke.
| Root key | What it holds | File on disk |
|---|---|---|
| HKEY_LOCAL_MACHINE\SYSTEM | Drivers, services, boot configuration | C:\Windows\System32\config\SYSTEM |
| HKEY_LOCAL_MACHINE\SOFTWARE | Machine-wide app and Windows settings | C:\Windows\System32\config\SOFTWARE |
| HKEY_LOCAL_MACHINE\SAM | Local user accounts and password hashes | C:\Windows\System32\config\SAM |
| HKEY_LOCAL_MACHINE\SECURITY | Local security policy and LSA secrets | C:\Windows\System32\config\SECURITY |
| HKEY_USERS.DEFAULT | The profile used before anyone signs in | C:\Windows\System32\config\DEFAULT |
| HKEY_CURRENT_USER | The signed-in user's settings | %UserProfile%\NTUSER.DAT |
| HKEY_CURRENT_USER\Software\Classes | The user's file associations and COM registrations | %LocalAppData%\Microsoft\Windows\UsrClass.dat |
Two root keys never appear in that file list. HKEY_CLASSES_ROOT is a merged view of the machine's and the user's Classes keys, and Microsoft's reference spells out where writes land: a change under HKEY_CLASSES_ROOT goes to the user's copy if the key already exists there, and to the machine's copy otherwise. HKEY_CURRENT_CONFIG is a pointer into the SYSTEM hive for the current hardware profile. Edit the real location, not the view, and you will always know what you changed.
HKEY_CURRENT_USER is a view too. It points at the signed-in user's branch under HKEY_USERS, which is named after their SID. That detail stops mattering until you need to change another person's settings, and then it is the whole job.
SAM and SECURITY are locked down even from administrators. The Local Security Authority reads them, and the settings in SECURITY are the ones you change through the local security policy console rather than by hand.
Every value has a type, and the type decides what the data means. Typing a 1 into a string value when Windows expects a DWORD is the most common way a correct-looking fix does nothing. Six types cover nearly every edit:
%SystemRoot% that expand when read.When a guide says "create a DWORD", pick DWORD (32-bit) even on 64-bit Windows. The QWORD option is a different type, and a setting that expects a DWORD will ignore it.
Press Win+R, type regedit and press Enter, then approve the UAC prompt. The Windows 11 Registry Editor is the same tool as on Windows 10, with one addition that saves time: the address bar under the menu. Paste a full path such as HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System and press Enter to jump straight there. Short forms like HKLM\SOFTWARE\... work too.
Three habits make the tool bearable. Add the keys you visit often to Favorites, which survive across sessions. Use Find (Ctrl+F) only as a last resort, because it walks the whole tree and can take minutes. And keep the right-hand pane's Type column visible, so a string pretending to be a number stands out.
Registry Editor saves every change the moment you press Enter. There is no Save button and no undo. That is why the next section exists.
Every safe registry edit follows the same four steps. Microsoft's own guidance starts the same way: export the keys you plan to edit before you touch them.
The command-line version does the same job and leaves a better paper trail:
codereg export "HKLM\SOFTWARE\Contoso\App" C:\temp\contoso-app-before.reg /y reg import C:\temp\contoso-app-before.reg
One limit to know about the .reg rollback. Merging a .reg file adds and overwrites values, but it never deletes a value you created after the export. If your change was "add a new value", the rollback is deleting that value by hand.
For a change bigger than one key, take a System Restore point first. It snapshots the registry hives along with system files, and it is the rollback Microsoft now points people to.
That is because the old safety net is gone. Starting in Windows 10 version 1803, Windows stopped copying the hives to the RegBack folder. Per Microsoft's RegBack article, the files are still there but each one is 0 KB, and the change was made to shrink Windows' disk footprint. You can switch the old behaviour back with a DWORD named EnablePeriodicBackup set to 1 under HKLM\System\CurrentControlSet\Control\Session Manager\Configuration Manager, which creates a scheduled RegIdleBackup task after a restart. Old guides that tell you to copy RegBack over config to fix a boot loop will copy empty files onto a broken machine.
HKEY_CURRENT_USER only shows the person signed in. To change a setting for a user who is signed out, or for every profile on a shared PC, you load their hive yourself.
In Registry Editor, select HKEY_USERS (or HKEY_LOCAL_MACHINE), then File, Load Hive. Pick the user's NTUSER.DAT from C:\Users\<name>, give it a temporary name such as TempUser, and it appears as a branch you can edit. When you are done, select that branch and choose File, Unload Hive. Skip the unload and the user's next sign-in can fail, because Windows cannot open a file you are still holding.
The command line is quicker for scripts:
codereg load HKU\TempUser C:\Users\jsmith\NTUSER.DAT reg add "HKU\TempUser\Software\Contoso\App" /v Theme /t REG_SZ /d Dark /f reg unload HKU\TempUser
Loading C:\Users\Default\NTUSER.DAT the same way lets you change the defaults every new profile starts from. It has limits, which this 2024 r/sysadmin thread runs into: values set in the Default hive were correct on disk, yet new users still got the old taskbar and colour settings, because Windows and the theme applied at first sign-in overwrote them. The replies point at Group Policy or Intune for anything that must stick, and at Process Monitor for finding what overwrote it.
The same trick repairs a machine that will not boot. From the Windows Recovery Environment command prompt, load D:\Windows\System32\config\SYSTEM (the drive letter is often different in WinRE) under HKLM, fix the value that broke boot, and unload it before you restart.
For another live machine, Registry Editor's File, Connect Network Registry opens its HKLM and HKU over the network. That needs the Remote Registry service running on the target, and on Windows clients it is disabled by default. Turning it on across a fleet to save a few clicks widens what an attacker with one admin password can reach. Leave it off and run reg or PowerShell through your remote management tool instead.
Every key carries its own permissions, the same kind of access list a folder has. Right-click a key and choose Permissions to see it. Most keys under HKLM let Administrators write; most under HKCU belong to the user. When a value will not save and Registry Editor reports "Error writing the value's new contents", the key's permissions said no.
A handful of keys are owned by TrustedInstaller, the account Windows Update and servicing use, and even an elevated administrator can only read them. Guides that tell you to take ownership and grant yourself Full Control will make the edit go through. They also leave that key writable by any admin-level process from then on, and the next cumulative update may fail or reset it. If you have to take ownership for a one-off fix, note the original owner first, make the change, then restore the owner and the permissions you found.
Permissions are also why a script that works in your session fails under your management agent, and the other way round. An agent running as SYSTEM can write HKLM but sees its own HKCU, not the user's, so a per-user setting pushed as SYSTEM lands in the wrong place. Push per-user values in the user's context, or load each profile's hive as shown above.
The graphical editor is for exploring. Anything you will do twice belongs in a command. reg.exe ships with every version of Windows and works in plain cmd:
codereg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v EnableLUA reg add "HKLM\SOFTWARE\Contoso\App" /v AutoUpdate /t REG_DWORD /d 0 /f reg delete "HKLM\SOFTWARE\Contoso\App" /v AutoUpdate /f
PowerShell treats the registry as a drive, so the same cmdlets that work on files work on keys. HKLM: and HKCU: are mapped already:
powershellGet-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" -Name EnableLUA if (-not (Test-Path "HKLM:\SOFTWARE\Contoso\App")) { New-Item -Path "HKLM:\SOFTWARE\Contoso\App" -Force | Out-Null } New-ItemProperty -Path "HKLM:\SOFTWARE\Contoso\App" -Name AutoUpdate -PropertyType DWord -Value 0 -Force Set-ItemProperty -Path "HKCU:\Control Panel\Mouse" -Name DoubleClickSpeed -Value 500
Two details trip people up. New-ItemProperty creates the value with the type you name, while Set-ItemProperty on a value that does not exist yet creates it as a string, which is how a DWORD setting ends up as REG_SZ and silently does nothing. And neither cmdlet creates a missing key, which is why the Test-Path and New-Item line comes first. Which shell to reach for, and when, is covered in our PowerShell vs CMD guide.
Support articles cover the common settings. For everything else, you find the value yourself, and there are two reliable ways.
The quick one is a before-and-after export. Export the app's key, change the setting through the app's own options, export again, and compare:
codereg export "HKCU\Software\Contoso\App" C:\temp\before.reg /y reg export "HKCU\Software\Contoso\App" C:\temp\after.reg /y fc /u C:\temp\before.reg C:\temp\after.reg
The fc output shows the lines that changed, which is the value and the data the setting writes. It works when you already know which key the app uses.
When you do not, Process Monitor from Sysinternals watches every registry access as it happens. Start a capture, filter on the app's process name and on the operation RegSetValue, then change the setting once. The handful of rows left are the values it wrote, with the full path and the data. Stop the capture straight away, because Process Monitor logs millions of events a minute and a long capture is unreadable.
Whichever method you use, test the value on a second machine before you push it anywhere. Some apps write a setting to the registry and also cache it in a file, and a registry-only change on a fresh machine is the only proof the registry is the part that counts.
The ticket goes like this. You change a value, it works, and an hour later it has reverted. Nothing is broken. Something with more authority wrote the value back.
Keys under HKLM\SOFTWARE\Policies and HKCU\Software\Policies belong to policy. Group Policy and Intune write them, and Windows reads them in preference to the normal setting elsewhere in the registry. Group Policy refreshes in the background every 90 minutes with a random offset of up to 30, and each refresh rewrites the policy values it manages. Edit a policy value by hand and you have a temporary change with a timer on it. The fix lives in the GPO, through the Group Policy Editor or the domain's management console, not in regedit.
Preferences are the other half. Group Policy Preferences can also write registry values, outside the Policies keys, and they come in two flavours that matter here. A preference set to apply once is a starting point the user can change. A preference set to reapply on every refresh behaves like policy, and it will undo your manual fix the same way.
So before you edit, check who owns the value. gpresult /h report.html lists the GPOs and preferences that touched the machine, and on an Intune device the MDM diagnostics report does the same. If something manages the value, change it there.
The registry accumulates leftovers. Uninstalled apps leave keys behind, and a cleaner promises to find them all and make the PC faster. On a modern machine, a few thousand orphaned keys cost nothing a user can measure, because Windows reads the keys it needs and ignores the rest.
The risk runs the other way. A cleaner decides which keys are "unused" by guessing, and a wrong guess removes something a driver, a licence check or a shell extension needed. Microsoft's support policy on registry cleaning utilities is blunt: "Microsoft does not support the use of registry cleaners." The same statement warns that problems caused by these tools may not be repairable without reinstalling Windows.
The r/sysadmin thread below is the usual way this story ends: a technician who ran several cleaners for years until a Windows feature update started failing and rolling back. The replies are close to unanimous, and the top one makes the point above: a large registry has no measurable cost, and a cleaner can remove something a later update needs.
For a slow PC, the causes worth chasing live elsewhere: startup items, a full disk, a failing drive, or one runaway process. A registry cleaner fixes none of them.
The same features that make the registry useful make it a favourite place to hide. MITRE ATT&CK lists registry run keys as technique T1547.001: a value under HKCU\Software\Microsoft\Windows\CurrentVersion\Run starts a program at every sign-in, and writing to HKCU needs no admin rights at all.
Our guide to startup programs covers the five places these entries live and how to list them in one pass.
Two other patterns show up in incident reports. Image File Execution Options, a debugging key under HKLM, can name a "debugger" that launches instead of a real program, so opening the on-screen keyboard at the sign-in screen starts a command prompt. And some malware keeps its whole payload in a registry value and runs it from memory through PowerShell, which leaves no executable on disk for a file scan to find, the pattern our fileless malware explainer walks through.
Policy keys get abused too. A value under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender that disables protection looks exactly like a legitimate policy, and on an unmanaged machine nothing will set it back. Tamper Protection blocks these changes on current Windows, which is one more reason to leave it on.
The practical check is a baseline. Export the Run keys, the IFEO key and the Defender policy key from a clean build, then compare machines against it on a schedule. A new value nobody can explain is worth a closer look, and our indicators of compromise guide covers what to do with one.
On one machine, regedit or a .reg file is fine. On fifty, you need a way to set the value everywhere and a way to prove it stuck. Three routes cover nearly every environment.
On a domain, Group Policy Preferences has a Registry item under Computer or User Configuration, Preferences, Windows Settings. Choose Update rather than Replace so it creates the value if missing without deleting siblings, and use item-level targeting to limit it to the machines that need it. On Intune, use the settings catalog first; if the setting is not there, a remediation script pair detects the value and fixes it, and reports which devices it changed. Without either, a PowerShell script run from your remote management tool does the same job, provided it reports back.
The reporting is the part that gets skipped. A change pushed without an audit is a change you assume landed. The pattern that works is a short checklist:
| Step | What to do |
|---|---|
| 1 | Export the current value from a sample of machines before the change. |
| 2 | Push to a pilot group and confirm the setting behaves as expected. |
| 3 | Check nothing manages the same value: no GPO, no Intune profile, no app that rewrites it on launch. |
| 4 | Roll out with the type stated explicitly: DWORD, not a string. |
| 5 | Read the value back from every device and list the ones that differ. |
| 6 | Re-run the read-back monthly. Values drift when an app update or a technician changes them. |
The read-back is one line per machine:
powershellGet-ItemProperty -Path "HKLM:\SOFTWARE\Contoso\App" -Name AutoUpdate -ErrorAction SilentlyContinue | Select-Object @{n='Computer';e={$env:COMPUTERNAME}}, AutoUpdate
If you run OpenFrame, that is one script run across a client's devices with the output collected in one place, so the machines where the value is missing or wrong show up as a list rather than a surprise.
The registry is a database split into hive files, with machine settings in System32\config and each user's in their own NTUSER.DAT. Registry Editor writes every change the moment you press Enter, so export the key first, change one thing, and keep the .reg file to roll back. If a value keeps coming back, policy owns it and the fix lives in the GPO or Intune. Leave registry cleaners alone, and push fleet changes with a read-back so you know they landed.
When the change you need is a security setting rather than an app preference, the local security policy guide covers the console that writes those values for you.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.