SQL Server Management Studio (SSMS) is getting better and better with each new release but Microsoft seems to ignore one big issue affecting a group of users that grows rapidly as the technology moves forward and we move on to modern workstations and laptops.

I recently switched my old Dell XPS laptop which served me very well the last 5 years. To meet my work needs, I moved on to a modern Inspiron 15 Gaming machine with a 15.6-inch UHD (3840 x 2160) display. It came with a Windows 10 operating system and its doing a decent job of managing the size of text, icons and other items on a majority of programs. However, one thing that was bugging me from the very beginning was the visual appearance of SSMS.

So, the first thing I did was checking out SSMS changelog and previous releases to find any information regarding 4K resolution and high DPI support. The 16.3 (Version number: 13.0.15700.28) update for SSMS includes initial beta support to allow high-DPI in SSMS to display appropriately on high-resolution monitors. Furthermore, it’s stated that this functionality is disabled by default because of continuous development and testing to make high-DPI in SSMS support better.

This initial beta support for high-resolution displays is linked to 17 customer bug requests on Microsoft Connect which has been retired after nearly 10 years. However, this is less important and the purpose of this write-up is to show how to make SSMS on 4K resolution and high DPI pretty again. So, let’s check how SSMS looks on UHD display with all, both Windows and SSMS, default settings.

SSMS 16.5.3

To enable high-DPI in SSMS, follow the instructions below:

1. First, we need to enable SSMS to look for an external manifest file, if available, by creating the following registry key:

   Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide
   Name: PreferExternalManifest
   Entry type:  DWORD
   Data: 00000001

   Start by opening Registry Editor in Windows. One way to do it in Windows 10 is the following:

   1. In the search box on the taskbar, type regedit.
   2. Select the regedit by clicking Run command.

   

   Depending on computer’s User Account Control (UAC) settings, you may be prompted to confirm that you want to start the Registry Editor:

   

   
   

   In Registry Editor, paste (only available in Windows 10) the key path and hit Enter to jump directly to the folder rather than navigating through the registry explorer and because it’s much faster. Right-click in the window’s right pane and choose the New > DWORD (32-bit) Value command:

   

   Give value the name “PreferExternalManifest” and hit Enter to save it:

   

   Right-click the newly created value and choose the Modify… command. Then change the Value data to “00000001” and click the OK button to save the changes:

   

2. Next step is to make SSMS DPI-aware.

   Copy the XML code from below to the clipboard:

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">   <!--<assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="CompanyName.ProductName.YourApp" type="win32"/>   <description>Your application description here.</description>-->   <asmv3:application>     <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">       <dpiAware>True</dpiAware>     </asmv3:windowsSettings>   </asmv3:application>   <dependency>     <dependentAssembly>       <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />     </dependentAssembly>   </dependency>   <dependency>     <dependentAssembly>       <assemblyIdentity type="win32" name="debuggerproxy.dll" processorArchitecture="X86" version="1.0.0.0"></assemblyIdentity>     </dependentAssembly>   </dependency> </assembly>

   Any text editor will do the job though make sure to run it as an administrator:

   

   Otherwise, you might get a warning that you don’t have permission to save the file at the specified location:

   

   Again, based on computer’s UAC settings, you may be prompted to confirm that you want to start the text editor:

   

   Paste the code into the text editor and save the file in the installation folder where ssms.exe is located:

   

   1. The default location is “%SystemDrive%\Program Files (x86)\Microsoft SQL Server\130\Tools\Binn\ManagementStudio”
   2. Save it as ssms.exe.manifest and set the Save as type option to “All files (*.*)”
   3. Set the encoding to UTF-8
   4. Click the Save button to exit text editor and save the file

   

   Restart the machine for these changes to take effect.

   Before this “fix”, the text, icons, and other items in SSMS looked fuzzy and blurry but after the machine restart, there’s a noticeable change in almost everything (see the screenshot below before/after):

   

   The only other high-resolution display enhancement since the SSMS 16.3 (August 2016) version came out was the icons update to be consistent with VS Shell provided icons and support High DPI resolutions which was added in the initial release of SSMS 17. What this basically means is that the whole support for high-resolution displays is still just in beta testing. I’m not even sure that it will ever be official. Microsoft had brought into question are they fully committed to improving the SSMS experience or not.

SSMS 17.6

The same fix can be applied to the latest version of SSMS as well. Now that we already did step 1 and 2, there is no need to repeat that. We just need to copy the manifest file that we previously created to the installation directory of SSMS 17 which is “%SystemDrive%\Program Files (x86)\Microsoft SQL Server\140\Tools\Binn\ManagementStudio”. When copying the manifest file to this location, the folder access will be denied and you’ll have to provide administrator permission to proceed. If your account has administrator privileges, just click the Continue button:

