UCyborg

The title bar height depends on type of window application creates, for example non-resizable window will have lower bar height than a resizable window. This is in their regular non-maximized state. For those familiar with Windows API, WS_THICKFRAME is the Window Style of interest. It's odd indeed, the height should be constant. Or add an option to tweak the behavior to one's liking. Is this supposed to be some sort of accessibility feature? Can't think of the good reason for the current behavior. Someone intentionally made it like this though.

It's strange because I clearly remember graphics drivers were offered in the past if I had no driver, but they would disappear after I installed them on my own without Windows Update's help, regardless of version I installed. And AFAIK, the NVIDIA driver version 376.53 wasn't put on Windows Update servers yesterday, been up a bit longer, only yesterday they were automagically installed. And I wondered why my PC was acting funny after a trip to the bathroom! Thanks for the hint about the policy setting. Regarding default drivers' dates, never gave a lot of thought into that. Interesting blog post. That they wouldn't be touched at all since 2006 doesn't make much sense. But there is another similar convention. Check your CPU properties.

@sierra117 Did you only try Firefox to come with that conclusion regarding title bar buttons? Firefox has custom title bar. On my end, title bar gets shrinked on every application with regular title bar and it is indeed the most noticeable when you look at title bar buttons. This is with default settings, messing with those registry settings will just have a more obvious effect. Note that Windows 7 eg. has the title bar height set the same as Windows 10, and yet the title bar buttons don't appear as big. Edit: Title bar shrinks on both Windows 7 and 8, title bar buttons are only affected as they are on Windows 10. Might be because they're so much larger compared to those on 7 and 8. So when the title bar shrinks, no space is left for the buttons so they must be shrinked. And registry settings affect everything in a relative way. At least that's what I see.

Yesterday, Windows Update decided it would be best to install some broken drivers for my graphics card. I put the old drivers back and used that old troubleshooter from https://support.microsoft.com/en-us/help/3073930/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-windows-10 to keep them out. I thought Windows Update was supposed to install graphics drivers only if none are currently installed. Did they decide to change that? And this whole need for a separate app to hide updates...ridiculous.

Firefox has custom title bar so it can't be affected by Aero Glass. Install GlassMyFox addon. You can also set it to use regular title bar by opening the Menu->Customize and enabling it there.

http://glass8.eu/out/UxTSB-2016-10-19.7z These work as well. Pick the correct DLL depending on system bitness, extract it to AeroGlass folder and rename it to UxTSB.dll. I haven't noticed anything different about 64-bit UxTSB.dll bundled with the old debug build of Aero Glass. Even the hack for adjusting ribbon title caption text color is still present, even though Big Muscle said he'll remove it.

Caption glow is baked in the theme atlas image. Without special tools, you can extract it from .mssytles or replace it using Resource Hacker. It's the first item under STREAM. .msstyles doesn't have any influence on the Ribbon UI caption text, because it's rendered by the Ribbon Framework, which simply doesn't care what you put in .msstyles and renders it on its own. Classic applications are affected though, unless you use Aero Glass to override the theme atlas. Stock Win10 atlas won't help with glow though, you'll probably have to look at other people' atlases. Theme Atlas Collection for Windows 10.14393 Big Muscle's UX Theme Signature Bypass DLLs are able to add glow if you use Aero Glass' custom theme atlas feature with the right theme atlas. With the new DLL installation method, it only works with Explorer, with the old AppInit_DLLs way, it will cause certain text in certain applications being rendered with incorrect parameters. So it's a no win, a proper solution to have customized Ribbon UI caption text doesn't exist AFAIK.

Not familiar with editing theme atlases, just wanted to say that Ribbon windows are outside of Aero Glass control because their title caption is not rendered by DWM.

Looks like it. Can't access it neither.

Must be a regression. I can reproduce the bug with text being too far to the left by turning off caption glow effect. Use atlas image options work correctly.

@xemnes If you edited the PNG so it wouldn't depend on the layout file, it would be perfect. I put it in aero 2.msstyles (part of sagorpirbd's Aero 7 Clear theme) with Resource Hacker (first item under STREAM) and it works well for both regular and modern apps, there is just this whitish line near bottom border of min/max/close buttons.

Actually, both screenshots have the titlebar. The Edge's normal titlebar is special in a way that it has tabs on it instead of title text. Aero Glass has the functionality to make modern apps' titlebars look according to whatever theme you're using, but this doesn't work properly with Edge. You appear to be using stock Windows 10 theme, so I suppose you can try a temporary workaround to disable said functionality. Open Command Prompt as Administrator and run: regsvr32 /u C:\AeroGlass\DWMGlass.dll This turns it back on: regsvr32 C:\AeroGlass\DWMGlass.dll You need to log off and back on for changes to take effect.

I see, it's been a while since I used that option, I guess because things haven't been as crashy as much as they are now so i left it as it is. You got the minidump in Aero Glass folder simply because DWMGlass.dll has that functionality and is sitting in explorer.exe. You can use SetUnhandledExceptionFilter function to specify the crash handler that will be called by the system when the process crashes. From there, you call MiniDumpWriteDump. http://stackoverflow.com/questions/5028781/how-to-write-a-sample-code-that-will-crash-and-produce-dump-file That crash could be caused by anything.

