Undestanding 'Merged View of HKEY_CLASSES_ROOT'

Here's Microsoft's documentation: Merged View of HKEY_CLASSES_ROOT - Win32 apps it was updated in 2021.

My understanding of the merge process has always been that everything from HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes is included in HKEY_CLASSES_ROOT. Except 'If the values of entries in the two Classes subkeys conflict, then only the value in HKEY_CURRENT_USER\SOFTWARE\Classes appears in HKEY_CLASSES_ROOT.'

So, what does this mean:

In particular the last sentence: "The merged view does not include the HKEY_LOCAL_MACHINE contents of duplicate subkeys.". This suggests to me that given the correct set of keys in HKEY_CURRENT_USER\Software\Classes, then values in those keys from HKEY_LOCAL_MACHINE wouldn't appear in HKEY_CLASSES_ROOT. But surely that can't be true.

Anybody have an explanation?

I don't see a contradiction. The cardinal rule for Windows policy is whenever there are (supported) duplicate keys between HKLM and HKCU, the user preference (HKCU) will win. 3rd-party apps can read from whatever keys they want, but Windows features must follow this rule.

Therefore HKR throws out duplicate keys by allowing the HKCU instances to win.

HKR is a synthetic view, just like HKCU. Both are generated dynamically from different hives. The CU in HKCU is your user profile. Someone else can have a totally different user hive, and their presented HKR would be different from your HKR.

The immediate subkeys of these keys from the HKEY_LOCAL_MACHINE tree are included in the merged view only if they are not duplicates of immediate subkeys from the HKEY_CURRENT_USER tree. [HKLM version wins if HKCU is empty]

The merged view does not include the HKEY_LOCAL_MACHINE contents of duplicate subkeys. [HKLM loses in a conflict]

Click to expand...

Excellent explanation, @garlin You taught me something.

A late reply - I've been unwell.

Thanks @garlin for responding. I'm still mystified by this.


The values in HKEY_LOCAL_MACHINE duplicate subkeys are always included in HKCR. The only way in which HKCU wins is that if the same value is written in HKCU, HKCR returns the data from HKCU.

Skeptic Mike said:

Here's Microsoft's documentation: Merged View of HKEY_CLASSES_ROOT - Win32 apps it was updated in 2021.

Click to expand...

I checked by looking at 2003 platform SDK, and the contents dated March 2005 are identical, except for the example which is wrongly formatted in the current version. (Missing newlines and indenting.) I haven’t found anything earlier, although I assume that there must have been some discussion about the merging which was introduced in Windows 2000.

I don't think there's any reason to take this further. I think that I understand how HKCR works, I just can't understand a small part of the documentation.