UCyborg

There used to be a bug when it comes to bridging a wired and wireless network adapter. When you had a bridge setup and connected to some WiFi access point, if you set it up that it connected to the access point automatically when it's in reach, it would drop connection after few seconds, supposedly because in other scenarios, it wouldn't make sense to have multiple adapters connected to the same gateway. This drove me nuts! Took me a while to figure out how to get it to work; I had to disable automatic connection. Anything but obvious workaround. I wonder when it was fixed and whether it's present in older OSes, must have been some update between October 2016 and April 2017 or it was Creators Update when the bug disappeared. Another WiFi related annoyance that is still present, why does it connect instantly when you set it up to connect automatically, but not if you try to connect manually. There's at least 10s delay, and you have to sit and wait for that spinning circle to disappear. And don't dare to close that pane until it connects, you just cancel the whole thing otherwise.

Disregard my previous post, I made it because I noticed another DWM error in event log, but it looks like it doesn't actually cause any malfunction in practice, I haven't seen a single glitch in Aero Glass 1.4.5 operation ever since. Occasional AeroHost timed out message would appear in debug.log, but nothing else that would suggest something is seriously wrong. Didn't have to restart DWM once. There's one more observation that might be worth mentioning regarding version 1.4.6 and later Win10 specific versions. Sometimes, I would have a maximized window open on the second monitor and minimizing it would leave its traces on the screen until something else that was drawn there cleared them up. This is a bit more difficult to come across, might need to be glued to the screen for a longer period of time, eg. 5+ hours and there might have to be some other not really obvious condition present. It's weird, but I think I would've come across it by now given the time I've been using 1.4.5, but I haven't. Edit: Eh, never mind, my computer's just being weird at random times. I guess inconsistency of these strange events made me believe it had something to do with Aero Glass. Guess I'll just live with it.

The only issue I've encountered so far is inability to set the theme with Settings app on Win10 Creators Update. The workarounds are described some posts back. Obviously the easiest solution might be waiting for new Aero Glass build and use its method for UxTSB.dll injection which should take care of these things automatically. If there are reliability issues with said method, the workaround is to have it sit on login screen for few seconds. Multiple user accounts or one password-protected account without enabling auto-login feature accomplishes that and allows things to settle.

Scrolling inactive windows surely seems to be the art on Windows. Don't forget about other utilities mentioned on that Superuser page I linked.

Windows 10 does this natively, interestingly, it doesn't work for Excel (confirmed for 2010 - 2016). WizMouse has an odd bug that would make mouse pointer temporarily lag under certain circumstances and looks like I'm not the only one who experienced the issue: https://superuser.com/questions/548141/windows-scroll-without-focus Ability to scroll in applications that don't support mouse wheel scrolling is a nice idea, though it seems it depends on individual application whether it works or not. KatMouse is a little better at it than WizMouse, if only it didn't stop working after some time (again, might be under unknown special circumstance). Actual Window Manager (not free, 60-day trial) has this feature as well, seems to work similarly to Windows 10's native function, plus no problems with Excel. There is an interesting quirk with UAC enabled, if elevated window has keyboard focus, it only allows scrolling other elevated windows, but not the regular ones and vice-versa. There are couple more utilities, but these are the ones tried.

Recently, this update popped up for Windows 8.1 and apparently also Windows 7 machines: KB3008923 Blog post about it Relevant comment on another site

I do mess with Windows 8.1 and 10 virtual machines more frequently these days and see the effect of being thrown back to the login screen occasionally with Aero Glass' injection method. This morning, the Windows 10 machine even crashed with KERNEL_MODE_HEAP_CORRUPTION, something I've seen only on that OS when theme fails to load and the system isn't patched to accept them. Windows 8.1 in comparison just loops infinitely with a black screen. As an experiment, I wrote a bare-bones service some time ago that just injects DLL into winlogon.exe the same way as Aero Glass (CreateRemoteThread) and the logon problem can still occur, on Windows 8.1 as well. When you think about it, it's not that strange. After all, you're at the mercy of how the scheduler schedules threads. With AppInit_DLLs, you get 100% reliability simply because everything is taken care of at the early stage when user32.dll loads. With CreateRemoteThread, you're randomly spawning the thread in the target process in undetermined state to load the library and hoping it'll work. It's independent of Aero Glass, the only important thing is you put all DLLs in the same folder and the path to that folder doesn't contain spaces. Also, it won't work on systems with secure boot enabled and future updates to Windows 10 may throw out AppInit_DLLs mechanism entirely. The UxTSB DLLs are in here: http://glass8.eu/out/UxTSB-2016-10-19.7z Then get my ZIP file and put the appropriate DLL in the same folder as UxTSBxx.dll. For both archives, you pick the DLL with the number 64 in the name assuming you have 64-bit Windows. Then install with the correct registry file I'm attaching below. It assumes you've put the DLLs in C:\AeroGlass, which can be corrected with Notepad if needed. UxTSB64Loader.reg UxTSB32Loader.reg

I've concluded that my issue is not connected to Aero Glass.

I wrote a simple and quick loader DLL for UxTSB DLL. It can be placed in the same folder as UxTSBxx.dll and installed with AppInit_DLLs method. The loader DLL will simply check if the process name is winlogon.exe or explorer.exe and only load the actual UxTSBxx.dll if it is then the loader DLL will be unloaded from memory. So AppInit_DLLs method can be used without breaking the ability to use .deskthemepack files and UxTSB DLL won't hang around in other processes. UxTSBLoader.zip

