Okay, so lets talk about what's going on in the above script.

As usual, a WinCron script is the main entry point for this job. Neither the WCScript exception handler, nor the VBScript ‘worker’ execute on their own and must be called to run.

On a historical note; once every second, WinCron looks for jobs with a -start trigger. When it finds one, it evaluates the -start condition and runs the script if appropriate.

So after WinCron decides to run our job "Weekly Maintenance", it begins executing the script statements.
When WinCron encounters the function call worker(), WinCron asks VBScript to takeover execution. WinCron then waits for the VBScript function to finish before continuing execution.

Now, there are 3 interesting lines in this job.
1. -action -onerror my_exception_handler
2. WCCtrl.Raise()
3. -action -return stop

The “-action -onerror my_exception_handler” is found in the body of the "Weekly Maintenance" job and tells WinCron what to do in case there is an error or exception. In this case WinCron is instructed to run the exception handler script my_exception_handler.
(Currently only WCScript procedures may be exception handlers.)

Next we notice WCCtrl.Raise(). WCCtrl.Raise() will “raise an exception” that can be seen by WinCron.
Keep in mind; things that are happening within the VBScript interpreter are not visible to WinCron by default. If WinCron is to know about an exception, we need to manually raise an exception with WCCtrl.Raise().

And finally we see “-action -return stop” . This directive is found in our exception handler and instructs WinCron how to proceed. In this instance, we are telling WinCron to “stop”.