Registry key access denied even with correct permissions

Question

I'm running a clean install (only several days old) of Windows 10 home 64 bit, and I encounter issues accessing a particular registry key. When the Office VBA editor (32 bit process under my own limited user account) scans the registry for available controls, it hits the {0002DF01-0000-0000-C000-000000000046} CLSID in the HKCR\CLSIDs branch and gets an Access Denied when opening the key in read mode, which prevents it from continuing. This key is only present in the HKLM branch, and not in the HKCU branch. Seeing it's default value, it's for "Internet Explorer(Ver 1.0)". There are two copies for it; one directly in the Classes\CLSID path, the other in the Classes\WOW6432Node\CLSID path for 32 bit processes. Since this is Office 32 bit I first focused on the WOW6432Node version.

My tests so far:

• This key already had read permission for my user account... what gives?
• The owner was TrustedInstaller (why him?), and the permissions were explicitly overridden for this key (i.e. not inherited like I'd suspect - why?)
• I changed the owner to Administrators, and added my specific user account with full permission. RegEdit's "effective access" tab confirms this user then has full permission on it, but the access denied is still triggered when the VBA IDE (running under this same user account) tries to read it?
• I temporarily renamed the key (e.g. by replacing the 1st "0" with a "1"). According to Process Monitor, the VBA IDE can now read the renamed key fine - no access denied anymore!? Renaming it back gives the old behavior again...
• Thinking this potentially might be a clash between the 32 and 64 bit 'version' of the same key, I tried to do the same with the 64 bit version of this key. Result: default permissions were already good enough, setting ownership to Administrators works, giving Administrators full control also works, but then renaming the key in RegEdit as admin is not allowed? RegEdit throws up an "Error Renaming Key - The Registry Editor cannot rename {0002DF01-0000-0000-C000-000000000046}. Error while renaming key." (wow, that's helpful info!) Using Process Monitor reveals that RegEdit's RegRenameKey operation also results in an access denied here.
• Running RegEdit with the System account using PsExec -s -i regedit.exe (account confirmed via Task Manager), it's still not able to rename the key.

It seems like this is thus not a permission problem per se; it looks as if some other process is actively monitoring access to this key by name and denying it? Irregardless of the correct permissions being set, admins cannot rename the 64-bit version of the key, and 32-bit processes trying to read the 32-bit version of the key get 'access denied' as well. I assume since 32 bit processes query for the generic Classes\CLSID... path (i.e. not with the WOW6432Node path explicitly in it like my RegEdit renames did), this triggers the same capturing here.

To complete the picture: I honestly can't remember when this started happening; I first noticed it a few weeks back when I needed this VBA IDE functionality again. I have Sandboxie v5.18 installed alongside the default Windows Defender. All software is patched and up-to-date. Apart from that no other invasive security software is installed. Turning off the Sandboxie service and Windows Defender didn't help either, and neither did running Windows in safe mode.

Does anyone have any idea what might be going on?

The context for anyone curious and/or needing help fixing this as well: I'm using Office 2010 professional 32 bit, and I've hit the VBA IDE bug which results in not being able to add additional controls to your toolbox when designing forms in the IDE. I can select "Additional controls" all day long (from the menu as well as from the popup context menu from the toolbox itself), but apart from a brief flash of the cursor changing form, nothing ever happens - no "Additional controls "dialog opens whatsoever, no errors are shown, nothing. The reason this happens is that when iterating through the registry in search of "control" type CLSIDs, the VBA IDE just quits what it's doing when it hits an 'access denied' error when reading a registry key. Using Process Monitor you can find which key triggered the permission error, and correcting the set permissions makes VBA happy again. Unfortunately the bug is present for a long time by now, and while it's not encountered that frequently, IMO it's still bad design which hasn't been fixed.