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 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 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.exeand 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:
(Exception from HRESULT: 0x80131040) System.IO.FileLoadException: Could not load file or assembly 'Microsoft.VisualStudio.Shell.Interop.8.0, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
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.
In the end, the solution was to copy the
PrivateAssemblies\Interop\Microsoft.VisualStudio.Shell.Interop.8.0.dll file (the one with assembly version 184.108.40.206) into the
The steps I did were the following:
- First, as a precaution, I renamed the existing
PublicAssemblies\Microsoft.VisualStudio.Shell.Interop.8.0.dllto something else, just in case I would need that file later.
- Then I copied the
After this change, the SSMS loaded without any issue.
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