I never got the WUMT script working. It would run when manually started, but the Task Scheduler tasks would never run. I could not modify the WUMT tasks. So, when I experienced the same results with WUMgr (whose Windows Defender Update task I could modify) and found a solution (see my post #1093 above) I thought it might shed some light on the issue I was having with the WUMT script. From here forward I'm guessing, but, the way I got the WUMgr Defender Update task working was by modifying the task to change the initial trigger from some finite time to login and it started working immediately. So, my thought was that possibly the initial trigger that WUMT creates in it scripts could also be modified to eliminate the "time" based trigger and change it to a login trigger. Don't know how much I've cleared things up. This is not my field of expertise. I just stumbled on a solution that works for me and thought it could be helpful.
"However, CPU bound (CPU hungry) threads also exist from time to time, and do a real number of the less greedy I/O bound threads. These ‘greedy threads’ are at the heart of the scheduling problem mitigated by Process Lasso’s ProBalance." this software, i also used it on an old amd pc ~8 years ago, propably is the reason if you can't get the script working at all. delayed execution of specific tasks is in fact the result of process lasso per definition. i recommend uninstall it!.. ms released new intel microcode updates for windows 10, so "refreshing" windows analytics function just in time makes a lot of sense. rolling it out using their best technics to bypass update blockings is expectable (when "adressing security issues", as they call this expensive development named "spectre")..
@rpo I like your solution to the problem by checking if wuauserv is running or not and will use your method, so thanks for that. I fixed the wub error problem in v2.5.5 by changing the 2 second timeout at line 282 of script v2.5.5 to 3 seconds. It's very odd, that's the only place requiring a 3 second timeout after wub.exe. Everywhere else a 2 second timeout works. Using NSudo to remove permissions slows down the script enough as it is, so using powershell is only an option if there's no other way to do something. Cmd and VB script does everything I need so far and is fast. @Homer712 I examined the working Defender update task that you sent me and will discuss this with some people to see if I can improve the task. I still don't see anything wrong with the WDU task but will let you know if I find out anything.
pf100: just guessing here, but I may just reinstall the script today and see what happens if I just leave it alone (if I remember the start time was set to 5:00 either AM or PM) and wait for that time to come around once. Maybe then it'll start triggering the tasks.
Thought better of it and left everything just as was installed, no changes. You have no idea the damage these "non-nimble" fingers can do. Should have the log file for you sometime tomorrow afternoon.
@Homer712 If the wdu task doesn't start, you will get no log file. You must exorcise your PC. Open it and put a dry toad on the motherboard. @pf100 A possible subroutine to manage the wuauserv service : Code: :wuauserv rem rem Calling sequence to enable wuauserv : rem call :wuauserv e rem Calling sequence to disable wuauserv : rem call :wuauserv d rem if /i "%1"=="e" (set "wub=wub.exe /e" & set "status=True" & set argok=y) if /i "%1"=="d" (set "wub=wub.exe /d /p" & set "status=False" & set argok=y) if not defined argok (echo Bad calling parameter. Press any key do exit...&pause>nul&exit) set "argok=" %wub% set max_retry=10 set /a "i=0" :wuauserv1 if %i%==%max_retry% (echo Operation did not complete within %max_retry% s. Press any key do exit...&pause>nul&exit) set /a "i+=1" WMIC Service WHERE "Name = 'Wuauserv'" GET Started | find /i "%status%" >nul && exit /b || (timeout /t 1 >nul & goto :wuauserv1)
So, seems that the dry toad on the motherboard worked . . . thanks "rpo" Image 1: After script run first time. WDU next run time 12:01:00 AM. Wub_task not yet run. Image 2: After the 12:01:00 AM run. Next run time 6:01:00 AM. Wub_task not yet run. Image 3: After the 6:01:00 AM run. Next run time 12:01:00 PM. Wub_task not yet run. Image 4: After restart. WDU no change, Wub_task ran at restart and shows that time. Image 5: Script run, log created, Wub_task has changed to not yet run. Image 5: WUMT window, shows that Defender definitions are being updated. Image 7: Tasks history. Comments: The WDU task does in fact wait for the first 12:01:00 AM to come around. After that, it triggers every 6 hours. The Wub_task ran upon a restart and is reset to "not yet run" when the script is subsequently run. Also, for some reason, when the script gets to the "pick 1 or 2" window, it takes two presses of the key to bring up either WUMgr or WUMT. This has changed from past runs. Request: For those of us that don't leave our computers on 24/7, can the WDU task 6 hour time be changed to say 2 or 3 hours (the location has changed since I was told to modify line 348). Also, for a first time install, is it possible to have the WDU task triggered at user login (plus say 15 minutes) rather than the 12:01:00 AM time. I'm not smart enough to know if it would have triggered with the laptop shut down after running the script the first time as I left the laptop running overnight for this test. Possibly this is not an issue and it would have run when I started the laptop up the following morning knowing that the first 12:01:00 AM has in fact come and gone.
Thanks for the feedback @Homer712. As soon as I wake up I'll send you a version that should work for you to test. And Wub_task is working as expected. Its only purpose is to prevent an update from forcing the windows update service back on after a reboot. Edit: Actually, both tasks are working as expected. I just didn't anticipate someone turning their computer off a lot. I'll fix that.
Thanks, and yes, everything seems to be functioning just as you envisioned except for those of us that don't leave our computers on 24/7. And this next script doesn't need to have the "log" function, correct?
The one I send you won't do any logging since I know what's going on now. It'll just have the task edited to update every 3 hours, and it'll also update 15 minutes after a logon. In the next release, I'll remove the WDU.cmd 5 minute delay and put the task in its own folder in task scheduler. I originally put the 5 minute delay in case of a missed update after logon, but it turns out to not be necessary. The file I send you won't have the 5 minute delay, so you'll get the improvement now.
@Homer712 and @pf100 What can be done for the wdu task is define the following triggers : - at system start and delaying the scheduling for 10 minutes - at 00:01 - at 06:01 - at 12:01 - at 18:01 I don't beleive that changing the time interval to 2 or 3 hours is usefull. The overhead due to the wdu logfile is absolutely negligible. And the user has the opportunity to start the wdu task on demand.
Yes, I'll do that instead. I just got over being sick for 2 weeks and my brain is slow. Edit: I don't see a need for a logfile anymore. We know the problem isn't a problem with the task itself. It's just a timing issue with frequent shutdowns which will be fixed by running the task at startup. Also, right now with my brain on strike I'm doing stupid stuff like editing the script and instead of %w%"</BootTrigger>" I was pasting xml and leaving the " off the end of the command and doing this which created errors %w%"</BootTrigger> The coffee isn't working. FML.
Things seem to be happening just as you stated. See the attached images. Thank you, and I will let you know about the 6 hour update. Thinking about it again, it does in fact sound like the proper interval so there should be no reason for further tinkering. When I was still working and a Product Line Manager, one of the products being developed was highly software dependent. After about six month of testing/tinkering with the code I had a sign made up that we hung over the Software Engineering Department that read, "There comes a time in the life of every product when you shoot the engineers and start production."