What layers are for
Use layers to keep a set of configuration entries removable as a group. Before disabling or deleting one, identify what manages it and take a backup of the affected configuration. Removing a layer changes every entry tagged with that name, not just the key you were inspecting.
Recover from a layer change #
-
Run
reg layer ls -land inspect important values withreg get KEY NAME -L. -
Confirm the layer is the intended one. For a managed role or policy, use its management workflow so registry state and its owner remain in sync.
-
If appropriate, disable the layer to stop its entries participating in ordinary resolution while retaining them:
-
Re-read the affected keys. The next winning entries may become visible, or values and keys may become absent. Verify the consuming services again.
-
Re-enable with
reg layer set NAME --enableif that is the intended recovery. Delete withreg layer del NAMEonly when its entries should be removed permanently.
Replace NAME with the layer you reviewed. Disabling is not a security
boundary: a disabled layer can still participate for threads whose
credentials name it as a private layer.
reg layer del asks for confirmation on a terminal. With non-terminal
input it proceeds without that prompt. Do not rely on a prompt to protect
an unattended script.
The base layer #
base always exists, is enabled at precedence 0 and cannot be disabled
or deleted. Writes go there unless you choose another layer. Repeating a
write in base replaces base's previous entry, so deleting another layer
cannot recover an older base edit.
Absence can also come from a layer #
A tombstone competes as "no value here". A blanket tombstone does this for all values on a key; a hidden-key entry masks a key name. Removing their layer lifts those markers, so configuration previously hidden can reappear. See delete, mask and hide.
Roles #
A role can put its registry configuration into a layer. Removing that layer withdraws its entries and leaves the remaining entries to resolve. This does not restore a historical snapshot of the entire machine: other writers may have changed configuration since the role was installed. A transaction is the separate mechanism for applying related registry changes together.
Group Policy #
Higher-precedence policy continues to win over local edits, regardless of write order. Lifting a policy layer lets remaining configuration resurface. Confirm the intended policy through its management workflow; do not try to defeat it with repeated base-layer writes.
What layer removal cannot recover #
Layer removal also does not undo actions already taken by a service, nor make a consumer accept the values that resurface. It is not a transaction, a version-history browser or a substitute for a backup.
A backup of an application's subtree preserves its tagged entries but
may not include the layer definitions under Machine\System\Registry\Layers.
After layer deletion, such a backup alone may leave the restored entries
inactive. Read backup scope and layers
before relying on that recovery path.