I've seen some visual glitches with 1.4.6 too, sometimes I noticed a black rectangle that flashed really quick around the taskbar clock area and the similar glitch would be seen when opening start menu, black flashing rectangles little above the start button on the bottom start menu border. So far, everything seems fine with 1.4.5, now I just need to see whether any errors pop up through the course of the following week.

I've been using this version for about a month since I've switched back to Windows 8.1 on my main rig and I've noticed some problems I don't remember from the last time I was on Windows 8.1. The only difference is the updated software, so up-to date Windows, Aero Glass 1.4.6 instead of 1.4.5 and a bit more recent NVIDIA drivers version 368.81 instead of 347.88, can't play DOOM (2016) at decent frame-rates with the old ones. I also have 2 monitors instead of one. The thing I've noticed, I consistently get this error in the event log on boot: The Desktop Window Manager has encountered a fatal error (0x8898008d) Now I'm thinking it must be a combination of Aero Glass and newer graphics drivers. Sometimes, but now always, the error is accompanied by the following errors in debug.log: [2017-04-27 11:52:17][0x99C:0x162C] AeroHost timed out [2017-04-27 11:53:22][0x6E4:0x8A8] Failed to query user token (2 - The system cannot find the file specified.) Which results in Aero Glass operating with default settings. Restarting DWM helps. Disabling Aero Glass completely gets rid of the error in the event log. I'll give version 1.4.5 a shot first to see whether it makes any difference and report back in the following days. Edit: Here's the full log from today, just removed machine ID related messages: [2017-04-27 11:52:06][0xBD0:0x1634] Message 0x1E, wparam = 0, lparam = 0 [2017-04-27 11:52:07][0xBD0:0x1634] Message 0x218, wparam = 7, lparam = 0 [2017-04-27 11:52:07][0xBD0:0x1634] Message 0x218, wparam = 18, lparam = 0 [2017-04-27 11:52:07][0xBD0:0x1634] Message 0x219, wparam = 7, lparam = 0 [2017-04-27 11:52:08][0xBD0:0x1634] Message 0x46, wparam = 0, lparam = 552741894752 [2017-04-27 11:52:08][0xBD0:0x1634] Message 0x47, wparam = 0, lparam = 552741894752 [2017-04-27 11:52:08][0xBD0:0x1634] Message 0x3, wparam = 0, lparam = 68222976 [2017-04-27 11:52:08][0xBD0:0x1634] Message 0x219, wparam = 7, lparam = 0 [2017-04-27 11:52:08][0xBD0:0x15A4] Uninstalling... [2017-04-27 11:52:11][0x99C:0x1090] Hook (USER32.dll!DrawTextW from udwm.dll) installed [2017-04-27 11:52:11][0x99C:0x1090] Hook (GDI32.dll!CreateBitmap from udwm.dll) installed [2017-04-27 11:52:11][0x99C:0x1090] Hook (GDI32.dll!CreateRoundRectRgn from udwm.dll) installed [2017-04-27 11:52:11][0x99C:0x1090] Aero Glass for Win8.1+ 1.4.6.610 x64 correctly loaded (C:\AeroGlass\DWMGlass.dll). [2017-04-27 11:52:12][0x99C:0x162C] DBGHELP: Symbol Search Path: .;SRV*C:\AeroGlass\symbols*http://msdl.microsoft.com/download/symbols [2017-04-27 11:52:12][0x99C:0x10E0] Message 0x46, wparam = 0, lparam = 676567316768 [2017-04-27 11:52:12][0x99C:0x10E0] Message 0x47, wparam = 0, lparam = 676567316768 [2017-04-27 11:52:12][0x99C:0x10E0] Message 0x3, wparam = 0, lparam = 67895296 [2017-04-27 11:52:12][0x99C:0x10E0] Message 0x46, wparam = 0, lparam = 676567316768 [2017-04-27 11:52:12][0x99C:0x10E0] Message 0x47, wparam = 0, lparam = 676567316768 [2017-04-27 11:52:12][0x99C:0x10E0] Message 0x3, wparam = 0, lparam = 66977792 [2017-04-27 11:52:13][0x99C:0x10E0] Message 0x46, wparam = 0, lparam = 676567316768 [2017-04-27 11:52:13][0x99C:0x10E0] Message 0x1A, wparam = 24, lparam = 676567316808 [2017-04-27 11:52:13][0x99C:0x10E0] Message 0x1A, wparam = 0, lparam = 676567316776 [2017-04-27 11:52:13][0x99C:0x10E0] Message 0x320, wparam = 2905420950, lparam = 1 [2017-04-27 11:52:13][0x99C:0x10E0] Loading settings (flags = 0x2) from HKEY 0x0000000000000000 for session #6 [2017-04-27 11:52:13][0x99C:0x10E0] Settings reloaded [2017-04-27 11:52:13][0x99C:0x10E0] Message 0x15, wparam = 0, lparam = 0 [2017-04-27 11:52:17][0x99C:0x162C] AeroHost timed out .[2017-04-27 11:52:17][0x99C:0x162C] Loading settings (flags = 0x3) from HKEY 0x0000000000000000 for session #6 [2017-04-27 11:52:17][0x99C:0x162C] dwmcore.dll version 6.3.9600.17795 [2017-04-27 11:52:18][0x99C:0x162C] udwm.dll version 6.3.9600.17415 [2017-04-27 11:53:22][0x6E4:0x8A8] Failed to query user token (2 - The system cannot find the file specified.) Looks like DWM was still active from yesterday's session, at the same time debug.log says Uninstalling the event log spits out a fatal error 0x8898008d. Just checked event log more thoroughly and noticed that it isn't actually that frequent, every 4 days at average...with consistent occurrence only in the last 2 days.

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.