UCyborg
Content Type
Profiles
Forums
Events
Posts posted by UCyborg
-
-
What's the good place to report these things without it being ignored? There are two issues when it comes to cooperation of legacy DirectDraw apps with the Desktop Window Manager, one is specific to Windows 8.1 (and I guess 8 too) There's this delay when you switch away from fullscreen app if the desktop runs at the same resolution and refresh rate as the app, it waits 3 seconds for the event that is never signaled. The Windows 8 specific issue is that if maximized windowed mode is disabled to allow real fullscreen, most ddraw calls just error out if you have the desktop extended through multiple monitors. The first issue could theoretically be patched at runtime, but this whole thing with patching Microsoft's DLLs to better support those ancient apps is getting old, as if the certain apps themselves don't have enough bugs.
Anyway, back to topic, I'm pretty sure they must have gotten some of the crash reports for this particular bug in the past. I doubt I was the first one who came across it, I do remember seeing the crash with explorerframe.dll as the faulting module in the past, the only difference is, I brushed it off as random crash and wasn't paying attention about reproduction.
11 hours ago, bphlpt said:The above action does NOT crash Explorer for my Windows 7 x64, so I cannot replicate this issue.
Someone over Reddit said he had that mouse button mapped to Alt + left arrow combination, in which case the keypress cancels the context menu so it doesn't crash afterwards. It's also possible that the issue surfaced up later with some update.
54 minutes ago, greenhillmaniac said:Amazing how such a small thing can trigger a crash.
Indeed, and then you see how rushed Windows 10 is, which is a good recipe for the issues to clutter up. Instead of the next OS being better than the old one, it looks like they all have their own quirks. Weren't there times when we agreed the new system is better in most, if not all aspects than the old one?
1 -
I just tried updating Windows Defender on a virtual machine. Have Windows Defender disabled by policy, so I enabled it and tried updating. It said that it couldn't (connection issues), but the definitions version increased. Then I restored virtual machine snapshot to a previous state and tried again, this time it worked without errors. But when I click Update again, here comes Connection failed error. Decided to reboot, Update, and now it goes through a lengthy process again (except Installing part), no errors. Click Update again and bam, Connection failed.
0 -
Hopefully he's just really busy IRL and will return to the project once things clear up. But you never know.
0 -
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.
0 -
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?
0 -
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.
3 -
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.
0 -
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.
0 -
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.
2 -
Scrolling inactive windows surely seems to be the art on Windows. Don't forget about other utilities mentioned on that Superuser page I linked.
1 -
On 11. 5. 2017 at 4:06 PM, NoelC said:
WixMouse.exe - An accessory that directs mouse wheel events to hovered-over windows.
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.
0 -
Recently, this update popped up for Windows 8.1 and apparently also Windows 7 machines:
0 -
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.
4 hours ago, neoandersen said:Please give steps how to apply it to Aero Glass
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.
1 -
I've concluded that my issue is not connected to Aero Glass.
0 -
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.
1 -
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.
0 -
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.
0 -
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?
0 -
@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.
0 -
Any chance for updated version 1.4.6 with UxTSB.dll injection feature like the newer versions?
0 -
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.
0 -
The double edged sword when it comes to disabling services when something mysteriously breaks like that.
0 -
The 0 bytes issue? I tried flipping EnableLUA to 0 and no change after reboot.
0 -
43 minutes ago, Shining Escuridao said:
Ironically I have a similar bug whenever I plug in a flash drive however, rather than displaying the size incorrectly a dialog appears saying that I cannot delete the file despite it behaving as though it did; and yes there is no program using the files... Win10 at its finest
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.
0
And somehow, nobody noticed at MS or maybe even worse, thought it wasn't worth the hassle to fix.
Link Shell Extension issue
in Windows 10
Posted · Edited by UCyborg
Wow, thanks a lot! There were 6 OneDrive entries (OneDrive1, OneDrive2, ...). OneDrive is disabled by group policy. After removing its entries, LSE's icon overlays work. There were total of 11 entries under that key, maybe it would work if OneDrive wasn't disabled, I'd have to try and see.
Edit: re-enabling OneDrive doesn't seem to change anything.