Search code examples
visual-studio-2017ssmssql-server-2017

SQL Server Management Studio 17.9 crashing when using pinned tabs


Due to work I'm doing I need to have latest SQL Server installed on my laptop, SQL Server Management Studio and Visual Studio 2017 Dev (all latest versions available as of today on Microsoft site(s) for download).

Everything works fine until I install VS 2017 (with a lot of options - total install comes to about 50GB, reflecting work being done). When that's done, SSMS crashes when I switch between tabs. Yes. I have opened query A in tab A, then Query B in tab B (connection to same server) and when I click query B that just loaded (double-click in Windows Explorer and using default association of .sql files) - boom: no error message, no warning. SSMS shows turning wheel for 5 sec and then it restarts.

Obviously it's unusable at this point, but did anyone had similar issue and tracked down the cause before I nuke the Windows and reinstall all from scratch?

Already tried SSMS repair, VS repair, SSMS reinstall, VS reinstall, SSMS uninstall then reinstall, SQl uninstall + SSMS unisntall + VS uninstall (had problems as VS installer wanted to be updated, then could not uninstall whole VS, had to do it app-by-app manually), then reinstalled in Microsoft suggested order: SQL Server, SSMS, VS. Again - worked fine until VS installation got done...

Any help appreciated.

After further investigation: one of the tabs needs to be pinned for the crash to occur. But the moment I pin any tab... all gone. So there may be no link between SSMS and VS, but replicated that 3 times now: open tab, pin, open another tab, click on first, then back on second and crash.

After some time and further investigation (11 Oct 2018):

The issue happened to me again. But at the moment it's unclear if it's DisplayPort or Displaylink to DP (as I'm still using port replicator, utilizing DisplayLink solution), that is the cause, as my laptop does not have DP out, just HDMI. I also can't replicate problem on other workstations without breaking things for other people, too.

The link to DisplayPort is still there, so switching to HDMI continues to be a valid workaround (as in my answer below), but the issue is definitely software in origin, related to Visual Studio in some way. Or at least what's shown in the event viewer for this error:

Application: Ssms.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ArgumentException at System.Windows.Rect.set_Height(Double) at Microsoft.VisualStudio.PlatformUI.Shell.DraggedTabInfo.NormalizeTabHeight() at Microsoft.VisualStudio.PlatformUI.Shell.DraggedTabInfo.ExpandTabStripCore() at Microsoft.VisualStudio.PlatformUI.Shell.DraggedTabInfo.MeasureTabStrip() at Microsoft.VisualStudio.PlatformUI.Shell.Controls.DockPreviewWindow.OnPanelLayoutUpdated(System.Object) at Microsoft.VisualStudio.PlatformUI.Shell.Controls.DockPreviewWindow.OnPanelLayoutUpdated(System.Object, System.Windows.RoutedEventArgs) at System.Windows.RoutedEventHandlerInfo.InvokeHandler(System.Object, System.Windows.RoutedEventArgs) at System.Windows.EventRoute.InvokeHandlersImpl(System.Object, System.Windows.RoutedEventArgs, Boolean) at System.Windows.UIElement.RaiseEventImpl(System.Windows.DependencyObject, System.Windows.RoutedEventArgs) at System.Windows.UIElement.RaiseEvent(System.Windows.RoutedEventArgs)
at Microsoft.VisualStudio.PlatformUI.Shell.Controls.ReorderTabPanel.OnLayoutUpdated(System.Object, System.EventArgs) at System.Windows.ContextLayoutManager.fireLayoutUpdateEvent() at System.Windows.ContextLayoutManager.UpdateLayout() at System.Windows.ContextLayoutManager.UpdateLayoutCallback(System.Object) at System.Windows.Media.MediaContext+InvokeOnRenderCallback.DoWork()
at System.Windows.Media.MediaContext.FireInvokeOnRenderCallbacks()
at System.Windows.Media.MediaContext.RenderMessageHandlerCore(System.Object) at System.Windows.Media.MediaContext.RenderMessageHandler(System.Object) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate) at System.Windows.Threading.DispatcherOperation.InvokeImpl() at System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(System.Object) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean) at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object) at MS.Internal.CulturePreservingExecutionContext.Run(MS.Internal.CulturePreservingExecutionContext, System.Threading.ContextCallback, System.Object) at System.Windows.Threading.DispatcherOperation.Invoke() at System.Windows.Threading.Dispatcher.ProcessQueue() at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef) at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean ByRef) at MS.Win32.HwndSubclass.DispatcherCallbackOperation(System.Object) at System.Windows.Threading.ExceptionWrapper.InternalRealCall(System.Delegate, System.Object, Int32) at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(System.Object, System.Delegate, System.Object, Int32, System.Delegate) at System.Windows.Threading.Dispatcher.LegacyInvokeImpl(System.Windows.Threading.DispatcherPriority, System.TimeSpan, System.Delegate, System.Object, Int32) at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr, Int32, IntPtr, IntPtr)

Same laptop, same Windows installation as before, same SSMS and VS installations. What changed: different docking station (thunderbolt instead of USB3.0), the two external monitors (same model, but different specimens) are daisychained via DP, connected to single miniDisplayport output in the dock.

Until I reversed the order by which the daisy chain was working (so previously display number 2 is now display number 3, with laptop native remaining main display and number 1) all was well.

After the swap the problem returned. Since the monitors were recognized as new devices, they were set up as 1920x1080 resolution from their native 1920x1200 and to duplication instead of extended. When set it all up back to as I wanted, the error started again.


Solution

  • After some more investigations: found this thread:

    https://feedback.azure.com/forums/908035-sql-server/suggestions/33619039-crash-when-going-to-pinned-tab

    and replicated the tip in there. After some more testing issue has been narrowed down to Displayport - the culprit monitor is connected to laptop via USB port replicator, which can output display to three monitors (2xHDMI and 1xDP). When changed connection of the offending monitor from DP to HDMI issue is gone.