UCyborg

I use the wireless adapter to connect the laptop to home router, therefore granting it internet access and making it part of home LAN. By bridging its wireless and wired adapter, I can connect the desktop computer to the laptop's ethernet port to make it part of the LAN as well. The only catch is, one computer must have manual IP settings, if both use automatic settings (DHCP), they get the same IP address. The problem that I had that is gone now, if the "Connect automatically when this network is in range" checkbox was checked in the properties of the wireless connection, the connection would be dropped in about 15 - 30 seconds (I don't remember exact time). Until then, both computers could normally access the internet. Trying to re-connect would again make it work only temporarily. When I went and cleared that checkbox and re-connected, the connection stayed. I just had to manually connect to it every time I turned the laptop on. Only when the Creators Update released, I tried again to see whether it would work with that checkbox checked, and indeed it works now as expected. There were no other changes that I'm aware of. The only tips I found at the time was to check power-saving features on the wireless adapter, manually enabling promiscuous mode and changing roaming sensitivity level, but since they didn't change anything, I reverted them to default settings. When you have the bridge, IP settings are managed from the properties dialog of the bridge, if you open the properties of the actual network adapter that is part of the bridge, it will just tell you to configure settings from the bridge's properties and give you the button that takes you there. So if I had things configured manually on the laptop, I would have to input the same IP settings in the bridge's properties as I would in wireless adapter properties if I didn't have the bridge setup and would only use the wireless adapter. In both scenarios, I deal with only one network, home LAN, bridge just allows me to connect the desktop to the LAN since I can't connect it directly to the router with the way things currently are in my house.

Here's another mystery when it comes to Windows 10's File Explorer. For those not familiar with Link Shell Extension, it adds functionality for managing NTFS hardlinks/junction points directly in Explorer's context menus. In addition, it alters those files/folders icons that are actually hardlinks, junction points etc. so they can be distinguished from regular ones. But on Windows 10, the icons remain the same, the correct icon is displayed only in the file's properties. The question is, why is that?

You need a mouse with at least 4 buttons for this to work. Mouse buttons 4 and 5 usually function as back/forward buttons. Navigate to any folder, start renaming a file/folder, right click on the text box to open the context menu, then press mouse button 4 (back). If there is a previous folder to go to, Explorer will crash. Any application that uses its standard open/save dialog can be crashed this way as well. That's right, you can crash one of the core Windows components by simply "pressing the wrong buttons". And the bug isn't present in Vista! And somehow, nobody noticed at MS or maybe even worse, thought it wasn't worth the hassle to fix.

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.