UCyborg

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.

I have same issue, really annoying, I had to reset explorer.exe everytime Do any of you have "Launch folder windows in a separate process" enabled in File Explorer Options? It's been a while since I've seen this bug and I did turn this on some time ago, maybe enabling it helps. Though it might also depend on Explorer usage pattern. Unless you have always at least one Explorer window open, this option makes the explorer.exe instance that hosts those windows restart every once in a while, so maybe it proves to be a viable workaround.

@Tusticles Thanks for the hint! I found the most important properties are under Windows & Captions Buttons -> Aero -> Window. We can only hope that at least bugs in Aero Glass will be fixed sometime.

@Lum Strange, Hyper-V presence shouldn't change hardware ID. At least it doesn't happen on my end. @Tusticles Which theme you're using that has this type of glow you get in the first screenshot?

OK, I understand now that running aerohost via srvany doesn't solve DLL injection problem. So we're still at the dead end...

Disable option in Task Scheduler doesn't stop it if it's already running, must select End and then Disable. That's the only possibility for ending up with 2 running aerohost instances I could think of. So if you just select disable in Task Scheduler and run the script to install it as service, you end up with 2 instances. But after a reboot, you should have only 1 aerohost started by srvany.exe.

Indeed, anti-virus programs love to flag useful non-malicious stuff for various reasons. Check out this blog post: http://blog.nirsoft.net/2009/05/17/antivirus-companies-cause-a-big-headache-to-small-developers/ File system modifications can certainly be malicious, not in this case though, and the warning on the website about total Windows breakage is just so you don't blame the author if something goes wrong. It's true however that using custom themes always carries a small risk of breaking something. What happens if Windows Update replaces those files with originals and you don't switch back to stock theme until files are re-patched? You won't make it to your desktop because Windows rather commits suicide instead of falling back to stock theme. Big Muscle's theme signature bypass DLLs lasted for quite some time, they just broke now with Creators Update. It's a wild goose chase with custom themes in general, need to keep up with how they change under the hood. From Anniversary Update to Creators Update in its current state, it seems they haven't changed drastically under the hood.

So it really works now? Starting aerohost.exe with the method I posted? You said you did disable the scheduled task the first time. I can confirm Pipe error occurs if you try to run 2 aerohost.exe instances.

It's hard to say. Type of disk and passworded vs passwordless account could be influencing factors in your particular case. Would be interesting to know what happens if you set passwords on those 2 computers you said don't have passwords. Apparently that extra time it takes to type in password helps on your computer with SSD. My machines have regular HDDs and using passwordless account works fine. All this still doesn't explain why VirtualAllocEx fails. Just access denied is not verbose enough. Does UxStyle work on your end? I suggested it some time ago as its different approach might work, the only problem is that it still needs some fixes; not working on build 10586 and Creators Update builds, in some scenarios its service has to be restarted for the themes to work again and it's been said its driver doesn't load on UEFI systems with Secure Boot due to signing requirements.

Just an idea. Interestingly, on Windows 8.1 majority of log entries don't appear, while on Windows 10 they do, so something changed in that regard. Either way, I don't think that problem would be solved by changing aerohost.exe into service. There is nothing particularly special about services, just that they interact with Service Control Manager. Would the problem occur on completely fresh bare-bones Windows installation? I don't have any other ideas besides maybe some 3rd party software interfering somehow. I have 4 different machines at home and none of them have this issue. Sorry, can't help you with this one.

Install AeroGlass in C:\AeroGlass.

Exactly, applications that are run under SYSTEM account run indefinitely unless you fully shut down or reboot the system. This just makes it independent from the Task Scheduler so maybe it starts sooner. Better solution would be modifying aerohost.exe to accept service events. srvany.exe is the wrapper that can make any application run as the service, but it is obsolete and has number of limitations. It's true that you can't make aerohost.exe directy run as the service with sc create. https://www.coretechnologies.com/products/AlwaysUp/srvany.html Then you have paid solutions like FireDaemon Pro or AlwaysUp. Those are the must if you want to run eg. a game server which wasn't coded as the service. There is also free NSSM. I can't really say if this helps with anything as I can't reproduce the injection problem on my end neither, but those are the only ways to run non-service application like it was the service. If it actually helps, judging by UxStyle source code, it doesn't seem it would take a lot of effort to turn aerohost.exe into real service.