Solved Global DPI Scaling Disable for Win8.1 for all files/users
- Thread starter aph
- Start date
There was an error in my OP, I had an environment variable as a compatibility flag. I corrected it so the first change should be made in another place.
You can use this in conjunction with Windows 8.1's per-screen DPI settings to get the result you are describing
Hello! I'm new. It looks like this thread has been around for a while. And yes, new people are curious, me included.
I read through your registry update. I understand adding HIGHDPIAWARE to all of those Windows applications, at lerast. I'm not sure what the first three keys do, it would be nice to know what affects they have (I know you say it's a bunch of complicated stuff, but again, I'm curious).
Okay, now the real question( s ). I'm using a Surface Pro 2, which looks great at 150% DPI, and two 23" external monitors, which look great at 100% DPI. The closest I've gotten to making everything look good together is using the Display DPI properties, letting Windows adjust the DPI per monitor, and selecting the second-to-Smallest setting. This results in most applications looking good everywhere, with the exception of some Windows components (which I guess you are fixing) and software like Microsoft Office.
I personally have tried adding the HIGHDPIAWARE values for winword.exe or outlook.exe, and received mixed results... In some cases, the application would lay out like a desktop app and be clean and sharp, but then look terrible on the Surface itself, or in other cases the app would look great on the tablet portion but then on the desktop monitor size itself with everything all spread out so touch could work... I don't know.
If we use this registry update - what does it fix, exactly? Am I correct in saying this doesn't allow per-monitor DPI setting (I can't tell Windows to make my externals 100% and the SP2 150%) but it makes many Windows applications DPI aware so they'll adjust the way they should on the different monitors?
I checked out the OP finding this thread after a couple of months and the file attached does the least intrusive thing that always seems to work--the only case where it doesn't that I've seen is on some files flagged as protected in the Windows folder.
It adds a right click context menu entry to .exe files to "Disable DPI scaling" which is equivalent to clicking Properties, Compatibility, Disable display scaling on high DPI. It allows multiple selections of .exe files and even folders. Using it on a folder causes it to traverse the folder tree and mark all executables inside the folder and subfolders as DPI-aware.
There is a more powerful, but less reliable method I've attached to this response (DPI Fix.reg). It doesn't always work, but when it does it prevents from having to manually add files to the high-DPI-capable list. I've seen best results when using right after a fresh install, and apparently getting similar results after deleting the AppCache value under the AppCompat key. I didn't bother to track down the exact cause/effect relationship once apps started behaving the way I wanted.
Both can be used at the same time
It adds a right click context menu entry to .exe files to "Disable DPI scaling" which is equivalent to clicking Properties, Compatibility, Disable display scaling on high DPI. It allows multiple selections of .exe files and even folders. Using it on a folder causes it to traverse the folder tree and mark all executables inside the folder and subfolders as DPI-aware.
There is a more powerful, but less reliable method I've attached to this response (DPI Fix.reg). It doesn't always work, but when it does it prevents from having to manually add files to the high-DPI-capable list. I've seen best results when using right after a fresh install, and apparently getting similar results after deleting the AppCache value under the AppCompat key. I didn't bother to track down the exact cause/effect relationship once apps started behaving the way I wanted.
Both can be used at the same time
What DPI Disable.reg does is the least intrusive thing that always seems to work--the only case where it doesn't that I've seen is on some files flagged as protected in the Windows folder--it adds a right click context menu entry to .exe files to "Disable DPI scaling." It's equivalent to clicking (Properties) -> (Compatibility) -> (Disable display scaling) on high DPI. There is more detail in my response above.
Since the goal is to mark the app as DPI capable and allow it to scale using its own WMF methods, you will get unpredictable results whether the app shows up properly scaled depending on your definition of that. The 8.1 way is to make everything big and adds a blurry looking effect to the upscaled window. This marks the app as capable of doing its own scaling even if it is not marked that way in its application manifest (an internal list of specs and functions that are part of the app.)
Most of the time that makes apps scale to the correct dimensions without blurriness. Sometimes an app won't scale up at all, and sometimes it will scale up halfway--with elements out of place on a properly resized canvas, for example. My goal was to prevent the automatic upscaling and blurriness that results. So to your question about per-monitor DPI, I actually don't know how it works on different sized screens since mine are all the same size. I'm guessing it should disable that on apps it's applied to since Windows is led to believe they are high-DPI capable.
AssaultCommand
New Member
- Messages
- 1
The registry edits made everything wonky and weird.
Thanks for all the effort you put into it though.
I take it to reverse the effect I just have to empty all the values set with this?
10/10 would not run again.
Thanks for all the effort you put into it though.
I take it to reverse the effect I just have to empty all the values set with this?
10/10 would not run again.
Haha, I laughed at the 10/10 part...
But, sorry you had that trouble. The last thing I want is for that to happen. I made a reg file to reverse everything:
Thank you Aph for posting your solution to this blurry DPI fiasco!
The AppCompatFlags HighDpiAware trick wouldn't work for me and, after some investigation, the culprit turned out to be the __COMPAT_LAYER=HighDpiAware variable in HKCU\Environment. This apparently makes no sense, as both the variable _and_ the flag are even documented somewhere, and are supposed to work like that. I thought that it might have been caused by a type mismatch but neither the type REG_SZ nor REG_EXPAND_SZ makes it work. Anyway, getting rid of it was what made the blur go away, so I thought I'd share this fix.
I tested this on mmc.exe. For running from the command line, I also needed to wipe the variable from the HKLM environment, HKCU was enough for Win+R, Win+X and Win+W style execution.
BTW, you have "^ HIGHDPIAWARE" in the .reg file, and "~ HIGHDPIAWARE" in your .bat file. Windows seems to use ~ when creating its own AppCompat entries. To the extent that I've checked it, both, as well as a plain "HIGHDPIAWARE" seem to work just the same. I guess the latter just replaces all the flags, whereas ~ and ^ are some sort of logical or bit-wise OR but if anyone knows the exact difference in how ^ and ~ are evaluated, please do shed some light.
Thanks again, Aph!
Update: It appears that setting __COMPAT_LAYER to "HighDpiAware" or "HIGHDPIAWARE" has the same effect as setting it to "blah", that is: (1) the flag is not intepreted, (2) it also stops any registry flags from being processed. I'm testing this on a fresh installation of W8 SP1 Dec 2014 with all the available updates and hotfixes installed as of now, so it'd be interesting to know if it used to work before what version it was on. Or perhaps there's another explanation....
The AppCompatFlags HighDpiAware trick wouldn't work for me and, after some investigation, the culprit turned out to be the __COMPAT_LAYER=HighDpiAware variable in HKCU\Environment. This apparently makes no sense, as both the variable _and_ the flag are even documented somewhere, and are supposed to work like that. I thought that it might have been caused by a type mismatch but neither the type REG_SZ nor REG_EXPAND_SZ makes it work. Anyway, getting rid of it was what made the blur go away, so I thought I'd share this fix.
I tested this on mmc.exe. For running from the command line, I also needed to wipe the variable from the HKLM environment, HKCU was enough for Win+R, Win+X and Win+W style execution.
BTW, you have "^ HIGHDPIAWARE" in the .reg file, and "~ HIGHDPIAWARE" in your .bat file. Windows seems to use ~ when creating its own AppCompat entries. To the extent that I've checked it, both, as well as a plain "HIGHDPIAWARE" seem to work just the same. I guess the latter just replaces all the flags, whereas ~ and ^ are some sort of logical or bit-wise OR but if anyone knows the exact difference in how ^ and ~ are evaluated, please do shed some light.
Thanks again, Aph!
Update: It appears that setting __COMPAT_LAYER to "HighDpiAware" or "HIGHDPIAWARE" has the same effect as setting it to "blah", that is: (1) the flag is not intepreted, (2) it also stops any registry flags from being processed. I'm testing this on a fresh installation of W8 SP1 Dec 2014 with all the available updates and hotfixes installed as of now, so it'd be interesting to know if it used to work before what version it was on. Or perhaps there's another explanation....
Last edited:
Glad it could help someone. Thanks for contributing.
Windows creates both ~ and ^ depending where it's set. The compatibility tab in properties sets ~ and the troubleshoot compatibility tool sets ^. In PowerShell lingo ~ is a concatenation operator and ^ is (I believe) a string replacement. But in practice they don't seem to make any difference since other flags like RunAsAdmin still get passed along just fine with ^.
Windows creates both ~ and ^ depending where it's set. The compatibility tab in properties sets ~ and the troubleshoot compatibility tool sets ^. In PowerShell lingo ~ is a concatenation operator and ^ is (I believe) a string replacement. But in practice they don't seem to make any difference since other flags like RunAsAdmin still get passed along just fine with ^.
This is really interesting. I've had trouble for a long time with mmc after initially getting it to be blur-free and thought it had to do with the AppCompat cache. Clearing it in the locations I could find never helped and your findings would explain why.
In the course of layering on fixes it seems adding the Environment var was counter productive. It's odd because inspecting a high-DPI-forced app in Process Explorer shows that var in the Environment tab. I guess it can only be set at runtime and not as a global variable.
Thanks for pointing this out. I will definitely try it. I'm almost certain you're right but I'll edit if I don't get the same results.
Meanwhile I've also discovered I needed to remove the "{^, ~,}HIGHDPIAWARE" entry for "C:\Windows\System32\cmd.exe" from "...AppCompatFlags\Layers", otherwise it would set the "__COMPAT_LAYER=HighDpiAware" environment variable, which (contrary to any reasonable expectations) makes things such as "mmc.exe" blurry again when started from the command line. Despite this being an elevated command prompt, only the HKCU entry seems to be processed. Maybe it has something to do with AppCompatCache but I didn't investigate, I removed both entries (in HKCU and HKLM).
It's a pity this environment variable thing can't be put to work as the best solution out of this mess would clearly be to enable global "high-DPI awareness", with a per-process opt-out (exactly the opposite of what MS decided to go for) and setting the environment variable would seem like the easiest solution to achieve this (if it worked).
It's a pity this environment variable thing can't be put to work as the best solution out of this mess would clearly be to enable global "high-DPI awareness", with a per-process opt-out (exactly the opposite of what MS decided to go for) and setting the environment variable would seem like the easiest solution to achieve this (if it worked).
Update 9/10: Funny how this thread is getting responses 4 months later. I solved it and hadn't looked back, but the first part had mixed up the keys for environment variables and compatibility layers. Here's my all in one solution:
That's it! Stop reading here.Code:Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Environment] "__COMPAT_LAYER"="HighDpiAware" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment] "__COMPAT_LAYER"="HighDpiAware" [HKEY_USERS\.DEFAULT\Environment] "__COMPAT_LAYER"="HighDpiAware" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] @="^ HIGHDPIAWARE" "C:\\Windows\\explorer.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\userinit.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\wininit.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\winlogon.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\smss.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\cmd.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\csrss.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\runonce.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\services.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\mmc.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\svchost.exe"="^ HIGHDPIAWARE" [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] @="^ HIGHDPIAWARE" "C:\\Windows\\explorer.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\userinit.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\wininit.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\winlogon.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\smss.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\cmd.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\csrss.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\runonce.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\services.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\mmc.exe"="^ HIGHDPIAWARE" "C:\\Windows\\System32\\svchost.exe"="^ HIGHDPIAWARE"
Now you did it. There's a whole bunch of reasons this works that spans acronyms long enough to build a bridge with. It's components, managed assemblies, common runtimes, manifest preference, policy merging, environment inheritance, process invocation.... or if you prefer your acronyms: COM, GAC, MSIL, NI's, CLR, DCOM, PCA, MSDT, EDB and all their struts like XML serializers that keep track of this stuff. This is a sledgehammer that puts them to rest.
This is really where you should stop reading. If you continue past this point and apply the settings to you graphics adapters, those will work, but you may get all sorts of out of range memory issues. Like hitting PrtScr and your computer freezing. I was desperate and crossed the line there, but am leaving the info for reference. The reg fix above is safe and works.
After all of that, do I still have to set any of these registry keys below?
Or do I need to delete or disable these by setting to dword:00000000 ?
HKEY_CURRENT_USER\Control Panel\Desktop
"Win8DpiScaling"=dword:00000001
"LogPixels"=dword:000000060
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM
"UseDpiScaling"=dword:00000001
Similar threads
