UCyborg

The DLLs are versioned 1.1.8.5, just the Readme and OldNewExplorerCfg.exe are still 1.1.8.4.

Version 1.1.8.5 resolves the issue. In this case we have a mix of two, Win10 and Process Hacker. Take just one out of the equation and the bug doesn't occur. Whatever the cause. something was invoked in OldNewExplorer which it was unable to handle.

Here it Is. I did remove all other extensions, but the result was the same. No other 3rd party software was running.

Exactly, Win10 is supposed to be the greatest MS's creation!

1.5.4 is only for Creators Update. You need 1.5.3 for Anniversary Update. Before you upgrade to Creators Update, uninstall Aero Glass. When upgrade is complete, you can install Aero Glass 1.5.4.

Hey, Explorer has a new bug (feature?) in recent Insider Builds. Whatever view you pick, all items are shifted to the right by some amount. It can still be crashed by invoking back/forward action when a context menu is open while renaming a file. Deleting a file from the root of plain removable storage media still shows file size of 0 in the confirmation dialog regardless of actual size and the last modification date is missing. The last one is pretty odd. What about the performance issues that were mentioned recently? Any idea if those are being addressed?

Not directly related to API sets, but regarding MS's moving functionality around, we also have *base.dll DLLs, eg, winmmbase.dll, combase.dll, etc. kernelbase.dll was already in Win7, those two and some others came later.

I tried latest nightly build of Process Hacker (3.0.872) on Win10 Build 16257. Also installed updated OldNewExplorer 1.1.8.4. Process Hacker crashes whenever it invokes open file dialog, or when trying to run Task Manager through it. Also crashes when selecting Show details for all processes. UAC prompt never has the chance to pop up. Another thing worth noting, invoking Task Manager doesn't crash it if was started as admin. Faulting module is OldNewExplorer64.dll, always the same offset: Description Faulting Application Path: C:\Program Files\Process Hacker\ProcessHacker.exe Problem signature Problem Event Name: APPCRASH Application Name: ProcessHacker.exe Application Version: 3.0.5399.872 Application Timestamp: 5989c1cd Fault Module Name: OldNewExplorer64.dll Fault Module Version: 1.1.8.4 Fault Module Timestamp: 59848e0d Exception Code: c0000005 Exception Offset: 000000000000127f OS Version: 10.0.16257.2.0.0.256.48 Locale ID: 1060 Additional Information 1: fb70 Additional Information 2: fb706959c68a8aa2c8c0ca4a10c4e28a Additional Information 3: af7e Additional Information 4: af7e957ec4603dad0dc94c9985f92f51 Extra information about the problem Bucket ID: d19a8f27aeb048385c54f1fa428af080 (120813232493)

True. Nobody that keeps up with Windows 10 will be on Build 15063 for much longer. Just tried the current Insider Build 16257 and once again, glass effect rendering just makes it crash. If you ensure that AG can only find symbols for ApplicationFrame.dll (ApplicationFrame.pdb ), other functions work as they do on Win10 Build 15063 with the current beta version of Aero Glass 1.5.4.904. The only log entry that seems relevant says: CDrawingContext::DrawVisualTree failed 0x80004002

I don't see them neither. Maybe those DLL names internally resolve to something else? I ran a search and haven't found them anywhere in Windows folder.

I get a hang too on an occasion, weird. I don't think it's possible. It prints the DLL versions there I think. When you get that warning, something may still not work correctly under the hood. On current insider build, ApplicationFrame.pdb is mandatory for UWP apps to have their frame altered. Do you ever get any errors in the Event Viewer about some app being terminated because it took too long to suspend? You can look under Custom Views->Administrative Events (Source: Apps). I saw it, not sure about the cause. One more tip, don't ever click inside the console window. Or if you do, press ESC to cancel out from selection mode, otherwise Metro realm can come to a stall. At least I can't launch any app when it happens. UxTSB actually never gets loaded in UWP apps.

I saw a line of code once where the author wanted to allocated space for variable array of pointers, so he multiplied the variable holding amount of pointers by 4, then wrote in the comment that a pointer may not be necessarily 4 bytes in size. I found it intriguing that he took time to write that comment instead of just using sizeof keyword straight away in place of 4.

@Hadden The script gets symbols for the DLLs on your current install if they're available. Not sure how you can tell for which build are they, they're identified by checksums if I'm not mistaken. On 15063, I remember having glass on both Win32 and UWP apps. They updated things since that Aero Glass version was released so symbols had to be downloaded to get rid of the warning about inability to hook DWM. Did you run "regsvr32 C:\AeroGlass\DWMGlass.dll" (without quotes, correct the path if installed elsewhere) from admin Command Prompt? This should enable glass on UWP apps. You may need to "taskkill /IM ApplicationFrameHost.exe" for changes to apply without having to log off. This will close all running UWP apps.

Agreed, though we can only go so far. It seems that author just compiled both versions of vorbis.acm, but only tested 32-bit version. People always talk about ability to utilize more memory and security when it comes to 64-bit, but it's also nice for correctness testing. Though pointers are just one issue (some devs loved to store pointers in int), there are some trickier problems where the program that worked correctly in 32-bit mode no longer does when compiled in 64-bit mode. Sometimes application developers explicitly go against documentation. I remember reading a conversation somewhere at stackoverflow.com where the asker insisted why he shouldn't do a particular thing in DLL's DllMain function. The documentation says only very simple things can be done in DllMain, ideally it should be empty, but he wanted to do something heavy and potentially dangerous just because it happened to work when he tried it. There's one more ceveat, selecting DLL project in Visual Studio puts a tempting looking DllMain stub without any "Dragons ahead" warning. At least this is still the case in 2015 version. Either way, the workaround for vorbis.acm was a probably a good move if that thing isn't maintained anymore.

