Filtering Registry Operations on Application Hives
User-mode applications use application hives in the registry to store app-specific state data.
A registry filter driver receives calls to its RegistryCallback routine for registry operations on application hives. These calls do not distinguish between registry operations on application hives and operations on other types of registry hives.
To load an application hive, an app calls RegLoadAppKey.
Application hives are loaded under
\\REGISTRY\\A instead of under
Note that there is no way to traverse
\\REGISTRY\\A. An attempt to open a key under \REGISTRY\A fails with error status STATUS_ACCESS_DENIED.
To access a key in an application hive, an app uses the handle that it receives when it calls RegLoadAppKey.
The operating system automatically unloads the application hive after all of the handles to the hive are closed.
In contrast to other types of registry hives, for which each key is secured with its own security descriptor, the security of an application hive is based on the hive file's security descriptor. This means that:
- An attempt to set a security descriptor on an individual key in an application hive fails with error status STATUS_ACCESS_DENIED.
- An entity that is successful in loading the hive can modify the entire hive.
Registry filter drivers that handle create-key and open-key operations (which are indicated by the RegNtPreOpenKey, RegNtPreOpenKeyEx, RegNtPreCreateKey, and RegNtPreCreateKeyEx notification values) must
take care not to use an absolute path (one starting with
\\REGISTRY\\A\\) to open an application hive; only the registry manager can do this.
If a registry filter driver tries to open an application hive in this way (for example, by calling the ZwOpenKey routine), the operation fails with
error status STATUS_ACCESS_DENIED.
Submit and view feedback for