@Alfonico I haven't had time to troubleshoot your WindowsUpdate.log yet for reasons explained in my next post
A report on the current state of the script 2.5.3 and 1809: I was mistaken previously when I said that I can remove permissions and lock system update hijacker files in 1809. v2.5.3 just renames them (and the uninstaller renames them back to the original file names and restores the owner back to TrustedInstaller), which is fine, but running sfc will "repair" (restore) them. v2.5.3 still fully locks all update hijacker system files in versions before 1809. I'm working on a method to regain control of removing all permissions to fully lock the files again. If anyone already knows how to fully remove all permissions to lock system files with 1809 (from the command prompt) it would save me a lot of experimentation time. I'm in the very early stages of testing, and looking at using nsudo and other methods to remove all permissions and lock the files again. I repeat, the script v2.5.3 is working fine in 1809, it's just not handling the update hijacker files in a manner that I think is ideal. Taking ownership and renaming the files is just a workaround for now. Stay tuned, an update is coming...
The AppCompat thing is just for applications not aware of Windows 10. As they also might not be aware of the "10" being two characters, and the build being 5 now, Windows reports and simulates a Windows 8 environment. Updating the application with a manifest saying "Yes, I know Windows 10 exists and can handle it" will restore reporting the true version. Oh, by the way, the biggest idiotic move is to not offer CUs to Windows 10 with AllowTelemetry set to 0. System tells you you're up to date, while you are not. So, that's a lie much worse as the other one.
that's true, but what methods are these? to trick the customer, lying to the user, "cache a lot" of shims in his explorer process, fail to communicate benefits rather than destroying his devices and tell him go forward..?!#.. i already brought a new usb ssd stick, for win to go perfect, and have my preferred "linux" burned in case this peace of s**t continues... i found the installers of my backup software and vbox installer in a hidden folder in system32.. winblows is much interested in.. wait - wasn't it a bug?
Do you mean the C:\Windows\Intstaller directory? That's the normal MSI cache for the packages. Otherwise, you'd need to provide the MSI file for every reconfiguration.
I found a fix for locking system files again. NSudo can't stop command prompts from flashing (it's on the to-do list), so I'll be using PowerRun which does hide command prompts. Using either one adds about 5 seconds to the script load time because I have to run 9 separate commands with it, but whatever works. I'll switch to NSudo when it's fixed.
I think PowerRun is a great tool, it will save me when the time comes , nice find As for the release if the to do list wont take long i think you should wait, but if it will take sometime you can release it now Nice Work!
what packages windows stores there is not that normal.. by the way, the windows 10 911 2018 update was the one to bring you the last step to force you to upgrade to the next major build. but preparation was done for month. esperially drivers where superseded unnoticed. a new driver model there should be with windows 10 1809.. i noticed on every windows maschine where i took detailed look for replaced drivers by microsoft ones, there were on every machine so far - until you notice what you not have noticed for month and you install WHQL vendor drivers. even two customers i know with build 1803.81 and WUMT got tricked very well... last friday i scripted some things on one of the devices to (hopefully) win some time... yet one thing... have you noticed the windows taskscheduler cmd.exe entry "explorer.exe / create_unelevated_task/skipuac" and.. when it showed up for first time??? i bet this one key-thing to stop this nice force trick. my bricked usb-flashdrive... hundrets of gigabyte userdata deleted from pcs of some individuals is 100% intentionally (arranged by microsoft). with new cleaning drives function enabled by default there clearly is no surprise.
Okay, I'll go ahead and release this tomorrow. It is an important update after all. Then I can work on the rest of the to-do list later.
Hello Don't waste time on my stuff. I "just" had to wait.... 3.5 hours!!! and the Windows Defender update (a few KB) got installed... So there is in fact no problem, I just need to let WUMT run the time it needs to update, even if it is ridiculously long. I suspect that the cause is my very slow Internet, although I don't know why. Have a nice day!
Hello Not urgent, whenever you have time. Hided updates: anomalies. When hiding an update, there is an error message shown by WUMT and the updates selected for hiding are not moved to "Hided". But when launching again the whole script, the hided updates don't show any more after the update, and the hided number of updates has increased by the number of updates that I tried to hided. Therefore the hiding process does work, despite the error message. But when trying to show the hided updates, WUMT indicates that is impossible because the WU service is off (which is normal). Then how do I show the hided updates in case I want to install them ? In case it can be of use for other users that have a similar problem, solution that I tried and worked: I ran the script enabling WU (with the E option): I closed the script window to keep WU on. I launched the WUMT using wumt_x86.exe (the one that is in the script folder). I launched the update process (which as usual took long) I was then able to show the hidden updates. I ran the script again to disable WU. Summary: If I am not mistaken, there are some anomalies affecting WUMT if WU is off. Regards
That's an amazingly long wait. What is your internet speed? Even though I enable the Windows Update service before WUMT runs, it can stop running again after some time even though it's still set to "Automatic (Triggered Start)", since while using the script there's nothing to trigger it to keep running. WUMT doesn't like it when WU stops running and that's what I believe is happening to you. Also, WU has to be running for WUMT to hide updates. You can work around it for now by leaving "services.msc" open, and before hiding updates "start" the Windows Update service (it'll be enabled and set to Automatic but not running). And I don't see what the difference could be in [E}nabling WU, closing the window, and manually running WUMT; and just running the script normally. It should behave the same either way. I've never tested the script with horribly slow internet speeds before but I will now, and I know a way to keep WU running until WUMT is closed, which would would fix your problem. I'll try to get that fix into 2.5.4 that I'm releasing today. Thanks for your report. Edit: 2.5.4 will trigger WU six times a minute to keep it running until WUMT is closed.
Many thanks for your message. I think that you nailed the problem. All my symptoms point to WU being off. "horribly slow Internet" does indeed apply in my case (typically 30 KB/s !!!!) I will try 2.5.4 as soon as it is released. Many thanks again.