@NoelC Your minidump says Explorer crashed for some reason. ClassicStartMenuDLL.dll is the only external module I can see somewhere down in the call stack. I'm curious, do you have the option "Launch folder windows in a separate process" enabled? (Control Panel->File Explorer Options) I've been using this option for few days now and it seems to help preventing the crashes at first glance, or at least delaying them so they don't occur with my usage pattern. When they would occur, it almost always happens when I interact with Explorer in some way, one example is minimizing one of the Explorer Windows then clicking the Start button. Though it doesn't happen necessarily only with Start button, one thing is certain, a lot of times, my mouse is somewhere on the taskbar when it crashes. Running virtual machine in the VMware seems to increase crash frequency, it happened few times while I was in the virtual machine.

This version still has the bug with debug.log being created in root of C drive, seems to happen when aerohost.exe starts, easy to reproduce by stopping and restarting it via Task Scheduler. Can also be triggered by registering/unregistering DWMGlass.dll, regardless of whether aerohost.exe runs or not.

Is there any difference between older UxTSB64.dll and newer UxTSB.dll besides compilation date? If not, then I suppose I'm not missing out on anything by using older UxTSB32.dll renamed to UxTSB.dll to utilize new injection method on my 32-bit system. It does seem to work, can't reproduce that DLL injection failure bug on that machine neither.

And we're still missing x86 version of UxTSB.dll.

I noticed the similar problem as CKyHC once, it occurred around Christmas time, I would get the usual spinning circle indicating logging in, then, instead of desktop showing up, I'm thrown back to the login screen, having to enter the password. I usually don't have to since I have auto-login enabled for my account. There is the same VirtualAllocEx error logged at said time frame. Cold vs fast startup doesn't change anything either, would probably have to keep rebooting PC (for cold startup to be effective) or turning it off and on again (for fast startup to be effective) all day before the bug would occur again, if at all.

Then I'm afraid I can't help you with this one as I'm unable to reproduce it on my end.

I cannot confirm DWMGlass.dll has any effect on those options whatsoever. Registered or not, if starting point in Explorer is This PC before navigating anywhere else, they will remain disabled until navigating to an actual folder/drive on PC. You can't cd to This PC from command line I think. And it's logical since they're meant to open the command line in directory you're currently in. And if it can't use that, it uses last valid location from navigation history (back/forward buttons).

This is fixed in latest experimental version: http://www.glass8.eu/beta If you don't want to use experimental versions, you must wait for the new stable version.

Sounds like you're trying to use the atlas that's not compatible with Win10 Anniversary Update.

Oh right, you need another DLL for that: http://glass8.eu/out/ModernFrame-2016-10-22.7z Drop it in AeroGlass folder, then add C:\AeroGlass\ModernFrame-x64-Release.dll to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs. Paths to multiple DLLs must be separated with space or comma. Then reboot.

Here's a screenshot of interesting experiment, I ran Paint with CustomNCRender option from Compatibility Administrator, part of Windows 10 ADK. Regular applications will just get the frame you got on Windows 7 with disabled DWM, aka. Windows 7 Basic, not Aero. I could grab it by the invisible frame, resize it, but couldn't close it by clicking where close button would normally be. Process Hacker's window commands weren't effective neither. Anyway, I think this clearly demonstrates what is under DWM control and what isn't. CustomNCRender option supposedly leaves entire non-client area of the window under application control, though regular applications still get backup basic frame without fancy effects. I forgot to mention that CustomNCRender is available only for 32-bit applications. And strangely, it doesn't do anything for the Wordpad.

Yes, the only reason Explorer is handled differently is because UxTSB.dll is injected in Explorer and it hooks DrawThemeText/DrawThemeTextEx function to change the text appearance, which I suppose is called by the underlying ribbon framework. But even there, eg. if you click any hard drive in my PC, Drive Tools appear in the title bar and I don't think that's supposed to have its drawing parameters changed. But given the purpose of those APIs, you can't tell from the parameters they take what exactly is it being used for, so I think it would appear properly only if you intercepted at the exact place where call is being made, not when when you're already in the function. But that's probably cumbersome to implement and isn't solving the problem that the text is still under user application control making the call, in this case indirectly via ribbon framework. I'm not really knowledgeable about how these thing actually work under the hood, so I can only point at stupidities from the user perspective. There is also this oddity in Firefox for example, unless you set it to use regular titlebar without extras like tabs and buttons on it etc., hovering the mouse over close, min. and max buttons will overlay ugly blue rectangles over them, instead of simply taking light-up versions of those buttons from the theme. Even if you use stock Win10 theme, hover-over version of buttons is inconsistent with the rest of the system, at least if you have good eyes to notice. GlassMyFox is apparently only able to restore non hover-over versions of the buttons. But with ribbon windows, title text has to be special, even though other elements on the frame are fine.