Registry Virtualization in Windows 10

OK! I was just experimenting with the registry and discovered an undocumented/obscure fact.

The registry has in effect two local machines. The non-virtualized local machine is viewable from RegEdit, while the virtualized local machine is viewable from C# code. These two overlap, but not for custom keys. We already gave the example that if the Oyster key is written to the local machine with C# code, then it is it is not accessible by RegEdit. The converse also holds. If you write the oyster key to local machine in RegEdit,then C# code cannot access it.

This is some cases produces a dilemma! Which local machine should a custom key be written to? If the operating system needs to see the key, write the key in RegEdit. If your C# needs to see the key, write the key in C# code. You can't have it both ways where both the system and your code see the key!! There’s no way that isn’t a big bummer.

For example, let's say you are writing a desktop background menu with a submenu. Submenu commands must go to the command store in local machine. If you write the submenu items in RegEdit, all works well, but nothing works if you write the submenu items in C# code. The operating system does not know what your C# code wrote in local machine.

In my project this means I can't, based on client configuration input, automatically write to the registry behind the scenes with C# code to keep this stuff away from the client. I must instead write a reg file and ask the user to pretty please to click on it. Thus if I really wish to distribute this project, Microsof'ts virtualization of local machine forces me into a situation where I look unprofessional. The operating system doesn't care a whit about the changes my C# code makes to the registry-- the operating system simply ignores it.

Now lets say the client changes their mind after some time about configuration input. This means some registry keys in local machine will have to be deleted. But that's not possible from C# code because C# code does not have access to local machine keys written with a .Reg file. Thus one is forced to give the client directions on how to delete keys from the registry. This is simply unacceptable and so virtualization of local machine just becomes a big nasty mess in the circumstances where I need it to work.

P.S. One obvious cadidate solution to avoid registry virtualization is to have C# code execute a .Reg file. However, this doesn't work. If C# code runs RegEdit.exe or the alternate reg.exe, Microsoft is smart enough to shoot you down. Keys written to local machine will still be virtualized. You actually have to click on the reg file to avoid virtualization. That's the only route I have. Not as bad as I originally thought since Reg files can also delete keys.

If you both click on a reg file and run it in C# to establish a key in local machine, you get two results. The first is a non virtualized key, and the second is a virtualized key, that each live in their own separate worlds.

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Mark Willis8y ago
OK! I was just experimenting with the registry and discovered an undocumented/obscure fact.

The registry has in effect two local machines. The non-virtualized local machine is viewable from RegEdit, while the virtualized local machine is viewable from C# code. These two overlap, but not for custom keys. We already gave the example that if the Oyster key is written to the local machine with C# code, then it is it is not accessible by RegEdit. The converse also holds. If you write the oyster key to local machine in RegEdit,then C# code cannot access it.

This is some cases produces a dilemma! Which local machine should a custom key be written to? If the operating system needs to see the key, write the key in RegEdit. If your C# needs to see the key, write the key in C# code. You can't have it both ways where both the system and your code see the key!! There’s no way that isn’t a big bummer.
For example, let's say you are writing a desktop background menu with a submenu. Submenu commands must go to the command store in local machine. If you write the submenu items in RegEdit, all works well, but nothing works if you write the submenu items in C# code. The operating system does not know what your C# code wrote in local machine.

In my project this means I can't, based on client configuration input, automatically write to the registry behind the scenes with C# code to keep this stuff away from the client. I must instead write a reg file and ask the user to pretty please to click on it. Thus if I really wish to distribute this project, Microsof'ts virtualization of local machine forces me into a situation where I look unprofessional. The operating system doesn't care a whit about the changes my C# code makes to the registry-- the operating system simply ignores it.

Now lets say the client changes their mind after some time about configuration input. This means some registry keys in local machine will have to be deleted. But that's not possible from C# code because C# code does not have access to local machine keys written with a .Reg file. Thus one is forced to give the client directions on how to delete keys from the registry. This is simply unacceptable and so virtualization of local machine just becomes a big nasty mess in the circumstances where I need it to work.

P.S. One obvious cadidate solution to avoid registry virtualization is to have C# code execute a .Reg file. However, this doesn't work. If C# code runs RegEdit.exe or the alternate reg.exe, Microsoft is smart enough to shoot you down. Keys written to local machine will still be virtualized. You actually have to click on the reg file to avoid virtualization. That's the only route I have. Not as bad as I originally thought since Reg files can also delete keys.

If you both click on a reg file and run it in C# to establish a key in local machine, you get two results. The first is a non virtualized key, and the second is a virtualized key, that each live in their own separate worlds.
Mark Willis8y ago
OK! I think the situation is hopless.

For example, let's write the "Oyster" Key under HKEY_LOCAL_MACHINE\Software:

RegistryKey key = Registry.LocalMachine.OpenSubKey("Software", true);
RegistryKey newkey = key.CreateSubKey("Oyster");

You will not find the "Oyster" key in regedit, but the key still exists. I did a C# search of the registry and could not find the key anywhere else except at HKEY_LOCAL_MACHINE\Software\Oyster, where it was originally written. So finding the key under the virtual store at HKCU\Softwate\Classes\VirtualStore is a thing that happens only in older versions of Windows.