Layers

If a successful write does not change the value you read, inspect the winning layer before writing again:

reg get Machine/System/KMES BufferCapacity -L
reg layer ls -l

Registry Editor shows the winning layer in the value pane and the layer list under Layers…. Neither interface currently shows the complete set of shadowed entries for a value.

What a layer retains #

A layer groups registry entries so they can be enabled, disabled or removed together. Each layer retains at most one entry for a particular value name on a key. Another write in the same layer replaces that entry; layers are not a history of every edit.

The default write destination is base. Use --layer NAME or Registry Editor's Writes go to control to select a different destination. Check the destination before changing or deleting anything.

How the winner is chosen #

For each value separately, the registry selects among active entries:

1. Highest precedence wins.
2. At equal precedence, the latest write sequence wins.

A read returns that effective winner. A winning tombstone instead makes the value absent. The same ordering also governs layered key names.

Equal-precedence layers can each win different values #

Base and role layers normally use precedence 0. Neither is permanently above the other. If base writes one value last and a role writes another last, each wins its own value. Layer creation order does not establish a fixed order for all their settings.

This also means a later role update can supersede an earlier local edit at the same precedence. Record the winning layer for the specific setting rather than assuming all settings come from one layer.

When precedence really does differ #

A higher-precedence entry wins even over a newer lower-precedence entry. Rewriting base does not defeat policy above precedence 0.

Creating or raising a layer above 0 requires SeTcbPrivilege in addition to the relevant key rights. Administrator membership alone does not supply that privilege. Do not change layer precedence as a shortcut around a policy decision; use the responsible policy or role's management path.

Sequence numbers are ordering information #

Write order is a monotonic sequence, not the key's wall-clock last-write time. Changing the clock does not make an older entry win.

reg get -L exposes the winning sequence. Conditional writes check the destination layer's entry, so a winner from a different layer is not a usable version of your own layer's value. See Transactions.

It is not only values #

Layers can create or hide key names and mask individual or all values on a key. Removing a marker lets the remaining entries compete again; it need not leave the key or value absent. Read Deleting keys and values before choosing between delete, mask and hide.

Where to go next #

• Disable or remove a layer and verify recovery
• Key and layer permissions
• LCS resolution algorithm and sequence counter for implementation detail

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 #

1. Run reg layer ls -l and inspect important values with reg get KEY NAME -L.

2. 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.

3. If appropriate, disable the layer to stop its entries participating in ordinary resolution while retaining them:

   Copy

   reg layer set NAME --disable
   

4. Re-read the affected keys. The next winning entries may become visible, or values and keys may become absent. Verify the consuming services again.

5. Re-enable with reg layer set NAME --enable if that is the intended recovery. Delete with reg layer del NAME only 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.

Where to go next #

• Remove one value or key entry
• Restore a subtree from a backup
• Understand security changes that outlive layers

Before deleting, inspect the current value and its winning layer. A registry deletion normally removes an entry in the selected layer; a remaining entry can become visible afterward.

Choose the operation you mean #

KEY, NAME and LAYER are placeholders. Masking and hiding still obey precedence and write order; they do not ignore stronger entries. reg unmask and reg unhide remove the selected layer's markers. reg mask KEY --all applies a blanket tombstone to values on that key. See the reg reference.

Hive roots cannot be deleted or hidden.

Deleting values #

1. Read reg get KEY NAME -L and confirm the destination layer.
2. Remove only the intended layer's entry.
3. Read the value again. It may be absent or replaced by another winner.
4. Verify the consumer's response. Absence may select a default or retain a prior runtime setting, depending on that component's documented behavior.

Do not assume deleting the effective value restores its compiled default. Do not use deletion to probe for hidden entries on a live system.

Deleting a populated key #

The kernel's single-key delete refuses visible child keys, but the tools provide recursive deletion:

• reg del KEY -r --layer LAYER walks the subtree and deletes in a transaction. It deletes links without following their targets.
• Registry Editor's Delete key… deletes the shown key and its subtree after confirmation. Check Writes go to first.

Inspect the subtree with reg tree KEY --values and save an appropriate backup before proceeding. The command opens the keys before deleting; file-descriptor and transaction limits can cause the whole operation to be refused. See reg del for the documented limits.

reg del -r prompts only when input is a terminal, unless the prompt is explicitly skipped. Non-terminal input proceeds without confirmation. A failure before commit aborts the batch. After a commit timeout or source failure, inspect state before retrying; an error does not prove rollback.

Deleting out from under an open handle #

An open handle refers to a key object, not just its name. Removing its last name does not revoke existing handles: their reads, writes and watches can continue while the object remains open. New opens by the removed path fail, or resolve another key if layers provide one.

If a service must use a replacement key, it may need to reopen it through its documented reload or restart procedure. The LCS deletion reference covers object lifetime.

Permission #

Deleting or hiding a key requires DELETE on that key. Deleting or masking a value requires KEY_SET_VALUE on its key. Layer-targeted operations also require permission to write into the layer. Parent permissions alone do not establish access to descendants.

Where to go next #

• Recover using a layer
• Key and layer access checks
• Verify the consumer after a change