UCyborg

I suspected it might be some other software interfering, that's why I suggested safe mode with added Themes service and aerohost in the other thread. So it was system-wide VirtualAllocEx hook that prevented allocating memory in winlogon.exe. Maybe try srvany.exe trick again now and see whether that makes login always successful the first time around?

@Dblake1mentioned the possibility of accessing classic personalization panel in the other thread. I don't know if anyone made a list, you'd probably have to crawl through registry to find these things, assuming they're still there in the first place. In that command, the first GUID is the Control Panel, the second is the personalization panel. One common thing these entries seem to have at the first glance is the registry setting System.ControlPanel.Category (HKEY_CLASSES_ROOT\CLSID\{insert GUID here}). CLSID key has tons of other things. Anyway, I found the entry for the taskbar dialog, but it just opens the Settings app.

Any chance for updated version 1.4.6 with UxTSB.dll injection feature like the newer versions?

Unless they changed something in the latest build, AppInit_DLLs should still work. Then you need to invoke the classic personalization control panel: explorer.exe ::{26EE0668-A00A-44D7-9371-BEB064C98683}\0\::{ED834ED6-4B5A-4BFE-8F11-A626DCB6A921} If the latter is gone, you have to use Settings app to change the theme. For that to work, manually inject UxTSB.dll in SystemSettings.exe, AppInit_DLLs doesn't work for modern apps. Alternatively, try and see if Aero Glass 1.5.2 without symbols works. Aside from DLL injection, some basic things like RoundRectRadius setting and caption text with glow might still work, at least it did for me on build 15063. You'll still have to use Process Hacker in case they removed the old personalization control panel.

The double edged sword when it comes to disabling services when something mysteriously breaks like that.

The 0 bytes issue? I tried flipping EnableLUA to 0 and no change after reboot.

That's crazy! Do you have any other machine where you can reproduce it? Does it happen irregardless of flash drive used? About the bug I mentioned, I got it on 3 different machines at home running updated build 14393, plus on a VMware virtual machine with freshly installed latest and greatest build 15063. The strangest thing is, it shows size as 0 bytes only for the files directly on the drive, for files in subfolders, it works correctly. Behavior seems to be identical irregardless of flash storage used, as long as it's treated as regular removable storage media, so MTP doesn't count.

Does anyone else get this bug: plug in USB flash drive or similar type of storage device, then try deleting a file from its root. The dialog asking if you want to delete a file should report its size as 0 bytes regardless of the actual size.

I noticed that installer erroneously modifies AppInit_DLLs in registry to load non-existent ModernFrame.dll on Windows 8.1.

Regarding resource extraction, you can also use Resource Hacker, the first item under STREAM is the PNG you're looking for.

It might be possible if one knows some tricks, which would apparently be required to implement this correctly. OldNewExplorer is good at reverting certain behaviors in Explorer, this might be one of the things you could add to Fix-Newer-Windows-File-Explorer-Oddities list. I went back to Windows 8.1 on my main machine after recent incident. Stlll, this information might be useful to someone else. I wonder how Windows 10 will be in general after 2 years from now, particularly when it comes to regressions like this.

This turned out to be a bit longer than intended, but someone may find my recent experience interesting, otherwise, feel free to skip the following 3 paragraphs. My decision whether to stay with Windows 10 or go back to 8.1 on my old trusty desktop was made easier by a recent BSOD I got during troubleshooting the update problem (UNEXPECTED_STORE_EXCEPTION), which left some serious corruption in the file system. The system was half-broken after a reboot, couldn't even open Computer Management. Running chkdsk afterwards from Recovery fixed a lot of errors, but also purged a lot of OS related data, which rendered it unbootable. Suddenly there was approximately 20 GB of extra free space on the OS partition. It could be that at one point in time, possibly after Anniversary Update, some sort of incompatibility arose with the customized driver for my motherboard's SATA controller. It was occasionally reporting some generic error for all my disks in event log. The motherboard is from 2008 and the last time drivers for its chipset were updated was back in 2010 when Windows 7 was the latest version. Despite the error, nothing appeared out of the ordinary for the long time, which makes this case even stranger. Been running Windows 10 since build 10586. Testing hardware doesn't indicate any failures, RAM is OK, S.M.A.R.T. parameters are normal, not a single sector had to be reallocated in the past, no read or write errors etc. Windows 10 still functions on my own and family members' laptop, all of which have newer hardware. The only problem encountered few weeks ago was the Intel graphics driver failing to update properly on one machine via Windows Update, surprisingly, I got the newer driver to work without much hassle; rolling back to the old one from Device Manager, running uninstaller from Program and features, rebooting, then it could be magically updated via Device Manager without a problem, which installed the same version from Windows Update. Still, it shows how unreliable Windows Update can be, even when it offers the driver that does actually work fine, but somehow fails installing it properly so the user is stuck with low-resolution mode. The first thing I've noticed when installing Windows 10 is how much longer it can take to boot, especially on cold startup where fast startup aka. resume from hibernation isn't involved. If Windows 8.1 and 7 could be ready in 30 seconds or less, Windows 10 can take whole minute. While SSD disks are the norm these days, there's no reason for a PC with a decent classic HDD to not feel reasonably snappy. Although the type of hard drive isn't the only contributing factor, the difference can be really astonishing. This reminds me of the most silly argument I've ever heard from Microsoft from the time Windows 8 was released: We've made startup process so fast that we don't let you press F8 anymore to let you access the boot menu. Faster boot times being popular argument in favor of Windows 10, yet I'm seeing the exact opposite results. Fast startup is compensating for bad startup performance more than ever in Windows 10, and it's still faster in 8.1. Windows 8.1 with fast startup enabled and without disabling anything manages to get me to the desktop so fast that Welcome screen doesn't even have the time to appear! My main monitor needs 3 seconds to display the image after receiving initial signal when the display driver takes over (it's not plugged in the first DVI port). Then just add 2-3 seconds for the Windows boot screen. Windows 10 always took its time before it was ready. Can also observe the slowness when comparing with virtual machines. Perhaps this script could turn things around in such scenario? Will definitely give it a go next time I'm messing with Windows 10. Someone reported the tweaker script cut memory usage from 70% to 30% on a machine with 1 GB of memory. That's very impressive! Seems like Microsoft is updating OS but not the minimum hardware requirements for optimal experience. On Windows 8.1 with Classic Shell after taking care of few checkboxes, Metro stuff can be easily ignored. NTLite may be worth checking out, though you don't get all of its functionality for free. I still don't get the decision for removal of things like MIDI Mapper and GUI allowing full control over wireless connections since Windows 8. On the other hand, you still find policy settings applicable for older systems dating as far back as Windows XP in Group Policy Editor. But additions in Windows 10 still make the OS heavier than it should be, regardless of whether the user utilizes them or not.

Are you using Internet Explorer by any chance? If so, you must right-click on it and select Save target as... You also need 7-Zip or similar archiving utility which supports extraction of contents of 7z archives.

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.