UCyborg

There is this annoyance in Windows 10's Explorer, if the user enables desktop slideshow and Automatically pick an accent color from my background, the scrollbar will jump up on each desktop background change, which triggers accent color change which is actually indirectly responsible for current Explorer behavior. It seems unlikely, from various responses over the internet, including Reddit, that Microsoft will ever address this, so probably the only hope would be coding some hack to remedy this. I came up with a very simple prototype DLL that can get rid of this annoyance. #include <Windows.h> #include <easyhook.h> HOOK_TRACE_INFO H_WindowProc_info; LRESULT (CALLBACK *O_WindowProc)(HWND, UINT, WPARAM, LPARAM); LRESULT CALLBACK H_WindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { if (uMsg == WM_SETTINGCHANGE && !wParam) { return 0; } return O_WindowProc(hWnd, uMsg, wParam, lParam); } BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { if (fdwReason == DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hinstDLL); HWND hWnd = FindWindow(TEXT("CabinetWClass"), NULL); LONG_PTR WndProc = GetWindowLongPtr(hWnd, GWLP_WNDPROC); LhInstallHook(WndProc, H_WindowProc, NULL, &H_WindowProc_info); ULONG ACLEntries[1] = { 0 }; LhSetExclusiveACL(ACLEntries, 1, &H_WindowProc_info); LhGetHookBypassAddress(&H_WindowProc_info, &O_WindowProc); } else if (fdwReason == DLL_PROCESS_DETACH) { LhUninstallHook(&H_WindowProc_info); LhWaitForPendingRemovals(); } return TRUE; } This is just proof of concept. It seems intercepting certain WM_SETTINGCHANGE messages so they never make it to Explorer and therefore prevent it from refreshing whatever things it refreshes gets rid of the annoying behavior. I use EasyHook library for function hooking. There could be downsides, can't say for certain if there are cases where certain important system setting changes that would make the Explorer receive WM_SETTINGCHANGE with zero wParam and it would be a good thing to reload whatever settings it reloads. The problem I'm facing, I have to somehow intercept window creation process and then hook its window procedure. The above code will only work for one already existent window, need to make this thing dynamic. I must be missing something obvious because if I hook the RegisterClassW function to get the address of window procedure to hook it (obviously I interfere only when the class name is CabinetWClass), the hook isn't called at all then, but LhInstallHook function doesn't return a failure. I think I'll try hooking one of CreateWindow functions next then use GetWindowLongPtr to get its window procedure address and hope that works. Edit: It seems each window uses its own dynamically allocated window procedure, but I don't know how it's set, SetWindowLongPtr apparently isn't involved. Must be set when window is ready somehow. Thought this'd be easier.

Probably not, at least not significantly. My excuse for running latest Windows version is that it usually runs the widest collection of software/games. Unless you're fan of UWP apps, I don't see any advantage. Sure, there are some small nice things there and there, but are they really worth it? My main Windows 10 installation decided to crap itself, update KB4014329 just refuses to install with ERROR_SXS_TRANSACTION_CLOSURE_INCOMPLETE. Usual remedies don't help, neither sfc /scannow nor Dism /Online /Cleanup-Image /ScanHealth find any corruption, tried with /RestoreHealth anyway and specified good install.wim from fresh ISO image, still no go, Windows Update troubleshooter supposedly found and fix some corruption in Windows Update database, nope, still won't install, manually cleaned Windows\SoftwareDistribution after stopping Windows Update, no, that's not it neither. Needless to say, I did reboot between each troubleshooting step and ruled out hardware failures. At this point, who knows if it would even upgrade to 1703 without some fail in the middle of the process. Might just disable Windows Update completely and stay with the current build. Or I could go back to Windows 8.1, that option would also work well for me, it just takes time to set everything back to the way I like it. Either way, the OS should be transparent and not stay in the user's way. Windows 10 seems to be exceptionally good at doing the exact opposite. Now, you're excepted to fight the OS every few months. Not in Microsoft's opinion, you're supposed to take it as it is.

The easiest way is using Aero Glass GUI. Go to Theme & appearance tab and decrease Blur effect radius. Opacity can be controlled under Glass color tab but only if you pick constant frame color, as Automatically compute from desktop background option leaves it under system control.

PE Viewer, the one bundled with Process Hacker.

Is it just me or do the executables have random future timestamps in the PE header?

Would be nice if people bothered to read the whole thread, it hasn't grown into a super long thread. There was a hint on the first page that the Creators Update compatible version is in the works, it'll just take a while. So it'll turn to 1704 when it releases.

