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:
- Run regedit.exe, everybody's favorite Registry Editor.
- At the root node of HKEY_CLASSES_ROOT, right-click and select Permissions from the context menu.
- Report what you see. The first image is correct. The second image is the problem scenario.
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.
Update: 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.
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:
- Install subinacl.
- 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.