@pf100, here's a minor issue that sometimes happens both with the Start Menu installed version and the manual execution in the portable folder: (Manually running the script produces a similar message that references a path on my desktop where I keep the folder with the script files.) I say that it's a minor issue because when it happens, running it a second time gives no error. It's happened on several computers. Incidentally, it appears to me that you can have the Start Menu version installed, and still run the script manually. You can also run the Uninstaller_undo-all-script-changes.cmd and then the script from the Start Menu -- all seems to work okay by doing that. Why would I? I've got WuMgr tailored for manual, and WUMT is hard coded into the Start Menu version, so that's one way to compare the actions of both programs.
Excellent idea. Your proposed changes will be in the next version. Thank you for this info. The problem is one of timing. What i mean by that is that batch script by design is supposed to execute one line of code, then the next and so on. But in the real world it doesn't work like that. As the script grows in complexity I have to introduce timeouts between certain commands to allow the previous command to completely execute or the next one will fail. Long story short, I'll figure out where the problem is and fix it. In the meantime, putting the script in the root of the drive ("X:\WUMT Wrapper Script") is a workaround.
As previously suggested, I've decided to go ahead and give users the choice between WUMT or WuMgr in a menu, so you won't have to edit the script anymore to use WuMgr. I'll include WUMT and WuMgr with the script download.
If this helps, I'm not positive, but I think the error happens right after "Creating tasks" is displayed. I just ran the script on six machines to test out WuMgr v0.9b, and did not duplicate the timing error on any of them, so I wasn't able to observe exactly when. Edit: Oh, I guess that is already expressed in the contents of the error message, ref: wub_task.
I can't re-create the error no matter what folder I put the script in, so if you could try this to troubleshoot it would be a big help: Open WumtWrapperScript.cmd in notepad, and in the Create WDU task, and wub_task section where it says Code: :::::::::::::::::::::::::::: ::Create WDU task, and wub_task call :createwdu call :createwub_task :::::::::::::::::::::::::::: Edit it to be like this instead and tell me if it fixes it Code: :::::::::::::::::::::::::::: ::Create WDU task, and wub_task call :createwdu timeout /t 2 >nul 2>&1 call :createwub_task :::::::::::::::::::::::::::: If that doesn't work, then try this instead Code: :::::::::::::::::::::::::::: ::Create WDU task, and wub_task call :createwdu call :createwub_task timeout /t 2 >nul 2>&1 :::::::::::::::::::::::::::: If neither of those options fixes it we can try something else.
Unfortunately, I've tried to intentionally reproduce the error on several machines and haven't been successful either. So I tested with your timeout line in each of the script places and it worked fine. But it worked fine without the timeouts. So basically, without trouble, troubleshooting is futile. I suspect it might have something to do with caching of the code. But even when I use my most plain vanilla computer with a standard HDD, uninstall 2.5.4, install and run 2.5.2, reboot, uninstall 2.5.2 (without running it) using uninstaller_undo-all-script-changes, then run the 2.5.4 script (without the timeout edits), I can't get the error. So no help, sorry.
That made me laugh out loud. Thanks for the effort. I always do my final tests on an old acer netbook with a 1.1ghz celeron 847 cpu and 8gb ram running 1809 pro (I triple boot Kali and Mint) that hasn't had a clean install since over 2 years ago, only upgraded with each new release. I can wipe and reinstall linux easily because I use the windows bootloader with easybcd pointing to grub on the partition with mint. No UEFI or GPT needed on this thing with creative use of extended partitions on a 320mb 5400 rpm hard drive. Man, that thing is slow. I use it mainly to watch movies streamed from the net connected to a big monitor. I've always used only the wrapper script on it. I figure if I'm going to have an issue with the script it'll show up on that netbook. But I do my initial testing for each new release on a VM on a fast machine because if I break that, no big deal. No idea why I just said all that, I guess just so you know how I test the script before I release it. On all my other machines besides the netbook I run LTSB 1607, and I use the wrapper script on all those too. I know, the script isn't really necessary on LTSB, but I make the script for myself first, and I use it on everything I own all the time because it works on any version, LTSC included since it's just 1809. If everyone decided to never use the wrapper script again, I'd still be using it because I made it for me. I believe in it that much. I don't know why I said that either.
"...The problem is one of timing. What i mean by that is that batch script by design is supposed to execute one line of code, then the next and so on. But in the real world it doesn't work like that. As the script grows in complexity I have to introduce timeouts between certain commands to allow the previous command to completely execute or the next one will fail." This may be 'old news' but... I've had similar problems and the cause was PowerRun. Unlike NSudo, PowerRun does NOT have a '-Wait' option (although it has been request buy several users on the user forum). PowerRun starts the target command but does not wait for it to complete so subsequent calls are stepping all over each other. Easy to verify by placing delays (say, 3-5 seconds) after each PowerRun call and comparing results with & without delays. Hope this helps.
That explains one other problem I've never mentioned anywhere on the board, only in private conversation. If I try to remove permissions from over 10 system files using powerrun, and so far I don't have to do over 10, but in my tests the 11th one doesn't get its permissions removed. But holy hell, if I add a 3 to 5 second timeout between each operation it would make the script painfully slow to load even with checking if the file exists first with "if exist" command before the operation to reduce the number of operations required. Using powerrun has really slowed the load time of the script even without delays. I wasn't aware of this issue with powerrun and it explains a head-scratching issue I was having with it. It's not a problem now with the script currently as far as I know, but your info helped a lot. I already have to use a 2 second timeout every time I run wub.exe in the script because it doesn't wait either. Thanks.
Glad this helped. The real solution is probably NSudo with the "--Wait" option. In the meantime, have you considered PsEexec? It runs with "system" level integrity and has worked for me as a suitable alternative to PowerRun. Specifically, this is form of what I'm using in my cmd scripts: 2>nul %PsExec% -d -h -s -nobanner -accepteula %ComSpec% /C "<command(s)>"
I was looking for the biggest hammer: TrustedInstaller. That's why I never tried PsExec since it executes commands as System. So unless I missed something it's basically just between powerrun and nsudo if my goal is TI. Just tried the latest nsudoc. Hides command prompts without making the cursor flash a wait cursor for a split second like powerrun does. Works better than I expected. I'm dumping powerrun.
I appreciate your sharing. And your need of the wrapper script for yourself is a boon for the rest of us. For some of my machines unable to upgrade past 1709, I installed earlier versions of the wrapper script, 2.4.2, 2.4.4, etc. Set and forget. Plus, I've been vascilating between Start Menu installations and portable execution, just to incorporate WuMgr. Then, this last Tuesday, I RDPd into each setup to make the 2.5.4 version consistent across the board. That's when I noticed the error at least three times. Sounds like the PowerRun issue @fracer2 mentioned could be involved. Another place I'm using your script is several WinToUSB installations of Win 10 Pro on some USB 3.0 portable HDDs and one Extreme SanDisk USB 3.0 flash drive. They all work great, but they break if updated higher than 1607. Your wrapper script is perfect to keep the Windows 10 version frozen. (BTW, Win 10 installed on an Extreme SanDisk flash drive is the answer for a bootable EasyBCD tool. Invaluable when you need it to point to the right place.)
Using [CODE=RICH][/CODE] you can enrich the text adding some colors even write bold letters although they look slightly bold, not much. Code: BOLD LETTERS non-bold letters BOLD COLORED LETTERS non-bold letters
I changed the code tag to code=rich and used bold red and it's still doesn't stand out like it does in a normal post. Oh well. Thanks for the effort.
I noticed you are planning on using NSudoC.exe in your script. Good luck. I will follow your lead. However, I suggest you confirm that the NSudo target commands are being correctly executed. I have had difficulties using NSudo inside a cmd script. My testing indicates that NSudoC silently fails. Apparently, NSucdC.exe suppresses the error messages. (I'm currently testing on 1703 and 1709 VMs.) As an experiment, you might want to switch to NSudo.exe to display any NSudo error messages.
Thanks for getting back with me. I already tested NSudoC with it and it's working. As I mentioned previously, I remove permissions from system files with icacls.exe as TrustedInstaller with it. The list of files are EOSNotify.exe, WaaSMedic.exe, WaasMedicSvc.dll, WaaSMedicPS.dll, WaaSAssessment.dll, UsoClient.exe, SIHClient.exe, MusNotificationUx.exe, MusNotification.exe, and osrss.dll. After restoring default permissions by using the script's uninstaller, then running the script using nsudo instead of powerrun, all permissions are removed from all files as expected. They can't be read, written, or overwritten by the system permanently until the uninstaller is run to restore default permissions. The command I use for each file, where %s32% is %systemroot%\system32 and %%# is each file in the list mentioned above, is (NSudoC.exe shown below is actually a variable in the script to run the correct version for the system architecture): Code: if exist "%s32%\%%#" NSudoC.exe -ShowWindowMode:Hide -Wait -U:T -P:E "%systemroot%\System32\icacls.exe" "%s32%\%%#" /inheritance:r /remove *S-1-5-32-544 *S-1-5-11 *S-1-5-32-545 *S-1-5-18 >nul 2>&1 This is the full code of that section of the script after renaming the x64 version of NsudoC to NsudoCx64.exe and leaving the x86 version's original filename as NSudoC.exe then using the correct one in the %nsudovar% variable and putting those two files in the script folder: Code: :::::::::::::::::::::::::::: ::Set list (s32list) of update hijacker files to be disabled, then disable everything in the list. wmic cpu get AddressWidth /value|find "32">nul&&set nsudovar=NsudoC.exe||set nsudovar=NSudoCx64.exe 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 CompatTelRunner.exe set s32=%systemroot%\System32 ::If "s32list" files were previously renamed by script, restore original file names for %%# in (%s32list%) do ( ren "%s32%\%%#"-backup "%%#" >nul 2>&1 if exist "%s32%\%%#" del "%s32%\%%#"-backup /f /q >nul 2>&1 ) timeout /t 2 >nul 2>&1 ::Lock files for %%# in (%s32list%) do ( takeown /f "%s32%\%%#" /a >nul 2>&1 icacls "%s32%\%%#" /reset >nul 2>&1 if exist "%s32%\%%#" %nsudovar% -ShowWindowMode:Hide -Wait -U:T -P:E "%systemroot%\System32\icacls.exe" "%s32%\%%#" /inheritance:r /remove *S-1-5-32-544 *S-1-5-11 *S-1-5-32-545 *S-1-5-18 >nul 2>&1 ) timeout /t 2 >nul 2>&1 ::If files in "s32list" aren't locked for whatever reason, rename them. for %%# in (%s32list%) do ( ren "%s32%\%%#" "%%#"-backup >nul 2>&1 if exist "%s32%\%%#"-backup del "%s32%\%%#" /f /q >nul 2>&1 ) ::::::::::::::::::::::::::::