New
#261
Thanks, Gary! I've been preoccupied elsewhere lately. Thanks for stepping in and troubleshooting the script issues.
--Ed--
Stop Windows 10 Updates Properly and Completely
-
-
New #262
Despite being subbed to this thread I only saw your reply yesterday Mathew. Yes I ran that later version and it is working well thanks. I was offered an update yesterday called "feature update to Windows 10 version 1803" which is 19.67 GB. Why so large and do you think that I should run it please? I Googled it with no conclusive results. Also in regard to the posts later in this thread with links to Major Geeks WUMT Wrapper script I am confused as to how this ties in with your suite of scripts etc. Sorry that I am not all across this but I prefer to ask and try and get a fuller understanding rather than do the wrong thing. Thanks again for all your help in regard to this :)
-
New #263
Who better to solve the problem that I caused
? And I'm going to turn this bad situation into a good one by including a recovery script with future versions. upfc.exe is a deeply rooted protected process update facilitator that I concerned myself with for no gain. It seems to be new as of 1803 and only runs when the version of Windows 10 is over 6 months old to force an update. When it can't run, it causes a GSOD. It can't defeat the script so there's no point in trying to control it.
-
New #264
You are now running version 1703 (as per your screenshot). You may update it to 1803 if you want a newer version. A feature update denotes a different version of Windows. Your screenshot shows "90.67 GB", which I consider a wrong number. Your screenshot also shows "KB4023057", probably an update hijacker, which should be hidden (rejected) if you don't want to be hijacked.
The core of my scripts was copied from Major Geeks WUMT Wrapper script. That is the tie.
Have you read the first sentence in "# Readme.txt" in my zipped file?
Your thanks should be given to the original author, pf100.
-
New #265
Thanks once again for the explanation Matthew and a big thanks to pf100 for the WUMT Wrapper script and subsequent support.
-
New #266
That's how big the update is in its entirety to update every possible version of Windows 10 to 1803. It only downloads the parts you need, so you'll only download 1 to 3 GB. That is, if you want 1803. If you don't, hide it.
You know what? I just download them all and don't worry about it anymore. The script covers everything (so far).
The only thing I concern myself with is if updates are causing a problem overall. I always check Woody's
MS-DEFCON System before I do updates. If it's any lower than defcon 3 I wait...
Thanks for believing in the script. I have a recovery script almost done to be included with the wrapper script starting with the next version. This is the first time ever for a version of the script (2.5.6) to cause a Green Screen of Death. From now on there'll be a simple recovery plan in place.
-
New #267
-
New #268
After an update, the hijackers locked by Wrapper Script may be unlocked. So, why is there no need to run the script again? Is it because a file locked by NSudo 6.1 can never be unlocked by an update? Is that what you mean by "works better" below?
You know what? Pedro147 is using my script, which has NOT been updated according to your updated version of Wrapper Script.
-
-
New #269
Nsudo works better than powerrun for two reasons:
1) Nsudo has a "wait" switch that lets each command complete. Powerrun requires a timeout between each command because it doesn't complete in time for the next command. Powerrun is just sloppy like that if you run 10 or 12 commands with it as fast as you can.
2) Powerrun briefly flashes a "wait" cursor every time it runs a command where it hides the command prompt. 10 to 12 rapidly flashing mouse cursors is just not cool. Nsudo doesn't have that problem.
The latest v2.5.5 is way better than any previous versions because it creates (if it doesn't exist) and removes permissions from the folders "%systemroot%\UpdateAssistant", "%systemroot%\UpdateAssistantV2", and "%ProgramFiles%\rempl". That way, if a new update tries to install Windows Update Assistant, it's impossible. That's why you don't need to run the script anymore after an update. And an update already can't unlock a locked update hijacker system file. So with 2.5.5 the system is completely locked down.
-
New #270
Download Recovery Script for 2.5.6 here.
SHA1: 293b634cd65fda46b6f9b4449c742443f01b3b11
I have the recovery script working. It works to recover 2.5.6 but works with any version of the script (up to now). Scripting in the Recovery Environment was a lot harder than I thought it would be. I'm putting this here in case a Recovery Environment Scripting God happens to walk by to say, "You should do it like this instead." Here are some things that don't work: some piping and redirection, findstr.exe, choice.exe, reliable error codes to detect locked files only solved by copying one (you can't copy a locked file), and a lot of other stuff I didn't make a note of. But most importantly, it works. Oh, and it doesn't hurt anything if you run it on the wrong drive by mistake.
Also, the recovery script currently looks for valid drives to restore by looking for \windows\system32\usoclient.exe on any valid drives and then reporting any it finds. In the screenshot below it says, "Drive C: looks like a possible candidate" because it's the only drive that had usoclient.exe. For the finished version, starting with the next script I'll probably put a text file in system32 that the recovery script compares its version with the wrapper script version and it'll check to make sure you're using the correct version of the recovery script. That is, if I'm brave enough to code in the RE some more.
To use it you'll just copy the recovery script to a Windows installation flash drive or flash Recovery drive and run it and you're done.
Recovery script screenshots:
Drive detection, hijacker file detection, and drive selection screen.
Succesfully restored default update hijacker file permissions to default.
Recovery script:Code:@echo off Title WUMT/WuMgr wrapper script 2.5.7 recovery (works with 2.5.6) :Start cls set "drive=" set "areyousure=" set "s32=" set "s32list=" echo. & echo (Ctrl-C) to exit script echo.&echo Looking for valid drives... :::::::::::::::::::::::::::::::::: ::Show available drives, free disk space, drive size, and volume label for /f "skip=1 tokens=1-4" %%a in ('WMIC LOGICALDISK GET FreeSpace^,Name^,Size^,VolumeName') do @echo wsh.echo "%%b" ^& " free=" ^& FormatNumber^(cdbl^(%%a^)/1024/1024/1024, 2^)^& " GiB,"^& " size=" ^& FormatNumber^(cdbl^(%%c^)/1024/1024/1024, 2^)^& " GiB," ^& " Volume Label=%%d" > %temp%\tmp.vbs & @if not "%%c"=="" @echo( & @cscript //nologo %temp%\tmp.vbs & del %temp%\tmp.vbs :::::::::::::::::::::::::::::::::: ::Find all drives that contain \Windows\system32\usoclient.exe echo. echo Looking for drives that contain \Windows\system32\usoclient.exe... for /f "skip=1 tokens=1" %%a in ('WMIC LOGICALDISK GET Name^') do (if exist %%a\Windows\System32\usoclient.exe echo ---Drive %%a looks like a possible candidate---) :::::::::::::::::::::::::::::::::: echo. & SET /P drive= Enter only a drive letter without colon (X and not X:) to run wrapper script recovery: echo (Ctrl-C to exit) echo You chose %drive% SET /P areyousure=Is this correct? (Y/[N])? IF /I "%areyousure%" neq "Y" goto start ::check for renamed update hijacker files if exist %drive%:\Windows\System32\usoclient.exe-backup goto continue ) ::check for file permissions copy %drive%:\Windows\System32\usoclient.exe %drive%:\WWStempfile if %errorlevel% neq 1 ( echo. echo If you see "1 file(s) copied." message above, the drive has already echo been repaired or drive %drive% is the wrong drive. echo Try again with the correct drive letter without colon. echo Press any key to try again... pause > nul del %drive%:\WWStempfile goto start ) :: :continue echo restoring default permissions to update hijacker files on %drive%:Windows\System32 ::Restore default permissions to Update Hijacker files disabled by script set s32=%drive%:\Windows\System32 set s32list=EOSNotify.exe WaaSMedic.exe WaasMedicSvc.dll WaaSMedicPS.dll WaaSAssessment.dll UsoClient.exe set s32list=%s32list% SIHClient.exe MusNotificationUx.exe MusNotification.exe osrss.dll upfc.exe ::If "s32list" files were renamed by script, restore original file names for %%# in (%s32list%) do ( if exist "%s32%\%%#"-backup ren "%s32%\%%#"-backup "%%#" if exist "%s32%\%%#" del "%s32%\%%#"-backup /f /q ) ::Now restore default permissions for Update Hijacker files for %%# in (%s32list%) do ( takeown /f "%s32%\%%#" /a icacls "%s32%\%%#" /reset icacls "%s32%\%%#" /setowner *S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464 ) echo Permissions restoration final check. You should see "1 file(s) copied" on next line: copy %drive%:\Windows\System32\usoclient.exe %drive%:\WWStempfile if %errorlevel% neq 0 echo. & echo Repair failed, try again with the correct drive letter without colon & pause & goto start del %drive%:\WWStempfile echo =========================================================== echo. & echo ---Update Hijacker system file permissions restored to default on drive %drive%--- echo Multiple "ERROR: The system cannot find the file specified" and other similar error messages is normal. echo You should see multiple "SUCCESS: The file (or folder): "filename" now owned by the administrators group" messages. echo You should see multiple "Successfully processed 1 files" messages echo If for some reason this recovery script didn't work, re-run the recovery echo script again and choose another detected drive. echo No harm was done if you picked the wrong drive. echo You may now exit the Recovery Environment and boot windows 10. :::::::::::::::::::::::::::::::::: :ENDLast edited by pf100; 17 Jan 2019 at 04:46.
Quote
Related Discussions
