For many years I was able to use Task Scheduler to run a WinBatch script at a certain time every day, using the Task Scheduler "Action" tab to "Start a Program":
"C:\Program Files (x86)\WinBatch\System\WinBatch_HF.EXE"
with argument specifying the WinBatch script:
"D:\steve\Scripts\WinBatch\Admin\ravenDocumentsBackup.wbt"
The script in turn runs a backup program. In the last few months that no longer works. The script works just fine, the backup is done, if I run it manually from inside WinBatch Studio but from Task Scheduler the backup program is not opened and everything hangs.
I am using Windows 10 Pro x64, all with latest updates. Does anybody have any idea why something that worked flawlessly for many years has now stopped working? The script itself has not been changed.
Thanks, Steve
First, look at the log file history. It likely contains a system error that explains your problem. Second, search for the term "task scheduler" in this forum there are multiple posts related to the topic. One or more of them may be helpful.
I don't know what log file history you are referring to. Windows? WinBatch? Task Scheduler? The backup program?
Task Scheduler history simply says the action was started and task is currently running. I eventually have to kill it.
The backup program that the script runs does not run. It has a log file and there are no entries in it. I also send an email when the script starts and that does not happen. So it seems like WinBatch simply does not start up completely and/or does not start running the script, when run from Task Scheduler. It all works just fine when run manually from WinBatch Studio.
There is nothing obvious in Windows Event Viewer, but I don't know how to use Event Viewer.
Are there other log files?
That the task log indicates that the task started but has nothing else in the log and combined with the fact that the script works when running as a desktop user may be very informative. However, since you have not provided relevant information about how the task is configured or exactly how your script is starting your "backup" program, it is impossible to say much more. But generally, when a script just hangs in the task scheduler it is because it is not written correctly to run as a task scheduler initiated task. This results in it displaying an error message box that no one can see or dismiss because the task is not configured to be able to interact with the desktop.
I'm having a similar issue. I have three WinBatch scripts (compiled) that are executed via the Task Scheduler. The first reboots my system before running a back. This one seems to work fine. The second controls what gets loaded when the system reboots (it runs as login). This one doesn't work. It shows an Op Code of 2 but no errors are indicated in the log. The third reboots the system after the backup and maintenance work completes. Again, it works fine. All three scripts worked perfectly until the last update to Windows 10. All exe files are set to run as administrator and the scripts are set to run at highest level during the compile. Any ideas?
Opcode 2 usually but not always indicates some file cannot be found. The file in question is not necessarily your compiled script but some file or files the script depends on. Your problem likely has nothing to do with WinBatch but something to do with a change to your system. Why not just use DebugTrace to attempt to identify the problem?
Does the debugtrace work in the Task Scheduler? The script runs perfectly if I run it directly (click on the exe file).
Once more thing. If I go into Task Scheduler and do a "run" from there it works perfectly.
Quote from: radioman54 on November 05, 2020, 07:54:40 AM
Does the debugtrace work in the Task Scheduler? The script runs perfectly if I run it directly (click on the exe file).
Yes, DebugTrace works provided the account you are executing the task under has write permissions on the directory you are attempting to dump the trace to.
Quote from: radioman54 on November 05, 2020, 07:57:18 AM
Once more thing. If I go into Task Scheduler and do a "run" from there it works perfectly.
You should take a look at how the task is configured and what assumptions your script makes. You are making some assumption that isn't valid.
I put the DebugTrace in and nothing happened. The script is not even loading. As far as assumptions, I've made none. All the script does is read the WINBATCH.INI file (in the WINDOWS folder), check if it is to start in backup mode or normal mode, then depending on that status it loads various things. If it's backup mode, it loads nothing. If it's normal mode it loads the processes I normally use (mail, tools, etc.). Like I said before, this has worked for years. The last Windows 10 update did something that broke it.
As far as assumptions are concerned you are making them. Every time you type something into a script or make use of a Windows component you are making assumptions.
If your script is not even being started then there is something wrong with how you have setup the scheduled task. Since you haven't provided any detailed information about how the task is configured it is difficult to offer any suggestions. One possible thing to check is the startup path. The opt 2 error is sometimes resolved by supplying the correct startup path in the task configuration. Also, keep in mind that Windows updates - particularly "feature" updates - can reconfigure some Windows settings to Microsoft's preferred configuration. Needless to say, this has been known to cause issues.
Rather than repeating the same information in this forum you might want to take a look at your scheduled task's configuration and perhaps conduct a Web search for instances of other Windows users with a similar problem. If you do figure it out, please let us know. I am sure other forum users would appreciate any knowledge you. gain.
Not saying this is your problem but it is an example of what you can find with a simple Web search.
https://www.kjctech.net/why-my-scheduled-task-completes-with-return-code-2/ (https://www.kjctech.net/why-my-scheduled-task-completes-with-return-code-2/)
Trust me, I did the searches. I found several examples just like the one you provided. I have those settings already and they didn't help. I've tried every thing I've found in my searches and I hoped that someone here had a similar problem and had found a fix.
Re-reading this entire thread, I noticed a few details spread out across different postings that may collectively identity a subtle issue.
Early in the thread, I see where the particular WinBatch executable being used is a 32-bit build.
Additionally, it is stated that the platform is Windows 10 64-bit.
Later, there is mention of the script [being executed by a 32-bit build of WinBatch] accessing "WINBATCH.INI file (in the WINDOWS folder)"
I'm wondering whether or not there is some issue involving file system redirection or protected INI file redirection that is causing the script to access a different INI file than expected, with the result being unexpected behavior.
If there is any question at all as to whether or not a WinBatch executable is being started by the Task Scheduler, I would highly recommend downloading & installing Mark Russinovich's "SysInternals" tools that are available on Microsoft's web site at the following link:
https://docs.microsoft.com/en-us/sysinternals/downloads/sysinternals-suite
In particular, what you want is the ProcMon utility. It uses a filter driver and DLL entry point hooking to allow logging of a "running stream of consciousness" for any process that matches the selection criteria that you configure. The log output shows every Win32 or system API function call that is made, along with a dump of the string & numeric parameter values. ProcMon is an invaluable tool for detecting the presence of a process, the sequence of file system I/O and registry accesses that are performed, along with path & key name/value details.
Ok, compiling x64 has caused another problem. It says it can't create the file because it may be in use or read only. I deleted the file and it still gives the same error.
Based on that error message, have you verified that the target directory exists and the target file does not currently exist such that it is flagged as read-only, has insufficient effective permissions to delete/overwrite it or is actually in use by a process on the system?
Target directory exists and the file is not read only (I deleted it).
I finally managed to get it to compile 64bit. When I rebooted my system the task failed completely. Launch failure on every piece. See attachment.
The attachments are from the Event Viewer.
I don't know why this worked but it did. I deleted the task from the scheduler and recreated it. I rebooted and the task ran at login as it was scheduled to do.
For what it is worth, error 214942557 (hex8007009D) has the text "The segment is already discarded and cannot be locked." It is usually caused by a corrupt file and/or memory corruption. The error is often associated with failed Windows updates but it could be the result of an incomplete update or something else entirely.
Since you have it fixed the above doesn't matter but it is amazing how many problems can be solved with the three-finger-solute.