Once again, security-by-obscurity to the rescue of Microsoft’s ability to frustrate power users!
Loading Hives…
Somehow, I wasn’t paying enough attention and use the registry editor to create a key then load a user’s NTUSER.DAT registry hive under HKEY_CURRENT_CONFIG… Yes, it warned me that loading the hive would “overwrite” everything under the newly created key (if there was any path collision), but I had not done this in umpteen years and thought nothing of it… It did not prompt me to “create a new key” to load the hive on…
Well, the UI let me… Don’t ask me how (when it’s supposedly impossible)…Then I realised my mistake (since you should only ever be able to load hives under HKCU and HKLM tree)…
Unloading Hives… Not So Fast!
So, just select the newly create key under HKCC and go to “Unload hive…” except that it’s greyed out… đź‘ż
reg unload HKCC\newkey didn’t work.
Found out that HKCC actually propagates under HKLM\CurrentControlSet\Hardware Profiles\Current and tried that.
Checked that the .DAT file actually wasn’t locked, so that meant changes would not propagate to the actual registry file (and really screw that user’s profile up). So, renamed and rebooted just to be sure…
Deleting Subkeys… Not!
Then tried to delete it – first ensuring I had ownership and then set permissions – no dice on the first and therefore failed on the second… đź‘ż
Rebooted in Safe Mode. Same.
W.T.B.F.
A wise sage said, “to delete the undeletable, use ‘psexec -i -s regedit.exe‘”…
Worked… Sigh.
