Fixing Hyper-V connection display scaling on High-DPI monitors


Got myself a new mobile workstation (Lenovo P50), and was looking forward to be able to run my Hyper-V lab on this powerful beast. With a Xeon processor, 64GB ram and m12 Solid State drives I thought testing deployments would become a breeze… But what I found was that this new computer, which has a 4K display would give me quite a few headaches!

Problem is that when using Hyper-V Virtual Machine Connection to connect to the guests, it relies on the Guest OS to handle the display scaling within the OS itself. This results in very small windows for operating systems that does not handle DPI scaling like some Linux distributions and to my great annoyance Windows PE!.

So when connecting to my guests the windows looked like this:


As you might suspect these small windows would cause you to squint quite a lot to see what is going on, an reading logfiles are near impossible…

The Fix

After drawing blank at my fellow deployment gurus I started trawling the internet for a solution, several days later after reading a lot of developer documentation on display scaling I finally found a solution!

Add the following registry key to tell Windows to prefer external manifest files:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SideBySide\PreferExternalManifest=1 (DWORD value)

Place a manifest file beside the executable that you want Windows to scale properly and that’s it!


Now your Hyper-V Virtual Machine Connection scales better, and squinting is a thing of the past.

Manifest file

Add the registry key mentioned above and locate the executable that causing you problems, in this case it is the vmconnect.exe located in the Windows\System32 directory.
Download the program.manifest file attached below and rename it to vmconnect.exe.manifest and place it next to the executable like this:


the manifest file is just an xml file that looks like this:

<?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″> <dependency> <dependentAssembly> <assemblyIdentity type=”win32″ name=”Microsoft.Windows.Common-Controls” version=”″ processorArchitecture=”*” publicKeyToken=”6595b64144ccf1df” language=”*”> </assemblyIdentity> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type=”win32″ name=”Microsoft.VC90.CRT” version=”9.0.21022.8″ processorArchitecture=”amd64″ publicKeyToken=”1fc8b3b9a1e18e3b”> </assemblyIdentity> </dependentAssembly> </dependency> <trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3″> <security> <requestedPrivileges> <requestedExecutionLevel level=”asInvoker” uiAccess=”false”/> </requestedPrivileges> </security> </trustInfo> <asmv3:application> <asmv3:windowsSettings xmlns=””> <ms_windowsSettings:dpiAware xmlns:ms_windowsSettings=””>false</ms_windowsSettings:dpiAware> </asmv3:windowsSettings> </asmv3:application> </assembly>

Start your program and that’s it, no reboot needed.

Remote Desktop

After this success, I thought about other uses for this fix, one of the obvious ones were RDP connection to computers that do not handle the scaling, such as Windows Server 2008.

Before adding manifest file to mstsc.exe:

RDP before

After adding a manifest file:

RDP After

So this also works for getting a more usable RDP connection on 4K or 3K monitors.

What I have done is copied the mstsc.exe to mstsc2.exe and copied the mstsc.exe.mui language file in the en-us language folder (make change in the appropriate language folder). I then added a mstsc2.exe.manifest file allowing me to choose whether or not to correct the display scaling depending on the OS I’m connecting to.

You can download the program.manifest file here:

Download “” – Downloaded 821 times – 668 B

About the Author:

