Permanently disable user-choice override in registry (FileExts)?

Question

The Short and the Sweet:

Is there any way to truly disable the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts in Win7?

On the affected systems, users should NOT be able to set their own associations, so that inability is not a liability here. But it's not enough to bar users; that's easy. I also need to bar Windows itself from writing to the key, and not even SYSTEM read-only permissions have proven able to do that (see end of post).

The Long and the Ugly:

Have a situation on Win7 Pro SP1, updated (critical only) through October 2017. VLC and various editing apps are used for audio and video files. Unfortunately, for a couple of types of files I need Windows Media Player as a viewer, so I can't get rid of the stinker, and that's a problem. I've got a very carefully configured set of multimedia file extensions set up using normal extensions and filetypeIDs in HKLM\Software\Classes. I install VLC and editing apps without allowing any of them to associate with anything, and I then create all the associations and context-menu entries myself, eliminating a lot of their own and native Microsoft context-menu clutter in the process to facilitate a better workflow.

The problem with this idyllic dream is that Windows Media Player makes an end-run around my config by hijacking asscoations with the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts. If you just delete the key, Windows simply recreates it and repopulates it. So I need to completely disable/lock the FileExts registry key so that it doesn't disrupt the careful setup I've configured.

But this isn't just a WMP issue: additional programs can cause the same type of problem with their respective file types. I have a similar issue with graphics applications. So please do not offer solutions that simply handle WMP. I need a solution that completely disables the user-choice override offered via the FileExts key. In other words, I need to make the FileExts key inaccessible to not just everyone but everything.

It doesn't matter if this causes me to lose some program's functionality down the road: if some app won't set up its associations the right way in HKLM\Software\Classes, I'll do it myself. So please, no finger-wagging at me over that issue. The fact is that FileExts is utterly unnecessary for Win7 to run. It's even unnecessary for WMP to run--the only thing it does is allow Microsoft a way to sink its claws in deep so it's really difficult to wrest control away from the apps it wants you to use (e.g. WMP). Well, OK, it also allows users an easy GUI way to set associations for single file types. But as I noted above in the TL/DR, that's not an issue here.

What I've attempted: after taking ownership of the key and then deleting everything under it, I imposed read-only permissions on both SYSTEM and the administrators group to no avail (first Deny everything, then give back Query Value, Enumerate subkeys, Notify, Read Control). That should have locked down the key like an iron chastity belt, but no dice. Despite the fact that the warning message says that Deny permissions will trump everything else, they don't. At next system restart, FileExts once again displays its hundred-odd default entries.

So is there a way to empty and then genuinely bar this key, or has M$ made it impossible?

Answer 1

Hallelujah.

After rereading the relevant section in Windows 7 Annoyances I was finally able to put the clues together.

Critical to creating effective registry locks is understanding that Deny permissions trump Allow permissions. E.g. a Deny for Query Value will disable Query Value for the designated user even if an Allow is also present enabling Query for said user. Now, this is no news to anyone, but the implications are important for the problem at issue here. I derived the crucial clue from the following passage:

"[When locking a registry key] you may be tempted to remove Allow permissions for a particular user (or even all users), rather than add the Deny entry. . . .The problem is that doing so wouldn’t prevent an application or Windows from taking ownership or adding the necessary permissions and breaking your lock. . . . [To] make a key read-only . . . place a Deny checkbox next to Set Value, Delete, and Write Owner". (David Karp, Windows 7 Annoyances, 156) [and I would add a Deny to "Create Subkey" as well, just to be safe.]

This passage avers that if you remove Allow permissions rather than setting Deny permissions, for some reason Windows and other apps will be able to weasel around your settings even though nobody's supposed to be Allowed. Karp does not explain why this is the case, but brief as his commentary is, it does make clear that removing Allow permissions fails to hinder Windows from doing what it wants. It also makes clear that straight-up denials cannot be evaded. So you should set Deny permissions rather than removing Allows.

That's not the whole story, though. The procedure with which I began did in fact start with Denials (see OP, next-to-last paragraph). I checked the entire Deny column. However, I then also went over to the Allow column and rechecked all the items that would give read access: Enumerate subkeys, Query Value, Read & Execute, and so forth. And that was the Achilles heel. Even though I didn't allow any of the write permissions, allowing any permissions at all after setting your Denials seems to have the same effect as removing Allows, negating the cyber-lockdown achieved by setting Denials. All human users, even admins, are still prevented from modifying the key, but Windows is not. This shouldn't be the case, of course. I did set the proper Denials for the Everyone user, and supposedly those trump everything else. As with so much else Microsoft, this feature does not always work as advertised. But as long as you don't touch the Allow column, it will.

To verify that Deny sans Allowances works, I restored a registry backup so as to start with a clean slate. Then I went back to the key and did nothing but set the write-permission denials. That was it--no check marks at all in the Allow column. And this time the lock worked the way it should. The key can still be read but now Windows is no longer able to sneak into it and repopulate.

Answer 2

Let Windows do what it will; you can automatically overwrite those keys with your own preferred content by 1) edit the registry to suit, 2) export those keys to a .reg file, 3) re-import using the reg or regedit.exe commands in a scheduled task set to run at every logon, or on demand.