Advanced

A service or sandbox can see different registry data from an administrator looking up the same path. Before concluding that the store is inconsistent, check whether the workload uses a private hive or private layer through its effective thread credentials.

This page explains the diagnostic distinction. It does not provide a command for creating private views; reg does not manage their attachment. Use the workload's documented isolation mechanism and the technical references below.

Private hives #

A private hive is visible to threads whose tokens carry its scope identity. Private hives are considered before global hives, so a private Machine can shadow the global Machine for that thread without changing the path.

An operator reading the global path therefore has not necessarily inspected the workload's configuration. Identify which credentials and scope the workload actually uses before comparing values or planning recovery. Do not assume a global-hive backup captures a separate private hive.

Private layers #

A disabled layer can be active for a thread whose credentials name it. It then competes using the normal precedence-and-write-order rules. Disabling it globally does not remove it from those private views.

This is per thread, not necessarily per process: different impersonation tokens can give threads in one process different views. Check the relevant request or service identity rather than only the process's nominal identity.

Typical uses are session-specific overrides, test settings and sandbox configuration. Those uses do not establish who may attach a private view.

Authorisation lives in KACS #

The token mechanism governs attachment. The kernel TRM documents scope GUIDs and private-layer names entering credentials at token creation, gated by SeCreateTokenPrivilege. That is a broad token-creation gate, not per-scope ownership authorization.

With the PEI-268 kernel fix, attaching a layer above precedence zero also requires enabled SeTcbPrivilege on the token's creator. That authorization stays with the attachment, so an ordinary process can use a view deliberately delegated by a trusted service. An attachment made without that authorization cannot gain high-precedence access through a later layer promotion: registry operations using that attachment fail with EPERM while the layer is above zero. Older kernels lack this check.

Use the private-hive and private-layer TRM sections for the credential model and its documented limitations. Configured limits can also reject a registry operation when the token carries too many scopes or private layers; this is not automatically a key-permission problem.

Where to go next #

• Effective values and layers
• Key and layer permissions
• Private-layer attachment and limits

Use a transaction when several registry changes must become visible together. reg apply and Registry Editor's Import… provide an operator-facing way to apply a registry document as one batch.

Apply one reviewed document #

Prepare or review a JSON registry document, then apply it with:

reg apply reviewed.json

reviewed.json is your reviewed file. All its operations must target one hive; cross-hive batches are rejected even if both hives use the same source. JSON is supported input; text-format batch input is not implemented.

reg export --json KEY FILE creates a reviewable starting point containing keys and effective values. It does not export key descriptors. A manually prepared document can include descriptor changes, which must be reviewed as security changes and need the relevant rights. See reg apply for its schema and version caveat for descriptor support.

A successful transaction publishes its changes together. Other readers do not see intermediate writes; reads inside a bound transaction see their own pending writes. This is registry atomicity, not a guarantee that all consuming services will apply the new configuration simultaneously.

Limits worth knowing #

• One hive per batch. Cross-hive atomicity is not available.
• Directory imports are separate batches. reg apply --dir DIR applies each file in its own transaction; the directory is not one atomic unit.
• No nesting or savepoints. Keep each document's recovery scope clear.
• Bounded time and size. A transaction can time out or exceed resource limits. reg apply errors need investigation, not an assumption that splitting the file preserves its consistency requirements.
• Source support is required. A source can reject the needed transaction mode; the default loregd supports transactions.

Atomic changes and removable changes are different #

A role can use a transaction to apply related registry entries together and a layer to keep those entries removable later. A transaction does not select the winning layer or create a history of previous states. Layer removal also does not undo a key's descriptor changes.

Review layer recovery separately from whether the original write was atomic.

Avoid overwriting another writer #

Transactions are not value-level conflict detection. If your change depends on a value remaining unchanged since you read it, use the conditional-write mechanism rather than assuming the transaction protects that read.

reg set --expected-seq N checks the destination layer's own entry. A mismatch returns exit status 6 without the write. reg get -L shows only the effective winner, so its sequence is suitable only when that winner is in your intended destination layer. It does not expose a shadowed layer's sequence.

If a commit times out #

A source failure returned during commit can also follow a successful storage commit. Check current state before resubmitting a batch after such an error.

A late successful response can publish the committed change and notify watchers even after the caller was told it timed out. Closing an uncommitted transaction normally aborts it, as does process exit, but that is not a way to undo an already-dispatched successful commit.

The LCS commit and failure reference describes these outcomes. After a successful batch, use the same consumer verification as for a single write.

Where to go next #

• reg batch formats and exit statuses
• Restore a saved subtree
• LCS transaction scope and lifetime
• Isolation and conditional writes

A registry link redirects a key path to another key. A normal open follows it, so an inspection may show the target's values rather than the link's own stored target. Check which object you are operating on before changing or deleting a link.

Inspect the link without following it #

For a suspected link at KEY, use:

reg info KEY --no-follow
reg get KEY @ --no-follow

Replace KEY with the actual path. The first shows the key's metadata, including its link flag; the second reads its unnamed target value. Add -L to the value read to see the winning target's layer and sequence. Omitting --no-follow follows the link by default.

These are inspection commands. Do not assume an option documented for get and info is available on every mutating subcommand. Check the reg command reference before changing a link itself.

What makes a key a link #

A link has both a fixed link flag set at creation and an unnamed default value of type REG_LINK containing an absolute registry target path. A REG_LINK value alone does not turn an ordinary key into a link.

This is the exception to the registry's ordinary opaque-data behavior: LCS reads the target during path resolution. The handle returned by a normal open refers to the resolved target.

Creating a link is privileged #

The command form is reg link KEY TARGET. Creation requires KEY_CREATE_SUB_KEY and KEY_CREATE_LINK on the parent, plus either SeTcbPrivilege or Administrator membership, in addition to applicable layer rights. Use it only when redirecting that namespace is intended.

Targets are followed literally. CurrentUser is not expanded inside a link target, so do not use it expecting a caller-specific user redirect. Resolution has a hop limit; cycles fail rather than loop indefinitely.

Layers can redirect a link #

The default target value is layered. A higher-precedence or later same-precedence write can change where the link resolves. Removing that entry lets the next winner determine the target; it need not be the historical target you expected.

A winning default value whose type is not REG_LINK can make resolution through the still-flagged link fail. Inspect the link with --no-follow and check the target's winning layer before attempting a repair. Verify both the stored target and the intended resolved key after recovery.

Where to go next #

• Layer selection
• Deletion, including recursive tools that do not follow links
• LCS symlink implementation and ABI for programmatic link handling