Reg key write fails: 0X000003F5 fix

Quick answer: Right-click the parent key → Permissions → take ownership and grant Full Control to your user. If that fails, use PsExec -s regedit to run regedit as SYSTEM.

What's actually happening here is that Windows returned ERROR_CANTWRITE (0X000003F5) because the registry hive has a permission entry that explicitly denies your user write access, or the key's ACL is corrupted. This isn't a generic "access denied" — it's a lower-level write failure from the Configuration Manager inside the kernel. The registry is a transactional database, and when the security descriptor on a key is malformed or the parent key has a deny ACE (access control entry) for your SID, the system refuses to apply the write transaction entirely. You'll see this most often when trying to modify keys under HKLM\SYSTEM or HKLM\SOFTWARE after a third-party installer or admin script botched the permissions — I've had this happen after a misconfigured Group Policy Object or a failed driver install on Windows 10 22H2.

Step-by-step fix

1. Identify the exact key path that failed. Double-check the error message or your script's log — it's almost always a specific subkey, not the whole hive. Write down the full path like HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SomeService.
2. Open Regedit as Administrator. Don't just run regedit normally — right-click and select "Run as administrator." Even if your account is an admin, the registry can elevate token checks differently.
3. Navigate to the parent key (the one directly above the failing key). Right-click it → Permissions. If the error is on HKLM\SYSTEM\Foo\Bar, check Foo, not Bar.
4. Click Advanced → next to Owner, click Change. Type your username, click Check Names, then OK. Check "Replace owner on subcontainers and objects" → OK. This forces the owner to you, overriding explicit deny entries.
5. Now grant yourself Full Control. Back in Permissions, select your user → check Full Control. Also check "Replace all child object permission entries" if available. Apply.
6. Close regedit, reopen it (still as admin), and retry the write. If it works, you're done. If the error persists, the ACL itself might be corrupt — move to the next section.

Alternative: Use SYSTEM context

When permissions are too mangled to fix through the GUI, the cleanest workaround is to run regedit as the SYSTEM account — the operating system's highest-integrity context. SYSTEM can override most permission entries that aren't hard-coded by the kernel.

1. Download PsExec from Sysinternals. No install needed — unzip it to a folder.
2. Open an admin Command Prompt. Navigate to your PsExec folder.
3. Run: PsExec -s -i regedit.exe. The -s flag runs as SYSTEM; -i makes the window interactive so you can see it.
4. In this new regedit window, navigate to the failing key. You should now be able to write. Make your change, then close.

The reason step 3 works is that SYSTEM is the security principal that owns the registry hive files (like C:\Windows\System32\config\SYSTEM). When you run regedit as SYSTEM, the kernel's security reference monitor sees the subject SID as SYSTEM — which has implicit write access to all keys unless an explicit Deny for SYSTEM exists (extremely rare). This bypasses any corrupt user-level ACEs.

If both fail: Check for corruption

If even SYSTEM can't write, the registry hive itself might have a corrupt cell. Boot into Safe Mode (with Networking) and repeat step 3 above. In Safe Mode, the registry loads minimal hives, and corrupt cells that only manifest under full driver loads may be absent. If it works in Safe Mode, your issue is a third-party driver or service that locks the key — chase that down via msconfig selective startup.

Last resort: Export the entire branch you need to edit using reg export from a working system (same OS build), then import it via reg import while booted from a Windows Recovery Environment command prompt. This rewrites the cell structure from scratch.

Prevention tip

Never manually edit permissions on registry keys unless you're absolutely sure. One wrong click in Advanced Security Settings can create an unreachable deny ACE that survives OS reinstall on the same hive. If you're deploying registry changes via scripts, use reg.exe add with /f and /reg:64 flags instead of regedit — reg.exe handles ACL inheritance more gracefully. And always take a full backup of the hive (reg save HKLM\SYSTEM C:\backup.hiv) before poking around.