Windows 10 Pro rel. 2004 Task Scheduler suddenly stopped running batch

Beginning about four days ago, all three of my Windows 10 machines stopped running batch files scheduled in the Task Scheduler. These batch files had been running on schedule for over a year when all three suddenly stopped about the same time. I believe that this is about the time that the September 2020 Preview Cumulative Update installed. Task Scheduler reports that "Access is denied. (0x80070005). I have tried running them directly as batch files and running "c:\windows\system32\cmd.exe" with the arguments "/c c:\bt\filename.bat" and both fail. I do have the starting directory shown as "c:\bt." All quotation marks are just to separate the commands from the rest of my message and do not appear in the boxes. I did an image restore from October 1 and brought my files up to date, and everything worked again until the update reinstalled itself. I could do the same thing again and postpone the updates, but, sooner or later, the update will be forced upon me and I would like to find a solution to this. Besides, it is very time consuming to restore and bring three systems back up to current data.



I've been playing with this now for three days and I'm at a loss. I've run SFC /scannow with no results and I also ran DISM to try to fix the Task Scheduler. I did try to go back to a previous System Restore and that failed. Whereto from here?

I have removed the update with no change and I reinstalled it with no change. It seems that restoring the old version is the only thing that works at this time. I did change one of the batch file tasks to an executable file with no other changes to the task and that ran perfectly. I also created a task that would just open the command prompt and that did not work, so it appears that Task Manager cannot open cmd.exe which would explain the batch file failure.

- - - Updated - - -

I have found a workaround, though not a fix. I went looking through my collection of utility programs and found Elevate64.exe which will elevate a command prompt to a new window at elevated permissions. Since this is an executable file, Task Scheduler will run it. This little utility will also run a program or a batch file in the elevated window, so I made the program to run c:\ut\elevate64.exe and added the arguments -wait4idle -noui c:\bt\update2x.bat. The -wait4idle closes the scheduled task while the utility created task continues to run. The -noui just tells the utility not to issue notifications. It works perfectly, but I would still like to find a fix to the original problem.

Try3 said:

1 Has Windows defender quarantined or deleted anything relevant?

No.

2.1 If, as you say,
I have tried running them directly as batch files and ... and both fail
then the batch file itself is not working properly and you could add a Pause line at the end of it so you can look through to see where it is going wrong.

The batch files work if called from the command prompt or Windows Explorer. They don't work if the batch file is used as the task to be run, nor does cmd.exe work if used as the task to be run with the batch file as the argument.

2.2 Perhaps the batch file calls an external item that is no longer installed / in the expected location?

All external items in the batch files are present and work properly if run outside of Task Manager.

3.1 Have you had any problems with logging in?

No. I tried switching to a local logon instead of the Microsoft logon, but that made no difference.

3.2 If, in a command window, you enter
whoami
do you get the expected response?
[The format of the response is ComputerName\UserName]

Yes.
My last post above details my workaround, but the problem is that it won't run anything except executables.

This doesn't tell me anything, but it might tell you something:



The executable is not in the same directory as the batch file and neither directory is in the default path of the system.

I opens the text file, but it uses Notepad to do so. It works either under both the regular and elevated settings. Again, I see no cmd.exe involvement here.