Microsoft SQL Server Management Studio startet nicht

Ein Wort zur Version, damit du die Pfade richtig einordnest. Die drei Methoden beziehen sich auf die klassische Standalone-Installation der SSMS-18- und SSMS-19-Generation. Diese Builds liegen unter C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\... und bringen die Visual-Studio-Shell als eigene Dateistruktur mit. Genau diese Struktur macht die folgenden Eingriffe überhaupt möglich.

Ab SSMS 21 hat Microsoft auf den Visual-Studio-2022-Unterbau umgestellt, dort sieht das Programmverzeichnis anders aus und die unten genannten Pfade existieren so nicht mehr. Auf 21 und 22 reparierst du deshalb über den Visual Studio Installer (Eintrag "SQL Server Management Studio", "Ändern", "Reparieren").

Bis zur Version 20 gelten die folgenden Tricks.

SSMS lädt beim Start eine Reihe von Package-Definitionen mit der Endung .pkgdef. Ist eine davon beschädigt, bricht der Shell-Start ab, noch bevor das Hauptfenster gerendert wird. Die Datei Microsoft.VisualStudio.MinShell.Interop.pkgdef ist ein bekannter Auslöser für genau dieses Verhalten, also für den Splash-Screen, der sich sofort wieder schließt.

Öffne den Windows-Explorer und navigiere zu:

Lösche dort die Datei Microsoft.VisualStudio.MinShell.Interop.pkgdef. Du brauchst Administratorrechte, der Explorer fragt beim Löschen nach. Starte SSMS danach neu. SSMS baut die nötige Konfiguration beim nächsten Start neu auf, die defekte Definition ist dann raus.

Diese Methode greift, wenn eine kaputte Erweiterung oder Integration den Start blockiert. Sie ist der schnellste Versuch, weil du nur eine einzige Datei entfernst und nichts an der restlichen Installation veränderst.

In SSMS 18 liegt die Datei Microsoft.VisualStudio.Shell.Interop.8.0.dll an zwei Stellen im Programmverzeichnis. Bei manchen Installationen, oft ausgelöst durch ein Update, weichen diese beiden Kopien in ihrer internen Assembly-Version voneinander ab, obwohl Dateigröße und angezeigte Dateiversion identisch aussehen. SSMS bindet dann die falsche Variante und stirbt beim Start. Genau deshalb hilft hier kein Repair: Beide Dateien sind ja vorhanden, nur eben in unpassender Version.

Der Fix besteht darin, die funktionierende DLL aus dem Interop-Verzeichnis über die Kopie im PublicAssemblies-Verzeichnis zu legen.

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

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

Sichere zuerst die vorhandene Zieldatei (zum Beispiel als Microsoft.VisualStudio.Shell.Interop.8.0.dll.bak), damit du die Richtung zurückdrehen kannst. Kopiere dann die DLL aus dem Quell- ins Zielverzeichnis und überschreibe die dortige Datei. Starte SSMS neu, ein Reboot ist nicht nötig.

In einzelnen Fällen war die Richtung umgekehrt nötig, also von PublicAssemblies nach PrivateAssemblies. Wenn die erste Variante nichts bringt, stell die Zieldatei aus deiner Sicherung wieder her und probiere die Gegenrichtung.

Die dritte Methode kursiert im Netz als "lösche Zeile 38 in der ssms.exe.config". Genau diese Angabe ist heikel und du solltest sie nicht blind übernehmen. Die Zeilennummer hängt von Build und Patch-Stand ab. In deiner Datei kann an Zeile 38 etwas völlig anderes stehen als in der Anleitung, die du gerade liest. Das blinde Entfernen einer Zeilennummer zerlegt dir im schlimmsten Fall eine intakte Konfiguration.

Was technisch wirklich dahintersteckt: Die ssms.exe.config steuert unter anderem die Assembly-Bindings und Runtime-Einstellungen von SSMS. Ein doppelter oder fehlerhafter <dependentAssembly>-Eintrag kann den Start verhindern.

Starte den Editor als Administrator (im Startmenü "Editor" eingeben, rechte Maustaste, "Als Administrator ausführen"). Öffne die Datei "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\ssms.exe.config"

Lege zuerst eine Kopie an (ssms.exe.config.bak). Suche dann gezielt nach doppelten oder offensichtlich kaputten Bindungseinträgen, nicht nach einer festen Zeilennummer. Speichere und starte SSMS neu. Wenn du dir unsicher bist, lass diese Methode aus und bleib bei Methode 1 oder 2.

Bleibt SSMS stumm, arbeite dich von harmlos zu invasiv vor. Starte SSMS mit ssms.exe /resetuserdata, um ein verbogenes Benutzerprofil auszuschließen. Prüfe die Datei ssmslog.txt in deinem %temp%-Verzeichnis, dort landet die konkrete Fehlerursache beim Start. Wirf einen Blick in die Windows-Ereignisanzeige unter Anwendung. Erst danach greifst du zu Repair: bei SSMS 18 und 19 über die klassische Programme-und-Features-Reparatur, bei SSMS 21 und 22 über den Visual Studio Installer.

Die drei Methoden greifen an drei verschiedenen Bruchstellen an, und das ist der Grund, warum du sie der Reihe nach durchgehen solltest. Methode 1 entfernt eine korrupte Package-Definition, Methode 2 korrigiert eine versionsmäßig auseinandergelaufene Interop-DLL, Methode 3 zielt auf einen kaputten Eintrag in der Laufzeit-Konfiguration. Ein Repair allein hilft bei diesen Mustern oft nicht, weil entweder die fehlerhafte Datei wiederkommt oder beide DLL-Kopien formal vorhanden sind.

Zwei Dinge bewahren dich vor Folgeschäden. Erstens: Sichere jede Datei, bevor du sie löschst oder überschreibst. Das gilt vor allem für die ssms.exe.config, weil ein falscher Eingriff dort den Start ganz verhindern kann. Zweitens: Behandle die kursierende Angabe "Zeile 38" als das, was sie ist, nämlich einen versionsabhängigen Zufallswert und keine verlässliche Anweisung.

Die Methoden tragen von Version 18 bis 20, also über die gesamte Standalone-Generation von SSMS. Greift keiner der Fixes und nervt dich derselbe Build immer wieder, bleibt als saubere Alternative der Umstieg auf das aktuelle SSMS 22, das sich über den Visual Studio Installer reparieren und parallel zu deiner Altversion installieren lässt. Für die schnelle Wiederbelebung deiner bestehenden Installation reichen aber in den meisten Fällen die drei Eingriffe oben.