Backup and restore is the feature nobody thinks about until the moment it has to work. For a tool that edits the Windows registry, “restore” is the entire safety story, and it is also where naive implementations quietly fail — a .reg file in the wrong encoding, or a single multi-hive import that aborts halfway and loses changes it could have applied.
ContextCleaner’s backup and restore is engineered specifically around those failure modes. This deep dive walks through how it exports backups, why the encoding matters, how it splits a restore by registry hive so a permission problem in one part never sabotages the rest, and how it elevates just the part that needs administrator rights through an inline UAC prompt. It is written for power users, IT pros, and developers who want to know the mechanism.
What a backup actually captures
When ContextCleaner creates a backup — automatically before every Apply, or manually with an optional note — it exports the registry keys relevant to the context menu using the built-in reg export command. Two key ranges are captured:
HKCU\Software\Classes— the per-user shell tweaks ContextCleaner writes (hides, promotes, demotes)HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Shell Extensions— the machine-wide shell extension state, including the block list
Using the system’s own reg export rather than a third-party crate keeps the dependency surface small and produces standard .reg files that are valid independent of ContextCleaner — your backups are portable artifacts, not a proprietary format locked to the app.
Each export is combined into a single snapshot file under your app data backups directory, timestamped, and listed in the Backup & Restore view with its size and any note. If neither key can be exported — for example, an unelevated session that cannot read a machine-wide key — the app surfaces the error instead of silently writing a header-only stub that would “restore” nothing. A backup that cannot capture data is reported as a failure, not a false success.
Why the encoding is not a footnote
Here is a detail that breaks a surprising number of hand-rolled registry backup scripts: reg import requires UTF-16 LE with a byte-order mark. Feed it a UTF-8 .reg file and it fails with the famously unhelpful “Error accessing the registry.”
reg export writes UTF-16 LE with a BOM and a Windows Registry Editor Version 5.00 header in every file. ContextCleaner exports the two key ranges separately, decodes each from UTF-16, strips the redundant header, concatenates the bodies under a single shared header, and writes the combined file back out as UTF-16 LE with a BOM — precisely the encoding reg import accepts.
This is not theoretical polish. Importing a UTF-8 .reg file was the exact cause of a restore failure this encoding handling fixes. When you are relying on a backup, the encoding being correct is the difference between recovery and a cryptic error at the worst possible time. The reader side is equally defensive: it detects and strips a UTF-16 LE or BE BOM, and falls back to a lossy UTF-8 decode for older backups so it never hard-fails on an odd encoding.
The real problem: one file, two hives
A context menu backup spans more than one root hive — per-user HKCU and machine-wide HKLM. This is where the naive approach breaks.
reg import processes a file in a single pass. If you hand it a combined file containing both an HKCU section and an HKLM section, and you are running unelevated (the normal case), the import hits the HKLM section, fails for lack of administrator rights, and aborts the entire operation with “Error accessing the registry.” The per-user changes that could have applied are lost along with it. The user clicked Restore, got an error, and recovered nothing — even though the part that mattered to them was writable.
That is a genuinely bad outcome for a safety feature, and it is the central problem ContextCleaner’s restore is designed to solve.
🛍️ Get the safety net that works — ContextCleaner on the Microsoft Store →
Per-hive splitting
Instead of importing the whole file at once, ContextCleaner parses the backup and splits it by root hive. It walks the .reg document line by line, and whenever it sees a [key] header it determines which hive that header belongs to — HKLM, HKCU, HKCR, HKU, HKCC, or other — and routes that header and all of its values, blank lines, and multi-line continuations into that hive’s bucket.
Each hive’s section is then written to its own temporary .reg file (with a fresh header and correct UTF-16 encoding) and imported independently. A failure in one hive no longer blocks the others. If HKLM cannot be written because the session is unelevated, the HKCU section still restores. The user gets back the per-user changes that were always within reach, instead of an all-or-nothing failure.
The restore returns a structured report listing which hives imported successfully, which required elevation, and which failed and why. That lets the app distinguish three honest outcomes: full success, partial success, and hard failure — and tell the user which one actually happened.
Inline elevation instead of “relaunch as administrator”
When a section genuinely needs administrator rights — HKLM, HKCR, and other machine-wide or cross-user hives — the clumsy solution is to make the user close the app and reopen it as an administrator, then redo the restore. ContextCleaner avoids that.
For a hive that needs elevation, it retries just that section through a standard Windows UAC prompt, launching an elevated reg import for only that one temporary file. Mechanically, it uses PowerShell’s Start-Process -Verb RunAs, which raises the normal Windows consent dialog, then waits for the elevated process and propagates its exit code. You approve the elevation inline, for only the part that needs it, and the rest of the restore proceeds without interruption.
Declining is handled gracefully too. If you dismiss the UAC prompt, Windows reports ERROR_CANCELLED (1223), which ContextCleaner maps to a clear “administrator approval was declined” message rather than a generic failure. You always know whether a section failed because of a real error or because you chose not to elevate it.
How it fits the larger safety model
Backup and restore does not stand alone; it is one layer of a deliberately redundant safety system:
- Automatic backup before every Apply, so a snapshot exists before any change — and if that backup fails, the apply aborts rather than proceeding unprotected.
- A 10-step in-memory undo stack for quick reversals without touching files.
- One-click restore from any snapshot, with the per-hive and inline-elevation behavior above.
- A tamper-evident audit log recording every backup and restore, including the per-hive result, so you have a verifiable history of recoveries.
Each layer covers a different failure mode. The undo stack is for “I just did that and want it back.” The snapshots are for “return me to how things were earlier.” The per-hive, encoding-correct, elevation-aware restore is for “make sure that recovery actually works when I need it.”
Frequently asked questions
Why do my backups use the .reg format?
So they are standard, portable Windows registry files that work independently of ContextCleaner. The app uses the built-in reg export/reg import tooling, which keeps the implementation lean and means your backups are not locked into a proprietary format.
What was the encoding bug, and is it fixed?
reg import only accepts UTF-16 LE (with a BOM). A .reg file written as UTF-8 fails with “Error accessing the registry.” ContextCleaner writes backups in the correct UTF-16 encoding and decodes UTF-16 (and legacy UTF-8) on read, so restore works reliably.
What happens if part of my backup needs administrator rights?
ContextCleaner imports each registry hive separately. The per-user (HKCU) section restores immediately; if a machine-wide (HKLM) section needs elevation, it raises a single inline UAC prompt for just that part. Declining only skips that section — the rest still restores.
Do I have to relaunch the app as administrator to restore?
No. That is exactly what the inline elevation avoids. You approve a UAC prompt for only the section that needs it, without restarting the whole application.
What if a restore only partially succeeds?
The restore returns a per-hive report, and ContextCleaner distinguishes full success, partial success, and hard failure. It tells you which hives were restored and which were skipped or failed, and records the outcome in the audit log.
The bottom line
ContextCleaner’s backup and restore is built around the failure modes that sink naive implementations: it writes .reg snapshots in the UTF-16 encoding reg import actually requires, splits a restore by hive so a permission problem in HKLM never aborts your HKCU recovery, and elevates only the section that needs it through an inline UAC prompt. The result is a safety net that holds when you actually fall into it. Read the full technical specifications on the ContextCleaner product page.