Weird Vista Registry Issue

I’m attempting to track down a very strange Windows Vista registry 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 or leave a comment:

Run regedit.exe, everybody’s favorite Registry Editor.

  1. At the root node of HKEY_CLASSES_ROOT, right-click and select Permissions from the context menu.
  2. Report what you see.  On the left, the correct permissions.  On the right, the busted permissions.

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.

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.

Leave a Reply

Your email address will not be published. Required fields are marked *