DPI-unaware uninstaller?

Hi, my uninstaller was DPI-unaware.

I found the reason, if not the cause.

Deleted the entry and solved the issue.

My theory is that the registry flag was set during a setup, but why the DPIUNWARE?

I'm keeping an eye on it. The 'bin' folder is used for Zip achives that require a password, and when their contents has been silently extracted they are then permanently deleted.

Other than that, I don't know. I hope it was a one-off.

Thrilled to see that you found a solution! And it makes sense if that compatibility mode was set against an earlier version of one of your uninstallers during development / testing. Reading through the previous HiDPI thread, it seems there is one time when you had set "ManifestDPIAware False" (on 20 June 2022?) just to test what happens - perhaps that set the registry flag? Or is it possible that at one time you tried changing the compatibility settings of the uninstaller via File Properties? I would never have guessed that File Properties would make a permanent registry entry against that specific location of the executable file, though.


These two SuperUser threads seem to have some information on how the AppCompatFlags\Layers registry keys work:

https://superuser.com/questions/1637...bility-setting

https://superuser.com/questions/1095...e-in-windows-8

ManifestDPIAware false does not cause this.

It is a conincidence that 7z.exe, cited on SuperUser https://superuser.com/questions/1637...bility-setting, is the software I use to create the archives in the 'bin' folder, the temporary location of the archives as well as the location of the uninstaller. 7zFM.exe is the file manager which isn't supposed to run. As far as I know I doesn't run. A user might not even have 7-Zip on their system.

I fooled around with the compatibility mode while searching for an easy explanation for the uninstall binary's apparent dpi-unawareness. At the time "Properties > Compatibility > Change high DPI settings > Override high DPI scaling behavior" was unticked. Bearing that in mind however, uninst.exe had recently been uninstalled and then reinstalled, so it is perhaps possible that the box was ticked previously and the tick did not show up. I'm not sure what the connection between the Properties box and the registry entry is either, to be quite honest.

It did not occur to me to look in the registry on June 20th.

(Why would ManifestDPIAware write to the registry?)

I am watching the 'bin' folder and 7-Zip. It creates archives during the compilation process.

; 7-Zip self-extracting archive (Igor Pavlov) - password encrypted
!system '"${7z}" a -sfx -t7z -m0=lzma2 -p${PW} -mmt8 -y htmlexev.exe $%TEMP%\program.exe'
!system '"${7z}" a -sfx -t7z -m0=lzma2 -p${PW} -mmt8 -y htmlexe.exe program.exe'
!system '"${7z}" a -sfx -t7z -m0=lzma2 -p${PW} -mmt8 -y html.exe text*.htm add*.htm \
mo_t*.htm mo_a*.htm file1.htm file2.htm file3.htm file4.htm file5.htm file6.htm'
!system '"${7z}" a -sfx -t7z -m0=lzma2 -p${PW} -mmt8 -y .\acroice\pdf.exe .\acroice\*.pdf'
!system '"${7z}" a -sfx -t7z -m0=lzma2 -p${PW} -mmt8 -y .\acrohome\pdf.exe .\acrohome\*.pdf' 

Each of the archives self-extract when the user enters the password on the NSIS Password page.

Could an archive extraction have triggered dpi-unawareness for the 'bin' folder?

More than likely I did something. My Windows 11 is pretty new. Testing the NSIS setup was among the first things I did. Possibly it happened then.

It is working, there has been no recurrence, and the 'un' folder was also fine for two weeks. What more can I say? I don't accuse NSIS. I'm sorry if that was the impression my posts gave you.

Thanks for the follow-up.

Originally Posted by rgreen View Post

I fooled around with the compatibility mode.... I'm not sure what the connection between the Properties box and the registry entry is either, to be quite honest.

Modifying the compatibility mode from Properties or by running the Compatibility Troubleshooter sets those registry entries. Windows will check those registry entries when loading a program so that the compatibility settings can persist between launches, and so it knows which compatibility settings to use when launching from that file path next time.

I just gave it a try on Windows 10, and setting High DPI Scaling Override on the EXE to "System" results in that "~ DPIUNAWARE" flag being stored immediately in the registry for that file path, though in my case it was stored in the registry at:

HKEY_USERS\[uniqueidhere]\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers

It also stored some binary data in:

HKEY_USERS\[uniqueidhere]\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Store

Deleting the EXE file from the computer does not remove those entries from the Registry.

So - not NSIS related (as you've already realized), but hopefully the info is helpful to someone else who encounters similar problems.