UCyborg

Still on HDD here. Memory allocation requests by applications have priority over SuperFetch cache, so I guess there's no need to panic over SuperFetch's memory usage. Also have to consider, if one wants to observe its effect, that it's learning patterns of what stuff user runs and surely those algorithms can't predict the unpredictable when user strays of the usual habits. Purely anecdotal and non-scientific; after fresh install and running the same things daily, it may have shoved a second or two of startup time of your average program. By average, I mean something not as simple Notepad, but not a long loading program like Photoshop and newer Visual Studios neither. .NET programs might be interesting to measure, especially if they pull in various assemblies. Or any native application with a lot of DLLs. Of course, you'd have to define "a lot"; DLLs vary in size and then there's also whether it can be loaded at its base address that will affect its load time. Historically, picking optimal base address for the DLL is one optimization, though it requires the developer to be aware of it as de facto toolchain (Visual Studio) doesn't do anything to pick the optimal address; you get the default unless you change it. Another factor affecting startup time is PE loader scanning compatibility databases and applying compatibility shims (if needed). ReadyBoost; an interesting concept technically, albeit a bit silly as a long term solution. Reminds me of the ability to utilize SD card as a swap space on Android smartphones. I did experiment with that on my old Samsung Galaxy Mini and it helped significantly in keeping apps running instead of terminating them due to running low on memory. But, didn't want to reduce the SD card's lifetime, so in the end, I chose not to use it.

