Hi, Listary loads itself into all processes on my system, that is expected. But it loads wrong version of Common Controls (comctl32.dll) library.
- My program does not depend on comctl32.dll statically.
- So after startup no version Common Controls is loaded.
- The program creates and activates an activation context specifying version 6.0 of Common Controls in it.
- Then it calls LoadLibrary(“comctl32.dll”) and loads version 6 of Common Controls.
- After a while Listary’s ListaryHook.dll gets loaded, it depends on comctl32.dll statically.
- BUT The default version of Common Controls (5.82) gets loaded into the process. This is bad.
- This is the same situation as if the application was compiled with ISOLATION_AWARE_ENABLED or with delay loaded DLLs.
This is bad for multiple reasons.
- Now there are two versions of Common Controls (comctl32.dll) library loaded into the process at the same time. So GetModuleHandle function might return unexpected result.
- Part of the application might be rendered in modern look and feel and other part with old look and feel.
- Listary does not respect application authors and their intends, it breaks applications.
The cause is in ListaryHook.dll (and ListaryHook64.dll) manifest. There is manifest in DLL’s resource with ID 2 that overrides currently active activation context.
The solution is to remove the manifest (resource ID 2) from ListaryHook.dll and design the Listary functionality to work correctly with either version (v5.82 or v6.0) of Common Controls.
Windows 7 x64. Listary version 5.00.2843, installer digitally signed on 2017-10-14.