Henrik Rading


  1. Jessica May 26, 2016 at 21:30 - Reply

    Thank you for this fix, this has saved me so much time an aggravation (and my eyes)!!

  2. RaFi June 8, 2016 at 21:08 - Reply

    you can patch up the built-in manifest using mt.exe (to avoid changing registry – that can influence all programs/whole computer)

  3. Henrik Rading
    Henrik Rading June 9, 2016 at 8:48 - Reply

    thanks for the info, I will need to look into mt.exe ( I agree that if you can avoid preffering external manifest files for all files, and just change the ones you are having problems with, will be much better.

  4. Ian Yates June 25, 2016 at 11:59 - Reply

    I did something similar for SQL server management studio as several of its dialogs were not great with dpi scaling. I like the idea of applying to mstsc.

  5. Heng August 5, 2016 at 6:01 - Reply

    Thank you very much. I should find your blob earlier.

  6. Tad November 11, 2016 at 16:59 - Reply

    Ugh! What is going on with this High DPI situation!?

    High-DPI Scaling is Worse Problem Now!

    A year ago I got a Surface Pro 3 running Windows 10. When connecting to a virtual workstation you could barely see it on the high resolution screen. (Why is are there no options in vmconnect to deal with this?!?) I spent days searching the internet for a solution. Adding a vmconnect.exe.manifest file with a dpiAware=false entry solved the problem nicely with the Enhanced session. That worked just fine.

    Now, following the Windows 10 anniversary update the manifest solution no longer works and using a virtual machine from a high-dpi device is a real problem again. The Basic Session selects a screen resolution that oversizes the screen and doesn’t look good. Trying to select a specific resolution for the virtual machine reverts to the virtual machine being too small to see.

    I find it hard to believe this isn’t something thoroughly tested. Is there a solution?

  7. Richard Hayton November 29, 2016 at 17:19 - Reply

    This solution looks great – but I can’t get it to work. I’m seeing errors in event viewer
    (These appear when I add vmconnect.exe.manifest, and disappear when I remove it).
    Running mt.exe -checkManifest returns no errors (but I’m not a manifest expert!)
    I’m running on Win10 Aniversary Edition in Developer Mode.
    (I’ve tried using a copy of VMConnect.exe and changing its compatability properties to say no High DPI – but that doesn’t seem to affect the VM itself…)

    Application: VmConnect.exe
    Framework Version: v4.0.30319
    Description: The process was terminated due to an unhandled exception.
    Exception Info: System.UnauthorizedAccessException
    at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32, IntPtr)
    at Microsoft.Virtualization.Client.DpiUtilities.Init(Boolean)
    at Microsoft.Virtualization.Client.InteractiveSession.Program.Main(System.String[])

    Followed by:

    Faulting application name: VmConnect.exe, version: 10.0.14393.0, time stamp: 0x5789927d
    Faulting module name: KERNELBASE.dll, version: 10.0.14393.321, time stamp: 0x57f4c4f0
    Exception code: 0xe0434352
    Fault offset: 0x0000000000017788
    Faulting process id: 0x2708
    Faulting application start time: 0x01d24a565cf61f5c
    Faulting application path: C:WINDOWSsystem32VmConnect.exe
    Faulting module path: C:WINDOWSSystem32KERNELBASE.dll
    Report Id: db36ea20-bbe9-4b70-946e-31177a5a3cda
    Faulting package full name:
    Faulting package-relative application ID:

    Followed by:
    Fault bucket 129172684551, type 5
    Event Name: CLR20r3
    Response: Not available
    Cab Id: 0

    Problem signature:
    P1: VmConnect.exe
    P2: 10.0.14393.0
    P3: 5789927d
    P4: Microsoft.Virtualization.Client
    P5: 10.0.14393.0
    P6: 5789882d
    P7: c0
    P8: 3e
    P9: System.UnauthorizedAccess

    Attached files:

    These files may be available here:

    Analysis symbol:
    Rechecking for solution: 0
    Report Id: db36ea20-bbe9-4b70-946e-31177a5a3cda
    Report Status: 0
    Hashed bucket: b2db94673814b1d64da94a9d7360e9e7

    • Chris December 15, 2016 at 18:36 - Reply

      Hi Richard, I am having the same issue as you. Have you found a fix?


  8. Henrik Rading
    Henrik Rading December 15, 2016 at 20:49 - Reply

    Sorry for not responding to this post sooner, but I did not get any notifications on the comments…
    Unfortunately I have not yet found a solution to the problem. Microsoft have changed something with Windows 10 1607 that causes this to stop working. I have not yet found a working solution, but I will keep trying when I do get the time, as i’m also keen on getting this fixed.

  9. cy February 8, 2017 at 14:53 - Reply

    mstsc.exe.manifest is still working on 1607
    vmconnect.exe.manifest is not working on 1607

  10. Andes March 21, 2017 at 2:51 - Reply

    Hi, Nice article!
    I recently try to export vmconnect.exe to other machine and it works. But the localization seems not working well. I have only english version. How you now how can I export the language packs too? Thanks


  11. Sam February 25, 2018 at 17:43 - Reply

    This is a huge help! Thank you so much!

Leave A Comment