Weird Vista Registry Issue

  Vista

I'm attempting to track down a very strange Windows Vista registry permissions issue that hit me on two machines, that I've found mentioned in random various forum posts across the Internet, that has no known cause or solution, and which I cannot seem to reproduce in a VM though I've seen it happen on 2 machines across 4 Vista installs.  I'm hoping everyone that happens to read this post will take a few minutes to check the following and contact me directly or leave a comment with a way to communicate back to you.  Here's what to do:

  1. Run regedit.exe, everybody's favorite Registry Editor.
  2. At the root node of HKEY_CLASSES_ROOT, right-click and select Permissions from the context menu.
  3. Report what you see.  The first image is correct.  The second image is the problem scenario.

image reg

Subsequently, every subkey that is created or modified after this problem occurs has no permissions attached to them, causing all sorts of issues like COM components not being registered, file extensions not being registered, etc.  Permissions on every entry prior to the problem occurring are set properly.

I first noticed the problem when installing XNA 2.0 Beta, though its problems were caused by the already unnoticed and broken permission state.  Several folks in the XNA forums have reported a similar issue with no evidence of a cause, though I did find a not-so-perfect solution for x86 machines.  I have a feeling this is something that has happened recently, perhaps due to a Windows Update, but that's just a guess.

I attempted to reproduce this in a VM and failed.  I rebuilt my Vista x64 desktop since this was causing chaos and managed to reproduce it twice by installing Office 2007.  Yet, doing that same thing in a clean Vista VM would not reproduce it.  So that's not it either.  There are reports of it happening on both x86 and x64 installs.  There's obviously some sort of interaction here, but I have yet to find the common link.

My original installations were running with UAC off.  My first two re-install attempts ran with UAC off as I typically run.  On the third re-install attempt I left UAC on instead of turning it off and that seemed to make all the difference.  However....note that in attempting to reproduce this in a VM multiple times in multiple ways, UAC was turned off and the problem did not occur.

Update 1/26/09: I’ve received a lot of emails from people stating that the “new” secedit fix isn’t working for them.  It’s certainly still worth a try to see if it will fix the problem as it’s an easier solution, but it you’ll likely still have to go with the subinacl method in order to correct the problem.

Updated solution (1/12/2009): Jim Beveridge left a comment below with a new solution that is a much better fix:

The solution is to reset the registry permissions by running this command (this is for Vista - should all be on one line):

secedit /configure /cfg C:\Windows\inf\defltbase.inf /db defltbase.sdb /areas REGKEYS

This is described in:

http://support.microsoft.com/kb/313222

Note that I intenionally added the /areas REGKEYS parameter to the command line so that only the registry would be updated. You don't want to reset file system permissions if you don't have to because some applications use non-default security settings.

This command should work on both 32-bit and 64-bit platforms. Secedit is more intelligent than the brute-force subinacl commands above. I also found that Secedit ran an order of magnitude faster than trying to run subinacl six or more times.

So, the below remains for posterity, but definitely try the above fix and see if it corrects the problem before trying what’s below…

The partial solution below does not fix the root of the problem.  One can reset the registry permissions using subinacl from the Windows Resource Kit, but a) it's a 32-bit app so it can only touch the 32-bit reg keys, and b) HKEY_CLASSES_ROOT itself will still randomly reset its permissions to nothing though the subkeys will still retain their fixed permissions.  So, anything which attempts to write to the registry is once again broken.

To partially fix the issue, do the following:

  1. Install subinacl.
  2. Copy/paste the following to a batch file and run it, replacing YOURUSERNAME with your Windows username: 
cd /d "%programfiles%\Windows Resource Kits\Tools" 

subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /grant=restricted=r /setowner=administrators
subinacl /keyreg HKEY_CURRENT_USER /grant=administrators=f /grant=system=f /grant=restricted=r /grant=YOURUSERNAME=f /grant=restricted=r /setowner=administrators


subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f /grant=users=r /grant=everyone=r /setowner=administrators
subinacl /keyreg HKEY_LOCAL_MACHINE /grant=administrators=f /grant=system=f /grant=users=r /grant=everyone=r /setowner=administrators


subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators
subinacl /keyreg HKEY_CLASSES_ROOT /grant=administrators=f /grant=system=f /grant=users=r /setowner=administrators

So, kind readers, please take a look at the above and let me know what permissions you're seeing on your registry so I can continue to find the root cause.