Don't touch that button! Didn't they also say at some point that clicking it is also expressing interest in upgrading to the new supposedly stable build of the OS (if it's released yet)?

Yes, I do, it could be the reason. It's back at 1,16 GB ATM after closing programs (with approximately 40 MB in the pagefile). Can't complain about most programs' startup time. I did read stories about Superfetch acting up for some people, including consuming larger amounts of memory. There is usually brief disk activity on behalf of that service after startup and logging in. I'll do some experimenting with it if the need arises. When did they change its display name? It's seen as SysMain instead of Superfetch.

Thanks, will do!

I got an email from @Martin24, he says he has trouble accessing the site as registered member. It started with him not receiving notifications on his email address and when he tried changing it to alternative one he has, he got stuck at the page asking to confirm his email address. He doesn't receive confirmation email. Can anyone help him?

Not much else besides the usual crap. Might just be the footprint of all the services. I just find it odd that it fluctuates, eg. at one point when I don't have anything open it's 1,25 GB and at the other it's 1,5 GB. Do fluctuations in standby memory also have anything to with it? If I understand correctly, it shouldn't, but who knows. Today, it's at 1,57 GB. I did disable a bunch of annoying scheduled tasks. Can always go back to version 1803 anyway. Kinda hoped they'd fix the bugs with compositor with thumbnails getting lost when certain 3D applications change resolution, but the behavior remains identical. And those changelogs they write for each update are a bit deceiving. How would they look like if regressions from previous builds/updates were clearly marked, eh?

AutoColorization also seems to have more noticeable negative performance impact on Win10 1809. When it changes, currently running window animation gets quite choppy. Windows 8.x sends more WM_DWMCOLORIZATIONCHANGED messages to applications and the color transition remains nice and smooth, while it's more abrupt on Win10. So performance degradation is even less logical. There's probably bigger impact with more applications running simultaneously.

Does anyone else have crash reports similar to this one in their Event Logs? Faulting application name: dwm.exe, version: 10.0.17763.1, time stamp: 0xe52aabf3 Faulting module name: dwmcore.dll, version: 10.0.17763.168, time stamp: 0x23095d3f Exception code: 0xe0464645 Fault offset: 0x000000000002a054 Faulting process id: 0x133c Faulting application start time: 0x01d4923d8cfce927 Faulting application path: C:\Windows\system32\dwm.exe Faulting module path: C:\Windows\system32\dwmcore.dll Report Id: cf7afade-9544-4a04-87ec-69a96e95dd73 Faulting package full name: Faulting package-relative application ID: It's not connected to Aero Glass, but I've noticed it on both Windows 10 1803 and 1809. Happens when the user session is closed (log off, shutdown, ...). And what does the exception code 0xe0464645 mean?

Is there anything written somewhere on the phenomenon of changing device boot order affecting which disk will be picked for writing boot files? In my case, both Windows and Linux see disks (I have 3) in the exact same order. It's consistent with the numbering of the corresponding SATA ports. Changing device boot order in BIOS does not change the order in which they appear in either OS, but it does affect which disk will be picked to write boot files to when installing Windows. I never experimented with what would happen if the first target disk didn't have active partition. Would it just look for the next and error out if it doesn't find it or error out right away? Another scenario to consider. I suspect such error would be shown on the interface where you pick where to install the OS. Wish I remembered if anything different was shown on the disk selection screen back then. Does it show all active partitions on every disk as System or just the one it finds suitable to write boot files to?

Don't hold your breath. Unless they sit down and actually start polishing things, there's no hope for such inconsistencies to get addressed, especially since we're talking about the part of the interface that is seen the least of the time.

Is there anything interesting here? Or am I looking for some other number? The only difference on the software side are the newer graphics drivers, 397.93 -> 411.63. Also noticed in event log that dwm.exe crashes when logging off/shutting down, the same happens on 1803 on my end. Doesn't matter whether Aero Glass and custom visual style are present. Speaking of visual styles, looks they were updated a bit to support dark mode in File Explorer. Now compare this to one of the full blown dark themes made years ago: https://www.deviantart.com/bigcyco1/art/purgatory-181435735 The dark mode in its current form is just another inconsistency.

That thing with 1,5 GB RAM was yesterday. It's better today (at 1.25). Can't tell what it was, must have been something made by Microsoft. Something not residing in the user session... They copied link to the Media streaming options from the Network and Sharing Center -> Change advanced sharing options to the main panel of Network and Sharing Center on the left side. The task PerformRemediation, the one that "Helps recover update-related services to the supported configuration." is disabled by default. It doesn't try to update with Configure Automatic Updates policy disabled anymore when you visit Windows Update page in Settings like in 1803, the way it should have been all along anyway. Same with Function Discovery* services that need manual intervention on 1803 for them to start if needed. If code compiles, ship it! It really was a perfect day for a walk today. It's Patch Tuesday, so here's KB4471324. There are still known issues.

This should be avoidable by making sure the disk on which the OS will be installed comes before others in BIOS boot device order.

The driver is already present on XP, but the INF file to set it up is only included out-of-the-box on Vista+. Copy this to Notepad, name the file wceisvista.inf and save to C:\Windows\INF: ; ; Remote NDIS based Internet Sharing device Setup File ; Copyright (c) Microsoft Corporation ; ; WceIsVista.INF -- This is the inf installation script for ; RNDIS-over-USB host driver for Intenet Sharing device. ; [Version] Signature = "$Windows NT$" Class = Net ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318} Provider = %Microsoft% DriverVer=06/21/2006,6.0.6000.16386 [Manufacturer] %Microsoft% = WindowsCeDevices,NTx86,NTamd64 [WindowsCeDevices.NTx86] %WindowsCeDevice% = RNDIS.NT.5.1, USB\Class_E0&SubClass_01&Prot_03 [WindowsCeDevices.NTamd64] %WindowsCeDevice% = RNDIS.NT.5.1, USB\Class_E0&SubClass_01&Prot_03 [ControlFlags] ExcludeFromSelect=* ; Windows LH specific sections ----------------------------------- [RNDIS.NT.5.1] Characteristics = 0x84 ; NCF_PHYSICAL + NCF_HAS_UI BusType = 15 include = netrndis.inf needs = Usb_Rndis.ndi [RNDIS.NT.5.1.Services] include = netrndis.inf needs = Usb_Rndis.ndi.Services ; no sys copyfiles - the sys files are already in place [Strings] Microsoft = "Microsoft Corporation" WindowsCeDevice = "Remote NDIS based Internet Sharing Device" Then try to get Device Manager to install it. If all goes well, it'll only complain about unsigned driver.

