Full Context Menu tweak not working for All Users (HKU/Default), works fine for HKCU

Recently I used the known tweak to enable the full context menu in Windows 11 on my work laptop, and it worked as advertised, no problems at all. I understand that this tweak will only change the context menu for the currently logged in user (ME), hence modifying HKCU....

Reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" /ve /t REG_SZ /d "" /f
Reg.exe add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /ve /t REG_SZ /d "" /f
(Restart explorer.exe or reboot laptop)

What I want to do is modify the default profile so that all new users logging in will also have the full context menu. In theory I should be able to load the default user hive, modify/add the same key, then unload the default user hive.

reg load HKU\temphive c:\Users\default\ntuser.dat
reg add "HKU\temphive\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}" /ve /t REG_SZ /d "" /f
reg add "HKU\temphive\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /ve /t REG_SZ /d "" /f
reg unload HKU\temphive

I also tried HKLM\Default.... as I've seen that being used to modify the default profile hive as well.....same results.

This process worked fine for the Left Start Menu tweak (all users have the Start menu on the left side of the taskbar). It does NOT work for the Full Context Menu. The registry key is changed in HKU\Default but when I log in as a different user (new user) the context menu is the standard Windows 11 mess. Looking in the new user's registry hive the setting is NOT being propagated from HKU\DEFAULT as it should be.

Has anyone out there been able to defeat this issue? Strange how modifying the Default Hive works for some keys and not for others.
Thanks in advance!!!

Hello, and welcome.

As a test, use the Enable_Show_more_options_context_menu.reg download in option 1 below first to clear the registry key, then use the Disable_Show_more_options_context_menu.reg file to disable "Show more options".

Afterwards use step 7 to apply and see if that may work for you.

The original fix, involved downloading a little script that did the dirty deed., and restored the full Right Click Context Menu.
That obviously worked for at least Some People, but not for me.

So I resorted to Plan B, entering the appropriate line of text at a command prompt. And, that worked.
I was confused by the terms "Disabled" and "Enabled". It seems like those terms should be reversed. Eh?

It's beyond my comprehension, why MS had to mess with something, like the Context Menu, that has worked just fine for many years and many versions of Windows. They just don't know when to leave well enough alone.

TM

This is exactly the process I used above....works fine for the currently logged in user, but when importing the same keys to the default user hive the setting does not get applied to new users.

Unfortunately not. Only current user so far.

DHC2Pilot said:

This is exactly the process I used above....works fine for the currently logged in user, but when importing the same keys to the default user hive the setting does not get applied to new users.

Click to expand...

Let me know if this works for you as it works for me

I know this is an old thread but I was looking for this answer myself, and this thread showed up at the top of my search without one..

The HKCU keys you are adding, are only overriding the actual systemwide key for each user. If you want this to be the default behavior for all users, change the main key.

You will need SetACL to gain permission to edit the key (or any other method to take ownership of the key): https://helgeklein.com/downloads/SetACL/current/SetACL 3.1.2 (executable version).zip

The following commands can be used from an administrator cmd prompt (from a folder containing SetACL) to make the changes and backup the original key to your desktop.


You will need to log out and back in/restart to see changes.

BobOmb said:

I know this is an old thread but I was looking for this answer myself

Click to expand...

DHC2Pilot said:

reg load HKU\temphive c:\Users\default\ntuser.dat

Click to expand...

Was the OP loading the right hive?
I think the Registry Keys required by the OP are only given in UsrClass.dat rather than NTUser.dat
reg load HKU\DefaultClasses C:\Users\Default\AppData\Local\Microsoft\Windows\UsrClass.dat
and that can be checked by browsing down through the loaded HKU\DefaultClasses hive.


On a minor note, this should be run at the end
reg unload HKU\DefaultClasses



Denis

I do not see UsrClass.dat in current Win11 install.wim(s) in that location. How would we bake this into an image without the HKLM key? (Which appears to work universally)

