C# Winform Registry set and get functions appear to work, but don't actually change the registry

Question

I'm trying to use this registry hack I found online:

;Disables F1 key - Help and Support - in Windows 10
;Ramesh Srinivasan, Winhelponline.com

[HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win32]
@=""

[HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win64]
@=""

When I run it as a .reg command via Windows Explorer and watch the registry with regedit, it works as intended. Removing it is another registry file that simply removes the \0 subkey (and win32 and 64 with it). I'm trying to emulate this function with C# in a Winform using .net CORE:

        private void CheckF1()
        {
            // Registry data from ;Ramesh Srinivasan, Winhelponline.com
            RegistryKey F1key = Registry.CurrentUser.OpenSubKey(@"SOFTWARE\Classes\TypeLib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");

            // EGADS! It's active!
            if (F1key == null)
            {
                fckF1RestoreBtn.Enabled = false;
                fckF1KillBtn.Enabled = true;
                fckF1Status.Text = "That creepy bugger is waiting and watching.";
            }
            else
            {
                fckF1RestoreBtn.Enabled = true;
                fckF1KillBtn.Enabled = false;
                fckF1Status.Text = "The F1-Help function had been put in it's place.";
            }
        }

        private void fckF1KillBtn_Click(object sender, EventArgs e)
        {
            Registry.CurrentUser.CreateSubKey(@"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win32");
            Registry.CurrentUser.CreateSubKey(@"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0\win64");
            CheckF1();
        }

        private void fckF1RestoreBtn_Click(object sender, EventArgs e)
        {
            Registry.CurrentUser.DeleteSubKeyTree(@"SOFTWARE\Classes\Typelib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");
            CheckF1();
        }

Weirdly the code "sees" a setting and responds like it should. Even to the point that whichever toggle position it was in on close it remembers when I load the file again. It's almost like it's playing along to screw with me. Regardless, when I watch the registry, none of my code has any actual effect though by all appearances it seems to work otherwise (it doesn't actually of course because the registry change isn't happening).

NOTE: I have already updated my manifest file for the project to include elevated permissions:

        <requestedExecutionLevel level="highestAvailable" uiAccess="false" />

Here's the breakpoint on the test statement to see if the subkeys are there that shows they are:

Meanwhile the registry location for the exact path shown in the debug doesn't have the 1.0\0 path at all:

I don't know how the code is reading phantom values. Someone closed my previous question pointing to another answer that didn't have any effect (Registry key deleted but still getting value from registry c#):

• "Prefer 32 bit" was never checked for my project in the first place
• Modifying my code as recommended had no effect

            var key = RegistryKey.OpenBaseKey(RegistryHive.CurrentUser, RegistryView.Registry64)
                    .OpenSubKey(@"SOFTWARE\WOW6432Node\Classes\TypeLib\{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0");

• Adding "Wow64Node" to the path makes no difference in execution.

EXPECTED BEHAVIOR

Checking to see if the HKEY_CURRENT_USER\SOFTWARE\Classes\Typelib{8cec5860-07a1-11d9-b15e-000d56bfe6ee}\1.0\0 path is present should return null if the \0 path is not present

Adding and removing the subkeys should show in the registry

Answer 1

So apparently HKEY_CURRENT_USERS is an alias. When the above code runs, it updates in HKEY_USERS under the specific logged in user. There's a question that talks about this behavior here: write registry to hkey_current_user instead of hkey_users

That said, the code appears to work, it's just that the registry doesn't update HKCU like when you run .reg commands. To verify it was working, I'd run the toggle that kills the keys then click them in Regedit and it would say they didn't exist. When I toggled back, I could click on them. So basically, it works (not sure if it required the "using" blocks as others suggested, but I see no reason to take them out).

Now my problem is that it points to the admin user and NOT the regular user because I'm running it and regedit as admin. It took forever to determine this based on running regedit as user in one case and admin in another. Bottom line, this won't work and I'll probably end up running .reg files in the command line instead.