Version 1809 is a mess. Notifications don't work with background apps setting off, resolution switches can cause them to appear off-screen and it complains about the firewall being turned off even with firewall monitoring disabled. Also the bloody thing eats 1,5 GB of RAM when just staring at the empty desktop. It was approximately 1,1 GB or so with version 1803 on my end.

Version 1809 doesn't seem to change anything regarding the background on shutdown/restart screen.

Anti-virus and such software tend to guess about any file they don't know about so they flag a lot of harmless and useful stuff. It's safe. Just the feature that allows the same window caption text color as set in AeroGlass to be applied to ribbon windows doesn't work since the feature relies on Big Muscle's DLL to be injected in every process (which also causes the problem with .themepack/.deskthemepackfiles). Though there's a better way to set that color by modifying the theme's visual style file. This works flawlessly on Windows 8.x, but they made some changes in Windows 10 that causes inactive caption color to be mixed with another color that is hardcoded. Similarly for active caption color, 2 colors are used, one is read from the visual style file and can be changed and the other is hardcoded. Which one is used depends on the brightness of the window frame background color. Confirmed to work on Windows 8.x/10.

Getting word out is not a problem, but going against terms of use is. Besides, it's a good netiquette to link to the official source of whatever you're promoting. This. A lot of people out there who think they're entitled to something. Anonymous mask that the internet gives tends to make people behave even shittier than they otherwise would. I like that idea. Then the general public won't be able to complain about debug windows and watermarks, though admittedly, there's always something to complain about. But honestly, directing frustration at Big Muscle, besides not helping in anyway, possibly even discouraging further development is misguided because ultimately, we're here due to the fact that Microsoft intentionally removed perfectly functional feature. In the old days, these types of programs were used to extend operating system with new functionality that wasn't implemented before, but today, we happen to also need software that restores features that were perfectly functional in previous versions. There is an easy checkbox in Windows 7/Vista for toggling transparency that satisfies the user with either preference. I remember the post where Big Muscle said he considered open sourcing Aero Glass, but decided against it due to other people's behavior. There was a similar story with Classic Shell, started out as closed source, then it was open sourced for a while before being closed again due to other people's behavior. The code was opened in the end when its author decided to stop developing it any further. Perhaps, as @DarkKnight said, changing things in one direction or another would just require more consideration on the licensing. Though in the end, I also agree there's nothing particularly off-putting or nonsensical about the rules already in place. You can never make everyone happy... Edit: Experimental builds can be downloaded only by donators in the first days. He must have downloaded it before it was available for everyone.

I could get it to compile, but toasts aren't replaced. I could definitely use some hints.

I assumed it got messed up somehow. I managed to break things in the past when messing with updates.

KB4467682 was pulled recently due to causing BSOD on certain systems. It happens to be well functional.

I tried Windows 10 1803 on my laptop again a while back for a very short time. I don't know how it used to work at one point with an older build, but once again, I encountered an issue when wired and wireless adapter are bridged, wireless adapter drops connection shortly after the another computer is connected to laptop's wired adapter. No such issue on Windows 8.1. I don't know what the issue is in OP's case, but when you have bugs in Windows' own networking stack, no driver update for the network adapter will be able to tackle the issue.

If you are going to write a three word sentance for something most of us think is s**** then please have the decency to explain "why" I think it mostly serves to consume CPU cycles and network bandwidth. For serious crashing bugs, Windows Error Reporting has been a thing for many years. For the rest, there are concepts such as users providing feedback (where for certain things MS conveniently ignores it if it doesn't align with their vision) and testing done by professional quality assurance team. No telemetry can replace these things.