UCyborg

I'm experiencing the strange issue with the latest debug version. When I login and dwm.exe has been running from when the previous session was closed due to initiating hybrid shutdown, the transparency on the top frame doesn't work. Oddly, it works on other sides (left, right and bottom). Also when this happens, when I log off, the second screen doesn't black out, the last frame of the desktop stays on it until the user is completely logged off. I guess this is when that instance of dwm.exe terminates.

Open firefox.exe with Resource Hacker: Copy-paste the entire content minus the highlighted line.

I think so. I haven't actually got around trying whether this registry setting still works (it's Windows 10, so you never know). I'll try it later today and edit this post to let you know. Edit: It works! If it doesn't work right away, log off and back on.

Try this.

ReactOS is an interesting project, but it would need a serious backing for it to move anywhere at a faster pace. Its devs also have to be careful to not violate Microsoft's license terms when implementing functionality. See this. ReactOS CONTRIBUTING.md file in the source code repo: Legal notice: If you have seen Microsoft Windows source code, your contribution won't be accepted because of potential copyright violation. Before contributing, you must affirm that the following is true: I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.

What do you people make of this? Didn't think anyone would actually bother to comment, but the author of Rufus himself did. Is anyone here who uses Vista on a regular basis actually concerned of the potential security implications? At least for me, regardless of the OS I use, whether that mitigation is enabled or not, it doesn't make a difference to me, because nothing ever gets on my PC without my explicit permission. I haven't used anti-virus software in years. To me, that's snake oil that only serves to give gullible people a false sense of security and slow the computer down and being downright annoying by deleting software that I actually want to run. It even happened to me once that I was compiling a program from source and NOD32 deleted the freshly compiled .exe right away! I was compiling a freaking game engine at the time... Windows Defender is the very first thing that gets turned off after Windows install. So, since this is primarily for the few Vista fans on this forum and that I don't really like programming and only ever bother with it if something I'd like to use is horribly broken or otherwise find some inconvenience that I'm able to fix, what do you think? Would you rather have a version that's potentially more secure or is the current fine? Honestly, my Vista image dates back to 2013, so it's possible that the bug with controls losing Aero appearance doesn't even occur when on a later patch level, but knowing MS, when their product goes out of mainstream support, they don't usually do any interesting updates. I guess I could compile both versions. I personally prefer the one that looks right.

How far along it is? Very alpha, like it's always been since its early roots dating back to the nineties trying to mimick Windows 95.

I don't see Firefox 66 behaving any differently from the older versions. I'd just use modified firefox.exe with Windows 10 manifest patched out unless someone comes up with CSS hack that actually works properly.

I still get this crash with latest debug version of AG on Win10 1809. Doesn't happen when Aero Glass is not loaded. It's possible I've terminated aerohost.exe last time without also terminating dwm.exe, so DWMGlass.dll was still loaded, hence coming to conclusion that it happens regardless of AG. I get these results both in VMware and on a real PC. Crash dumps are not generated in this scenario. I don't see it crashing on 1803 virtual machine though...maybe I used the wrong snapshot when testing the last time.

I miss the x86 flavor. What's the actual reason for dropping x86 support? Just that everyone else does it? Last time I checked, x64 assembly was more complicated than x86.

Have you tried this? http://glass8.eu/out/rs5_17763_1564_x64dbg.7z It's a debug version, but supposedly fixes some crashing problems that were reported. The latest non-debug version also crashes for me occasionally, though I decided I'll just wait for the new non-debug version.

I noticed in version 1809 that they started using NDIS 6.x drivers by default (for portable devices with USB tethering feature), so no need to manually update them anymore to avoid connection stability issues due to bad backwards compatibility with NDIS 5.x specification. Also the old Windows 8 bug with DirectDraw and DWM_DX_FULLSCREEN_TRANSITION_EVENT that caused 3 second delay on transitions from/to fullscreen mode when the app's screen settings (resolution, refresh rate) matched the desktop's is gone. Didn't think this one would ever be addressed.

I've recently come across a very nasty bug in Windows 8.1, specifically in its NDIS kernel driver (ndis.sys). Basically, when using network adapters in bridged mode and copying files from a file share, non-paged pool usage keeps rising with more files copied (Task Manager->Performance tab->Memory). Reboot is the only way to reclaim that memory. I haven't seen anyone posting about this particular problem, the only known issue with similar symptoms occurs with outdated Ethernet Killer drivers. I did find this: https://answers.microsoft.com/en-us/windows/forum/all/windows-10-memory-leak/4bbdd7a6-d6e1-46ab-8ea1-c2ee60361088 And this: https://support.microsoft.com/en-us/help/4025339/windows-10-update-kb4025339 (Addressed issue with memory leaks in the nonpaged pool with the "NDnd" tag, which causes the OS to crash.) Windows Performance Toolkit confirmed that the leaks happen in ndis.sys and that the allocations have "NDnd" tag. The network adapter drivers can be ruled out since the only requirement is that the network adapters are part of the network bridge and the behavior can be consistently reproduced with different network adapters. While I can't say with 100% certainty, it's likely the Windows 10 update article I linked speaks of the resolution of the same bug. It must have appeared in Windows 8.1 and was only later fixed in Windows 10. Latest cumulative update for Windows 8.1 does not address it.

Windows 10: How to burn CDs and DVDs And if you install OpenShell, you get a replacement start menu, which presents "This PC" option right after you open it (well, actually, the very first time you try to open it, its Settings window opens). But still, the fastest way to open File Explorer is using the yellow folder icon in the taskbar (assuming it wasn't removed for any reason). Traditionally, File Explorer used to be called just Explorer in the old days. Then at one point it was renamed to File Explorer. The confusion stems from the fact that the most common way to open it is not through the shortcut that just points to the File Explorer program, but through the special shortcut (that's my own term for simplicity sake), that opens the specific location in the File Explorer. This special shortcut had different names throughout history, such as "My Computer", "Computer" and "This PC". But it always pointed to the same location where you can access all storage media connected to the computer. The only difference besides the name, they added some commonly used folders in newer Windows versions in the same place where you see all storage media. BTW, I don't know how good it is, but there's this book called Windows 10 for Dummies. Perhaps it has some useful answers.

Rufus can still be made to run on Vista without much effort. I've put the binary on GitHub.

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?