SSMS : How to fix SQL Server Management Studio not opening problem

Recently, I installed the SQL Server Management Studio 18 (SSMS) and after just one use, it didn't want to start anymore. The SQL Server Management Studio stopped loading after the splash screen showing up for a brief moment and no messages appeared to show me what was wrong, except for Windows playing the default beep sound notifying me of a problem. In this article, I will show you how I solved this issue.

First, I assumed, the SSMS 18 didn't want to open due to another process running, but looking at the Task Manager, there was none. Next, I tried using the repair option which is shown next.

Using Repair option

We can use the Repair option that is located in "Programs and Features", but the option is a bit hidden. The steps are as follows:

• On Windows, run the "Programs and Features" utility.
• From the list of installed applications, select "Microsoft SQL Server Management Studio" and click on the Uninstall button. This will cause the following window to open:
  
• Click on Repair button, which will take a while to complete.
• You will need to restart the computer.

Now if we are lucky, the problem would be solved by now, but in my case, there was no change. Next, I wanted to see if there is some sort of log file for the SQL Server Management Studio, so I could examine it and find out why the application doesn't want to open.

Using the SQL Server Management Studio log file

It turns out, there indeed is a logging feature available, but to use it, we need to run the executing file using a -log argument.

The steps are as follows:

• Open Windows Explorer and go to the installed folder of the SQL Server Management Studio. In my case using Windows 10, this was at C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE
• Once there, type cmd in the address bar and press enter:

  

• The command prompt will open at that specific path. The executable file for the SQL Server Management Studio is ssms.exe and we need to run it with the logging enabled. We do this by using -log argument, followed by the location and the name of the log file. We need to specify the full path to the log file, something like this:

  ssms.exe -log d:\log.txt
  

  This will create a log file at d:\log.txt. Simply modify it to the path of your choice.

• When the application fails to open again, find the log file and open it using a text editor, like notepad.

Examining the content of the SSMS log file

Looking at the generated ssms.exe log file, it consisted of multiple <entry> tags and some of them were Errors showing 80004005 - E_FAIL. All those errors in a log file happened when the two tasks below were attempted:

• CreateInstance failed for package [Async Query Service Package]
• CreateInstance failed for package [Task Scheduler Package]

In both cases, they had the same detailed description of the error:

The issue with the Microsoft.VisualStudio.Shell.Interop.8.0 library

So it seemed, the issue had something to do with the Microsoft.VisualStudio.Shell.Interop.8.0.dll file. I searched for this .dll library inside the installed "Microsoft SQL Server Management Studio 18" folder and found two files located at the following path:

• C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\PublicAssemblies
• C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\PrivateAssemblies\Interop

Both files had the same size of 168KB and both showed the same 8.0.50727.938 version when checked the information under Properties:

But, even though, those two files looked identical, by examining the content of the files, it was obvious that they were not the same.

To try to figure out, what was going on, I ran the following command in PowerShell to check for the Assembly version of both library files.

[System.Reflection.Assembly]::LoadFrom("Full Path to Microsoft.VisualStudio.Shell.Interop.8.0.dll").GetName()

For a .dll file located in the PublicAssemblies folder, the result was:

And for a .dll file located in the PrivateAssemblies\Interop folder, the result was:

From this information, the error message of "The located assembly's manifest definition does not match the assembly reference" made more sense now.

Solution

In the end, the solution was to copy the PrivateAssemblies\Interop\Microsoft.VisualStudio.Shell.Interop.8.0.dll file (the one with assembly version 15.0.0.0) into the PublicAssemblies folder.

The steps I did were the following:

• First, as a precaution, I renamed the existing PublicAssemblies\Microsoft.VisualStudio.Shell.Interop.8.0.dll to something else, just in case I would need that file later.
• Then I copied the Microsoft.VisualStudio.Shell.Interop.8.0.dll file from PrivateAssemblies\Interop into the PublicAssemblies folder.

After this change, the SSMS loaded without any issue.

Missing or deleted Microsoft.VisualStudio.Shell.Interop.8.0.dll

If for whatever reason, you don't have the Microsoft.VisualStudio.Shell.Interop.8.0.dll file at PrivateAssemblies\Interop, you can download the file from pconlife.com website.

The "MD5 hash" of the Microsoft.VisualStudio.Shell.Interop.8.0.dll file is da57504433ae4597798aa8d3ae8d66bf, so make sure, the file downloaded matches the same hash value. You can use this online tool to check the MD5 hash of the files.

Thanks to just a guy commentator for being the first to point out the problem of a missing Microsoft.VisualStudio.Shell.Interop.8.0.dll file.

Conclusion

If you run SQL Server Management Studio 18, but it doesn't open and doesn't give you any error message, it might look like a tough problem to solve. One option is to use Repair located in "Programs and Features", but if that doesn't work, we can also use the ssms.exe log option. In my case, the log file was showing an issue with the Microsoft.VisualStudio.Shell.Interop.8.0 library file. It turns out, the installed folder contains two such .dll files and solution was to copy the one at PrivateAssemblies folder into the PublicAssemblies folder.