So the Thursday before last I set out to configure Vista's file indexing to only index file extensions of type lnk and exe, as I already had it configured to only index the locations on my computer which contained program shortcuts, but I wanted to extend these locations to include a folder of standalone executables and launch them from my start menu as well.

 But lo, I encountered this:

Just where exactly did all of my file types go?  You can see from the screenshot that the list stopped at .ado.

Well, like any good Windows troubleshooter, I turned to Sysinternal's essential Process Monitor.  I re-opened the file type dialog, this time with monitoring enabled, and performed a search for the last file type on the list, .ado.

As you can see from the lines I highlighted in the screenshot above, Vista was failing to read the next file extension in the list, .adobebridge, and presenting an Access Denied error.

Using Process Monitor's oh so useful Jump To... context menu feature, I jumped straight to the registry key having difficulty, and sure enough:

How interesting.  Using the key's context menu to view and modify its permissions presented me with this amusing (but accurate, I suppose) little message box before presenting the actual Permissions dialog.

Using the Ownership tab under Advanced to take ownership of the key allowed me to see the permission settings:

As you can see, there are no permissions set at all.  Adding the Users group and granting them Read privileges was enough to fix the dialog, but it takes write privileges to be able to actually toggle indexing on and off for the file type, so I made sure to add the Administrators group and grant them Full Control.  (UAC prompts you to allow the Advanced settings dialog to be launched with administrative rights when you first enter it, as denoted by the icon on the button: )  As it turned out that there were a dozen or so other keys the dialog choked on which required the same modification.  They didn't all have blank permissions, but none of them had read access for my account.

I'm not sure what's broken here, perhaps the software or installers which added these file extensions did so improperly, or maybe it was intentional and they didn't realize the entire file type indexing dialog would break when it was denied access.  Either way I would gander that the dialog behavior is most certainly a bug.

Unfortunately I'm not an expert when it comes to Windows Permissions setting, as I've never interacted with them on more than a casual basis, and I've done very little in the way of inheriting and propogating permissions, so I'm curious about the most appropriate and efficient solution to a scenario like this.   Include inheritable permissions from this object's parent was enabled for the registry keys with the problem, and other working keys claimed to be inheriting permissions from their parent, but I looked at the permissions on HKEY_CLASSES_ROOT and there appeared to be none to propogate.  So perhaps that is not their parent?  Any revealing information would be welcome.

(Note: Mark Russinovich of Sysinternals does an ever enlightening job of educating us on Windows internals, making copious use of Process Monitor in the process.)