Where is the hidden metadata in the Windows registry, how to view it, how to edit it?

I'm going to spare you the gory details of my troubleshooting. I am digging in to more detail about why the problem and solution described here actually works: "The operating system is not presently configured to run this application." The suggestion, in essence, is to delete the reg key: HKCU\Software\Classes\VirtualStore\MACHINE. This solution works. I determined that HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Microsoft is the actual key that needs to be deleted.

However, the key can be completely emptied of any keys and values, and the app still fails. But, if I rename the original key and create a new key with the same name, the app works. All permissions and ownership are the same.

The sample registry tree looks like this:

VirtualStore
|-MACHINE
  |-SOFTWARE
    |-Microsoft
    |-Microsoft.working

As I swap the two key names between Microsoft and Microsoft.working the application will start or stop working as well. If I export the original, non-working Microsoft key, delete it, then import it back, the application will work now.

Now, obviously there is metadata on the original key I am not privy to. What is it? Where is it? How do I view and edit it? I am positive the key has a unique identifier that is linking it somewhere else, like a primary key in a database. This key is part of the Registry Virtualization in the operating system.

Appleoddity

Posted 2019-10-23T20:50:27.663

Reputation: 9 360

Probably the permissions (only keys have permissions, not individual values). Use regedt32.exe not regedit.exe, the former tool knows how to view and edit permissions. – Ben Voigt – 2019-10-23T20:56:14.780

@BenVoigt Thank you. I indicated the permissions and ownership are the same. – Appleoddity – 2019-10-23T20:57:32.067

There's also a "class" prompt when you create a registry key (corresponds to fourth parameter of RegCreateKeyEx() function). Perhaps that isn't matching. The RegQueryInfoKey function can tell you what this is set to; I don't believe it can be viewed by the Registry Editor program (either version) bundled with Windows. – Ben Voigt – 2019-10-23T21:02:03.027

@BenVoigt Yes. There is a Class Name property. That can be viewed by exporting from regedit to a .txt file. The property is <NO CLASS> on all the keys in question. – Appleoddity – 2019-10-23T21:03:38.847

I suggest running the application while Process Monitor is recording and seeing where the registry access pattern changes between the two runs (working and non-working). The particular access performed, along with the difference in the error code or return code, may give a clue as to the difference that exists in the registry. – Ben Voigt – 2019-10-23T21:23:04.330

Regedit32.exe, where is that? Not in W7 or 10. – Moab – 2019-10-23T21:30:38.947

1Regedt32 (no "i") was removed in a recent Windows version, as the standard Regedit fully knows how to change key permissions. – user1686 – 2019-10-23T21:31:51.810

Ah, no i, D'oh! – Moab – 2019-10-23T21:34:49.673

@BenVoigt I said I would spare the gory details of troubleshooting. You are correct. There is a difference in access pattern to these keys. This is part of the operating system registry virtualization. The operating system redirects reads/writes from HKLM to the original key mentioned. The OS does not redirect read/writes to the new key. That is why I said it is clearly linked via a UID. The OS knows it is different. In the interest of keeping things simple I’d like to answer the question of metadata that is beyond a doubt present and so far appears undocumented. – Appleoddity – 2019-10-23T23:26:22.210

@Appleoddity: The evidence doesn't support your idea of a UID (or inode number, or anything that identifies the key besides its path) If there were one, the behavior wouldn't be affected by your switching the names. But the key is being found by name, and only by name. Then some additional tag (which is not an identifier, the name is the only identifier) is causing it to be used during virtualization or not. – Ben Voigt – 2019-10-24T03:56:38.937

Have you tried the reg flags command mentioned at https://docs.microsoft.com/en-us/windows/win32/sysinfo/registry-virtualization ? Apparently it uses an undocumented function NtSetInformationKey() in ntdll.dll (There is a documented API for changing flags in an offline registry hive... ORSetVirtualFlags)

– Ben Voigt – 2019-10-24T04:00:01.467

@BenVoigt yes. They can only be applied to HKLM\Software. I played with them on the redirected keys, the OS continued to redirect the keys no matter what flags were set. This indicates to me once the redirection is in place it stays in place until the destination keys are deleted such as what I did in my post. I think the core problem is actually related to misconfigured flags. The OS was never supposed to redirect the ClickToRun folder. Once it does, the application breaks. A computer without the problem has the flags set properly through inheritance. The bad computer does not. – Appleoddity – 2019-10-24T04:05:13.247

Where is the hidden metadata in the Windows registry, how to view it, how to edit it?

No answers