I know nothing about the contents of wim files.

But I've checked further and that UsrClass.dat file does not exist in the C:\Users\Default\AppData\Local\Microsoft\Windows folder.
C:\Users\%Username%\AppData\Local\Microsoft\Windows\UsrClass.dat exist for the currently logged on user but not for other [previously logged on] users.
So I have no idea how the job can be done.


Denis

It is only a system that has not been run yet. Your C:\ before it's first run when no users have been created yet. A "Windows Image"

If the file is not there, it comes from somewhere else, or is generated at boot.

I almost want to test importing a UsrClass.dat into the default users appdata folder to see if it gets overwritten or used during install, but even if that works, editing a key is better than creating an entirely new file..

BobOmb said:

I almost want to test

Click to expand...

Bob,

I think that might well be a useful test.
Given that there was no UsrClass.dat for my other users, perhaps a new UsrClass.dat is spawned at every login so its data resides in the ntuser.dat after all??????

I thought that somebody knowledgeable in TenForums had posted about that UsrClass.dat file but the only note I can find at the moment is
Edit Classes-Registry of other users - Stack Overflow
and, more generally for your offline editing,
Edit Registry on an Offline Image [DISM] - TenForumsTutorials {there does not seem to be an ElevenForumTutorial yet}
Modify Registry from InstallUSB [SIW2 #19] - TenForums


All the best,
Denis

It appears UsrClass.dat is a compatibility remnant used for pre-vista software writing to non user based registry hives.

Source (MS) Registry Virtualization - Win32 apps :
*copy/paste consolidated for context

Prior to Windows Vista, applications were typically run by administrators. As a result, applications could freely access system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access rights. Windows Vista and later versions of Windows improve application compatibility for these applications by automatically redirecting these operations. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user's profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).

Registry virtualization is enabled only for the following:

• 32-bit interactive processes.
• Keys in HKEY_LOCAL_MACHINE\Software.
• Keys that an administrator can write to. (If an administrator cannot write to a key, then the application would have failed on previous versions of Windows even if it was run by an administrator.)

If the caller reads from a key that is virtualized, the registry presents a merged view of both the virtualized values (from the virtual store) and the non-virtual values (from the global store) to the caller.

For example, suppose HKEY_LOCAL_MACHINE\Software\AppKey1 contains two values V1 and V2 and that a limited user writes a value V3 to the key. When the user attempts to read values from this key, the merged view includes values V1 and V2 from the global store and value V3 from the virtual store.

Note that virtual values take precedence over global values when present. In the example above, even if the global store had value V3 under this key, the value V3 would still be returned to the caller from the virtual store. If V3 were to be deleted from the virtual store, then V3 would be returned from the global store. In other words, if V3 were to be deleted from HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1 but HKEY_LOCAL_MACHINE\Software\AppKey1 had a value V3, then that value would be returned from the global store.

Bob,

That's very interesting. Thanks for posting.

I'll study the MSLearn article properly later but my initial impression is that the OP never needed to alter any UsrClass keys at all, assuming RegEdit or any reg commands were run as Admin.
I don't think I've quite grasped the whole thing yet because my UsrClass.dat file was modified at my last login & has a file creation date in 2020 yet my other not-currently-logged-in user has no UsrClass.dat at all.


All the best,
Denis

Its not directly stated but the article is referencing UsrClass.dat (and others) when they mention the "Virtual Store".

I found a new hive when looking this up too (C:\Windows\AppCompat\Programs\Amcache.hve)

I can't check my Winodws 11 computer at the moment, because it's doing a long test sequence that I cannot interrupt, but I imagine the Registry hive list is the same as in Windows 10.
hklm\system\currentcontrolset\control\hivelist

The other files in C:\Windows\AppCompat\Programs certainly make it look at though Amcache.hve is a hive.
I have not tried to examine its contents.


Denis