You could try and see if it works in safe mode. There is a trick to get Aero Glass working in safe mode, first, install it as the service just to get rid of dependency on Task Scheduler (see http://www.msfn.org/board/topic/170945-uxtheme-signature-bypass/?do=findComment&comment=1136296), maybe you could just enable Task Scheduler in safe mode instead (I haven't tried), but this way, you keep things to a minimum, then, you have to add both Aero Glass and Themes services to the list of safe-mode enabled services (see the attachment). AeroGlassSafeMode.zip

Agreed. This feature for restoring modern app frames to have theme defined appearance has been considered experimental for quite a while and it seems it's not quite there yet. I think that detail about tablet mode is important to know for testing purposes, otherwise one could suggest just running Edge, since it's one of the apps that don't require Microsoft account, but guess what, it doesn't have full-screen toggle AFAIK. Don't forget you can just turn that particular Aero Glass feature off (http://www.msfn.org/board/topic/176569-aero-glass-for-win81-153/?do=reportComment&comment=1136963), so at least the functionality isn't effected in negative way. There is also a minor bug with caption centering feature, when application resizes its own window and TextGlowMode is set to 0 or 3, the caption isn't always centered right afterwards. The easiest way to reproduce the bug is with Command Prompt window. Right-click on its frame, go to Properties->Layout then change Width under Window Size to something smaller than default eg. 80 and confirm the new setting. Then return to Properties dialog and set it back to 120.

You can create new DWORD EnableLogging in registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\DWM and set it to 1. Although I'm afraid it won't give any more useful info for this scenario, but worth a try I suppose.

No. Here's a hint for everyone, this isn't app-specific issue. It can be reproduced in any modern app, simply activate Tablet mode. A note about SeDebugPrivilege, it seems it's enabled by default when running under SYSTEM account.

Yes, 0x00000000 is okay, my point was, 0x00000003 no longer produces glow effect, have to set it explicitly to 0x000c0003. I played with DrawThemeTextEx a bit and from what I've observed, if you don't enable DTT_GLOWSIZE flag in struct member DTTOPTS.dwFlags, then the function will use TEXTGLOWSIZE value from .msstyles, otherwise, it takes DTTOPS.iGlowSize. Just so that we're on the same page, I tested with modified aero 2.msstyles from Aero 7 Clear theme. Your guide also says for TextGlowMode: 0x3=Composited glow effect using your theme settings. HIWORD of the value specifies glow size (0 = theme default). That's why I think something strange must have happened from 1.5.1 -> 1.5.2. I was also curious about the possibility of Aero Glass controling GLOWINTENSITY property, but it looks like DrawThemeTextEx doesn't offer any control over it, bummer. So subtracting a little from RECT.left is not a solution in this case?

Aero Glass is not your ordinary type of software. Ordinary applications don't care about Windows internals, so things are simpler. I still didn't get symbols on my 32-bit installation this morning, but version 1.5.3 which knows everything it needs to work is released.

Which can look pretty ugly, but the composited glow effect looks nice: It seems you have changed the behavior when registry setting TextGlowMode is set to 3. In 1.5.1 and earlier, the size WORD set to 0 meant use the value from .msstyles, in 1.5.2 and 1.5.3 zero means no glow. Old behavior seems to make more sense. For this setting to have any effect at all, GLOWINTENSITY property in .msstyles must be non-zero in .msstyles (http://i.imgur.com/McXdF28.png) so if the person doesn't use custom .msstyles, he doesn't have access to this kind of glow. Is intensity something Aero Glass could control if the user desires? As long as people understand there is no clean way to control these parameters for applications that draw captions on their own, as those questions have arised in the past and you don't really get an answer unless you dig into the whole theme hacking and related matters. If you use TextGlowMode set to 3 and leave caption text left-aligned, there remains the bug with text being shifted slightly to the right, the same problem you've fixed in 1.5.2 for glow effect from atlas image. It only shows when both size setting in UI and GLOWINTENSITY property from .msstyles are non-zero. A note about things to come, it seems changes in current Creators Update builds are extensive enough that will once again require modifications to Aero Glass internals when it releases. If I remember the build number correctly, there were symbols available for 15055, and it crashed with an error saying it couldn't find symbol CGeometry::GetShapeDataNoRef. It's great to see a new update! I noticed the bug with debug.log being created in the root drive is gone as well. I wonder about the practical effects of SeDebugPrivilege addition, supposedly being mandatory to inject code in critical system processes, one would assume it was there before.

Regarding registry settings, it was never stated they're supposed to be there, you have to create them yourself or use GUI. And no need to create new topic, these things have been discussed before. You can't do much but wait and hope for a new bug-fixed version to come out. Aero Glass on Windows 8.1 is a better experience, though that fact doesn't help us much on Windows 10.

I think we're lucky if we get fixes for existing issues. It's so close to perfect. This auto-update idea reminded me of another possibility, would it be possible for DWMGlass.dll to clean-up after itself on unload? That'd be neat. It crashes if you unload the DLL. I wonder why in recent Windows versions Unload option in Process Hacker works for dwm.exe while in regular processes it throws "Unable to find the module to unload."

Would be a nightmare if it was one window per process and you had a lot of windows open.

Because that's not the job of theme signature bypass tool. By original design, applications that draw controls on window frame, must then also draw window caption using DrawThemeText API. UxTSB.dll just hooks that function and if random application uses it for something else, you get unexpected results like these: The cleanest solution for the most consistent experience accross applications is modifying theme to enable text glow like it was on Windows 7, take note of TEXTGLOWSIZE and GLOWINTENSITY properties: Then set "Caption glow effect mode" in Aero Glass GUI to "Use theme settings". At least that is supposed to get you default Windows 7 behavior, the problem is the long-present bug in Aero Glass with text not being rendered at correct position. For now, I use the option that takes glow from atlas image, so I have one type of glow for regular windows and the other for ribboned windows. Though it's not connected to ribbons, it's the customized frame. The other type you get is composited glow controlled by those two properties I mentioned. Aero Glass only overrides TEXTGLOWSIZE, so no glow if GLOWINTENSITY is 0. I think the glow from atlas image is exclusive to captions of regular windows. And so is custom colored caption text without UxTSB.dll in every process (AppInit_DLLs method). Not in Creators Update.

I see, it seems we all have a little different experience. I figured that since I'm on Windows 10, "Launch folder windows in a separate process" is a must for me, I've been getting frequent Explorer crashes before, almost every other day. Are you saying "Launch folder windows in a separate process" gives you separate process for every explorer window? I only have one extra process, regardless of how many windows I open. I usually use tabs given by QTTabBar extension. One constant thing on my end is that Explorer process' memory usage rises with time. The one that hosts its windows is now at 157 MB and it's been running for more than 9 hours, even though I haven't had any window opened for a while.

I just realized why you can't use unsigned theme on Creators Update without editing registry, the theme selection settings have been moved to Settings app. Manually injecting UxTSB.dll in SystemSettings.exe with Process Hacker 2 makes it work!

The second service is kernel-mode driver that does the actual patching. UxStyle doesn't work on Creators Update at all, it didn't work properly on November's Update neither. I wasn't the only person where it prevented graphics drivers from working on each boot: http://virtualcustoms.net/showthread.php/69833-Discovered-a-problem-with-UxStyle-Community-Edition-for-Windows-10 It needs updating. So until then, you're good with UxStyle. PS:

It fails at allocating memory in winlogon.exe's virtual address space to store path of the DLL to load, it's not connected to the fact that you're using Russian Windows, file permissions also shouldn't have anything to do with it, otherwise it wouldn't work at all on your home system, not even whey you slowly type password. I was wondering if there exists a general purpose injector, but found nothing flexible enough for this task. Would be good to know if using some alternative produces any different results.

It seems when there are permission issues, only these entries appear in logs: [2017-01-25 02:59:38][0x2024:0x3E8] Installing DWM hook... [2017-01-25 02:59:38][0x2024:0x3E8] User: SYSTEM [2017-01-25 02:59:38][0x2024:0x3E8] Module: C:\AeroGlass\DWMGlass.dll There is this convention that applications shouldn't write to their own directory, and this restriction on Program Files has been implemented by default at least since Windows XP, though a lot of people probably used admin account for everything. Before UAC was the thing, admin accounts get full access on program Files directory automatically. So the worst that can happen probably is that Aero Glass can't write its logs. There is this catch, DWM doesn't run under SYSTEM account so once DWMGlass.dll is injected, it does everything under DWM's account. And there is some magic in there that lets it access user specific settings in registry.

Correct settings in .msstyles really gives you working composited text glow. Aero Glass GUI "Use theme settings" option with theme defined text glow size is also the most consistent variant because the text caption text will be look identical across application, whether they use plain window frame or draw their own controls on it before drawing caption with DrawThemeText API. Unless for example you want custom colored caption text. But I think it boils down to the fact that these things are unofficial extensions that were never intended by Microsoft so the original design doesn't account for them. Glow effect baked in theme atlas image you get with "Use atlas image" is also Aero Glass exclusive concept if I'm not mistaken. There is another issue with "Use theme settings" on 1.5.2 besides being rendered at incorrect position. Setting glow size to 0 means 0 instead of theme defined size.

You're right, it shouldn't cause problems, I tried. Even having 2 aerohost instances doesn't cause injection problem on my end neither.

Correction: themes still work on newer insider builds, just selecting them under Themes doesn't work, have to manually set path to .msstyles in registry then it works after re-logging in.