Followed by Resurrection Update! BTW, update KB4032188 apparently implements a workaround for a crashing bug (64-bit pointer truncation) caused by 64-bit vorbis.acm used by some software. One example of MS fixing other people's crap.

I tried Aero Glass on Insider Build 16251, symbols are currently available only for ApplicationFrame.dll, so restoration of regular window frames for UWP apps seems to work just like on Build 15063. One issue worth mentioning, Edge behaves oddly, clicking anything inside its window makes its frame change like in the screenshot below, it's the same on Build 15063. This also makes frame buttons refuse to respond to clicks a lot of time. When it happens, only buttons get inactive look, but frame color indicating window with keyboard focus remains, even when it does lose focus. All other functions of Aero Glass except transparency and watermark work. I wonder if it would still work if symbols for the rest of the modules were available. Or would it just crash? I'd say there's a good chance it works, but we can't know for sure. Note that the glow on the text of Edge titlebar is from before I switched back to default Windows theme to give Aero Glass' theme atlas image loading function a spin. The atlas image was extracted from sagorpirbd's Aero 7 theme.

You can only test "Use theme settings" properly if your theme has certain 2 values in it set properly. I wrote about it here. The first issue with size setting not being interpreted correctly should be easy to fix. The alignment problem might actually be bug in Windows. Anyway, the point of "Use theme settings" is so called composited text glow; compared to the other type of glow, it doesn't use atlas image as the rendering source. It seems the best type to combine with the setting for centering caption, because the atlas image based glow looks like this then: There's also a minor bug with resizing windows.

http://www.msfn.org/board/topic/176569-aero-glass-for-win81-153/?page=11#comment-1140110

Nope, no news about the current state of the project in months. So you got experimental version working now? You actually only need to bother with SDK Installer and the script I attached if you don't donate, if valid donation.key is present in Aero Glass folder, it downloads symbols on its own. They tell Aero Glass how to hook certain functions in Desktop Window Manager to provide glass effect when Microsoft changes something. It only works for smaller changes, when they rewrite some routine, Aero Glass code has to be updated as well.

In this case, it does, you need to manually get symbol files from MS server. To do that, download Windows SDK Installer and run it. When it asks which features to install, you only need Debugging Tools for Windows. When you got that installed, put the attached file in C:\AeroGlass and run it to download the symbols. Which version of Aero Glass have you downloaded? Latest Win10 version is only supported by the debug build of Aero Glass available in Experimental versions section on the website, it has no installer and opens debug console on login along with a warning that this is debug build. There is an app for changing settings in Download section, under Others. symbols.cmd

Haven't found a solution, the same problem was mentioned on some random Korean site and on extension's forums (the latter was dealing with MKV files, also Windows 8.1). There were also some hits about MediaElement from .NET Framework not working under certain circumstances, but compiling quick app with Visual Studio to test it haven't revealed any faults on my end, it worked. Nothing has been heard from extension's author for a while. This bug makes no sense.

https://www.reddit.com/r/Windows10/comments/6q2y6n/bug_in_anniversary_update_and_creators_update/ https://www.reddit.com/r/Windows10/comments/6q2wt1/bug_in_creators_update_causes_battery_drain_when/

Yes, it does, just try setting system locale to Slovenian here: After reboot, log off and back on so the session number increases and the 8x12 option disappears: Apparently picking a random language in said dialog may not reveal the bug and I haven't found the list of affected languages, I just know English US is not, Slovenian is and "windows 7 raster fonts 8x12" search term is known to Google. Coupled with the fact that the session number must be higher than 1; makes no sense at all, at least from the outsider perspective. Also noticed in Win10, Command Prompt windows maximize normally, even if you switch to legacy console. I remember this link, 10th of July. At this point, I'd also like to pinpoint another thing common to most NT systems, at least since Compatibility Engine is the thing. Process creation is a bit slower than it would be normally since the system scans the compatibility database to know which compatibility shims it should apply. There is a setting somewhere to turn it off, which might be desirable if only properly written software is run on the system. But it can be useful for some problematic legacy applications and games. Another problem with the compatibility database, some entries in there are incomplete or redundant, in some cases even making the app crash. That's why you might have heard that someone fixed some app crashing by renaming its executable. Interstate '82 comes to mind. Because Windows was applying a shim to it that it shouldn't. And not everyone knows about Compatibility Administrator. Also, compatibility modes exposed in .exe properties tend to apply tons of redundant shims. We also have Metro style wizard for user account creation in dialog accessed by running netplwiz since Win8. It locks the desktop, but not the taskbar and tries to convince you to go MS account way. There's also something strange about the Task Scheduler, opening dialog for editing task's trigger takes few seconds to open the first time. It feels fastest on Vista, at least on my side, though it's still not instantaneous the first time.

Windows 7 introduced odd bug in Command Prompt windows when it comes to Raster Fonts. With certain system locale setting (language for non-Unicode programs) and when session ID is higher than 1 (it increases each time user logs on), size 8x12 for Raster Fonts just disappears, so it falls back to 7x12. I don't know which languages exactly except Slovenian are effected. Looks like it was fixed in Win10. Another interesting issue on older Windows versions, spewing events with IDs 500 and 501 - The Desktop Window Manager is experiencing heavy resource contention. My 8.1 machine generates them on approximately 1-hour interval. Didn't happen on Win10, same graphics driver version. Video RAM usage is always below 512 MB (have total of 2 GB), not doing anything 3D heavy, warnings persist even though no performance degradation is apparent. I also see them on my two virtual machines with Win 7 and 8.1, but not on Win10 one. On with the bad news, someone noticed another performance issue: https://stackoverflow.com/questions/45024029/windows-10-poor-performance-compared-to-windows-7-page-fault-handling-is-not-sc