Feature Enhancement Request: RegCreateKeyEx()

[ChuckC]

WIL has both RegOpenKey() and RegOpenKeyEx(), with the latter exposing the desired access parameter of the underling Win32 API function RegOpenKeyEx[A|W]().  When it comes to creating a registry key, however, it only provides RegCreateKey(), and there are 2 parameters of the underlying RegCreateKeyEx[A|W]() that it does not expose.

One of the missing parameters is the desired access [samDesired] parameter that is exposed by RegOpenKeyEx().

The other one is the "dwOptions" parameter, which is a DWORD flags mask that allows 2 flag bits to be specified when creating a key.  One is for creating a key that is actually a symbolic link to another key, which is sometimes done to provide compatibility between old & new versions of an application when the old application cannot be modified to use a different registry key name.  The other key creation option flag can be highly useful, and it is the "volatile" flag.

When a volatile registry key is created, it exists in-memory, but is not persisted in any registry hive on disk.  A volatile registry key exists within the namespace associated with a registry hive, such as HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_USER, etc..., but it only exists for as long as that hive remains loaded in memory.  When the hive is unloaded, the volatile registry key an all subordinate keys & values cease to exist.  For a user's registry hive in their profile, the unload occurs when the user logs out.  For the local machine hive, the unload occurs when the system is shut down.


The situation in which I found myself needing to use a volatile registry key was to stash a flag value that needed to remain in existence until a system reboot had occurred.  The process that determines if the flag needs to be set can only be performed a single time, and the return value of a certain function only has meaning the first time that it is called when attempting to configure an instance of a mini-filter driver.  If that initial function call returns true, then the mini-filter driver cannot be used without a system reboot being performed.  However, the same function can be called multiple times and all subsequent calls after the first will not return meaningful results.

Rather than creating a temporary file somewhere on disk and then setting up something in the registry to delete the file on the next system restart, it was simpler to use a volatile registry key.

Of course, the WIL support for the CLR and .NET means that the underlying Microsoft.Win32.RegistryKey class could be used from within a WinBatch script, which is how I approached it over on the PowerShell side of things since PowerShell's registry support had the same limitation.  However, given that RegOpenKeyEx() exists, it might be convenient to have a RegCreateKeyEx() that permits both the create options and the desired access to be specified when creating a new registry key.

[td]

As always we appreciate thoughtful feedback. Your request will be added to the ever expanding list of feature requests.