Actually my tantrum, as it turned out, has nothing to do with ASP (sadly).

So I’m working on a classic ASP application, implementing some new security features concerning local machine user accounts and domain user accounts. I notice that occasionally I’m getting ASP 0177  errors which stem from the Server.CreateObject() function failing, sometimes with an unhelpful “Object not found” error, sometimes with an “Invalid Prog Id” error and then sometimes with a “Remote procedure call failed” error.

After much head scratching, ensuring that the objects to which the Prog Ids relate, do exist and are registered, lots of googling,  I start to notice a pattern. If I log into the Web app (isolated) first using a domain user account, log out and subsequently log back in using a local machine user account, everythings fine. But if I log in first using a local machine user account, things start vomiting badly.

This starts to point me in the right direction as it seems to indicate that there’s a permissions problem (which is true), so I check that the accounts have the right permissions to launch and access the related COM+ application and objects. Which they do, so this doesn’t help as I’m still getting the problem.

Ok time to start thinking laterally, given that there’s a number of different errors, I decide to tackle them one by one, so by chance I decide to pick the “Invalid Prog Id” error first. Given a Prog Id, an object can be created by looking up the Prog Id in the registry, grabbing the CLSID and from that key it would lead to the DLL module concerned which CoCreateInstance can then use to instantiate an object. I locate the Prog id in the registry, and check it’s permissions.

Aah, the permissions expressed, wouldn’t give the local machine user account access to the registry key so that would explain the “Invalid Prog Id” error. So I check the Prog Id permissions for the other COM objects involved, and they turn out to be the same.

Mmmmm, I expand the search and go back to the root HKCR node and check permissions there, interestingly I find that only my domain user account and the SYSTEM account have read permissions from that node downwards, which isn’t right, the Administrators group at least should have Full Control permissions from that node, but oddly it doesn’t!

So I set about fixing it, I add the Administrators group with Full Control permissions, I also add the Users group with Read permissions and another specific application related group also with Read permissions.

Fire up the Web app, log in using a local machine user account, and (obviously enough) it all works 🙂

Question is though, what cobbled the registries HKCR permissions in the first place?