Why can’t I open SQL Server Management Studio

Recently we worked with a customer who could not launch SSMS from a specific computer. We heard about this issue in the past from few others but never found the actual cause of this till now. So posting some of the information here as well as how we narrowed this down.

Whenever you try to open SSMS you will immediately get the following error:

After you click OK, the window will disappear. This happens consistently. So we started off with the favorite tool from Sysinternals –> Process Monitor. One key information we found from this was the inability to load some of the key .net framework libraries like the following:

By this time we also learnt that only specific users are encountering the problem. This confirmed that this must be then a specific permissions issue. So we started to check and compare all the permissions of this folder hierarchy. Some of the tools we used include the AccessCheck and AccessEnum from Sysinternals. These tools allow you to see the permission changes in a specific folder hierarchy. Also you can use the built-in command line tool like CACLS or the downloadable XCACLS to review and reset the permissions on various folders. These tools especially come in handy when you dealing with system and hidden folders like the one we are dealing with here.

In the non-working machine, we examined the properties of the file that encountered the “ACCESS DENIED” and noticed that this file did not have the EXECUTE permission for the built-in Users group.

We tracked this lack of permissions all the way up to the C:\Windows\Assembly folder. When we compared the permissions of this folder with other machines where this was working fine, we noticed that all working configurations had the EXECUTE permission set for the Users group. Here is the CACLS output from a working machine.

Now when we added the execute permissions for Users group for everything below Assembly folder, then SSMS starts working fine. You can use the CACLS or XCACLS command to reset the permissions on these folders to their defaults.

Moral of the Story: Do not change permission settings on the system and critical folders whose default permissions are set by the Operating System or .net Framework unless you want to go on adventure rides like this.

Thanks

Suresh B. Kandoth