The before/after example is shown below:

This issue can also be resolved another way. There’s a neat tool to check whether applications are DPI-aware or not called Sysinternals Process Explorer:

1. Download and extract the ProcessExplorer.zip archive from the URL above.
2. Depending on your system type, run either the procexp.exe or procexp64.exe application.
3. From the View menu, click the Select columns command:

   

4. And then add the DPI Awareness column to the view of Process Explorer:

   

5. Start the application that you want to check (in this case Visual Studio 2017).
6. In Process Explorer, locate the application, and then examine the DPI Awareness column.

Microsoft Visual Studio 2017 process is devenv.exe (find more information about a process from the Description column) and under the DPI Awareness column we can see that this application is System Aware:

System Aware: These applications do not scale for DPI changes. They query for the DPI one time, and then use that value for the lifetime of the application. If the DPI changes, the application does not adjust to the new DPI value. It will be automatically scaled up or down by the system when the DPI changes from the system value.

What this means for Visual Studio 2017 is that it supports 4K and high DPI right out the box. If we do the same for SSMS 17 it will also indicate that it’s System Aware, but this is only because of the registry key and manifest file that we created in the installation directory:

If we go back to SSMS 17 installation folder and delete the manifest file, the application will no longer be DPI-aware, and the “DPI Awareness” column will change its value to Unaware:

Unaware: These applications do not scale for DPI changes. They are always assumed to have a scale factor of 100 percent (96 DPI). These applications are automatically scaled by the system at any other DPI settings.

Whenever the Unaware value is present, that means that the application does not support 4K and high DPI and elements such as the taskbar, icons, toolbars, text, and dialog boxes appear to be fuzzy. As you can imagine, once we delete the manifest file from SSMS 2016 installation folder it also becomes Unaware.

SSMS 2012/2014

These two versions of SSMS does not include initial beta support, so the above “fix” will not work for them. If we examine the DPI Awareness for both SSMS 2012 and 2014, it will indicate that they are Per-Monitor Aware:

Per-Monitor Aware: These applications check for the DPI when they are started, and adjusts the scale factor whenever the DPI value changes. These applications are not automatically scaled by the system.

What this means in our case, is that the application does not handle 4K resolution and high DPI very well and you can expect similar visual appearance as for the Unaware applications.

DPI-scaling overrides

An easier way to stop the madness is to tweak Windows compatibility settings for applications that do not appear correctly. At least for SSMS 2016 and 17 on Windows 10 operating system.

Instead of creating the new registry value and the manifest file, locate SSMS shortcut on the desktop (this functionality can be enabled in the .exe properties) and do the following:

1. Right-click on the application icon and click Properties.

   

2. Go over to the Compatibility tab, enable Override High DPI scaling behavior. Scaling performed by and set the Scaling Behavior to Application:

   

3. Click Apply and then OK to close the window and save the changes.

Application: This forces SSMS to run in per-monitor DPI awareness mode. This setting effectively tells Windows not to bitmap stretch UI from the .exe in question when the DPI changes.

Now, Per-Monitor applications usually do not handle 4K resolution and high DPI very well but not always. In this case, enabling this option fixed the fuzziness and blurriness perfectly without enabling the beta support at all:

Display scaling and high-DPI in SSMS is, in general, a complex problem. There is no magic bullet or single fix to resolve all DPI Scaling problems but considering the fact that we’re talking about Microsoft’s applications here and not third parties we’re really missing continuous improvements from Microsoft in this field.

Disclaimer: All tests were performed on a 15.6-inch display with the resolution set to 3840 x 2160 pixels and scaling option set to 250% (Windows default values) but due to the complexity of the problem the results shown in this article might vary on other environments.

I hope this article has been informative for you and I thank you for reading.

• Author
• Recent Posts

Bojan Petrovic

Bojan aka “Boksi”, an AP graduate in IT Technology focused on Networks and electronic technology from the Copenhagen School of Design and Technology, is a software analyst with experience in quality assurance, software support, product evangelism, and user engagement.

He has written extensively on both the SQL Shack and the ApexSQL Solution Center, on topics ranging from client technologies like 4K resolution and theming, error handling to index strategies, and performance monitoring.

Bojan works at ApexSQL in Nis, Serbia as an integral part of the team focusing on designing, developing, and testing the next generation of database tools including MySQL and SQL Server, and both stand-alone tools and integrations into Visual Studio, SSMS, and VSCode.

See more about Bojan at LinkedIn

View all posts by Bojan Petrovic

Latest posts by Bojan Petrovic (see all)

• Visual Studio Code for MySQL and MariaDB development - August 13, 2020
• SQL UPDATE syntax explained - July 10, 2020
• CREATE VIEW SQL: Working with indexed views in SQL Server - March 24, 2020