Windows 10: Task Scheduler failing after BST and DST changes

This raised to be current/ongoing as the auto-locking of threads on quiescence, which not much cop when issue only going to recur every 6 months, has locked good original. See https://answers.microsoft.com/en-us/windows/forum/all/task-scheduler-failing-after-bst-and-dst-changes/64a72eed-b2a0-4b2d-bc6d-28aae6385c40 for excellent original thread with description of issues.I also independently raised calls with MS on both DST switch over effect on Task Scheduler and the Powershell commandlets wrt,. TaskInfo returns, with frankly, pretty mixed responses thereto.Have just had Recurr

:)

 

Task Scheduler failing after BST and DST changes

We have hit an bug in Task Scheduler that seems to have surfaced between March 2021 and October 2021, The trigger for the issue is Daylight saving changes for the UK (I guess Europe and may be other parts of the world) and also there is some affect from the US DST change. I am seeing this on Server 2016 and 2019 versions of Windows so would expect Windows 10 to similarly affected.

Symptoms
After BST either starts or stops and clocks change a number of scheduled task fail to run. This appears to be limited to those using a weekly or monthly schedule, daily and other triggers work ok.

Observed status
There is no error on last run

Last run date is prior to BST change
Next run date is scheduled correctly,

there is no error in the eventlogs it just doesn't even start.

The US always change a week before the UK/Europe in the Spring and week after the Autumn (Fall), last October all the failing tasks which were exhibiting strange behaviour like when they did run it was 1 hour later than expected started work correctly after teh US DST change.
This spring they all just failed after the BST chnage in the UK.

Fixing by export, delete, reimport fixes the issue until the next DST event.
Changing the start time of the trigger to today also fixes the issue
Manually creating the task fixes the issue
However when you are looking at tasks across hundreds of servers it is not a trivial thing to verify. It may also be affect any of teh hundreds of MS tasks on a device but it is impossible to work out.

After digging through servers that have the same task but created a different times from an XML file and where some would work and some would not.
Our conclusion is there is an issue with the trigger start date in relation to the creation date and where these fall in the cycle of DST changes, of which there are 4 zones, due to the US and UK changing a week apart. (UTC/UTC, DST/UTC, DST/BST, DST/UTC). It occurs when the task scheduler is creating the next run date and the calculation it makes based on the start date when the task is created which i guess is quite complex. SOmething gets broken in the calculation as we flip between UTC and BST.

If the trigger start date and creation date are done a different times and these fall in to different scenarios

Another observed issue which may be related is how different things see dates. If you use Schtasks to get info on task the dates are all shown correctly, however in PowerShell the date for the last runtime is not reported correctly as below, these are for the same task, PowerShell is reporting the last runtime as 1954. PowerShell only gets a small amount of info and there is no verbose option so I cannot see if it is seeing the trigger start date incorrectly as well, i assume these dates and times are stored in unversal format and get converted on the fly by the program displaying the information.

PowerShell

LastRunTime : 12/08/1954 05:30:30
NextRunTime : 10/04/2022 18:00:00

schtasks

Next Run Time: 10/04/2022 18:00:00
Last Run Time: 20/03/2022 18:00:01

Has anyone else come accross this? You may not have noticed if you have one report not working and just recreated the task for it, but if you had a weekly scheduled task fail after 2am 27th March you may have been impacted by this and may again in October.

Unfortunately I don't have the facilites to test scenarios and trigger DST events, but my best guess that the most likely workaround is going to be making the trigger start date the same as the when you created the task untill the issue is resolved by Microsoft.

 

Task Scheduler failing after BST and DST changes

Thank you for responding, its nice to know we are not the only ones.
To confirm for me,
Server reboots did not fix this.
Syncronise across time zones also had no effect, as some of the tasks already had that ticked and failed.

Only Recreating the task (export, delete, Import) or changing the start date fixed the issue, still unsure if these are permenant fixes or just till the nest DST/BST event.

 

Task Scheduler failing after BST and DST changes

I thought I'd chip in with some of our findings having had a number of scheduled tasks fail on our network due to Task Scheduler not kicking in. We have found the following:

• Scheduled tasks on Windows Server 2012 and 2012 R2 are unaffected
  
• Windows Server 2016 and 2019 are affected but only tasks that are Weekly or Monthly (or with multiple triggers that contain either)
  
• Symptoms similar to those described. Tasks do not start; no messages, no log entries, they just proceed to the next scheduled event.
  

We have a call logged with Microsoft for advice on a permanent resolution to this however the following may work (albeit until the next DST event)

• Open each failing event and alter the change the 'from' start date
  
• Alter the time (even by one minute) let it run and revert
  
• Each of the above may just be just a case of resetting the task and re-presenting it to the system.
  
• A reboot of the servers (gleaned from the internet - not tried in our case). However this would happen as a result of monthly patching.
  
• Another suggestion for a permanent resolution is to tick the box to 'Synchronise across time zones' on setting the trigger time. This may have some validity as the system log entry for the DST shift states it is shifting time zones.
  
  The system time has changed to ‎2022‎-‎03‎-‎27T01:00:11.415086900Z from ‎2022‎-‎03‎-‎27T01:00:11.415086900Z.
  Change Reason: System time adjusted to the new time zone.
  
  (This is how it was displayed in the log file: yes, the old and new times showed as the same although the actual log was timed at 02:00:11)
  
  We can't afford the time to test the time zone solution so it may either have to wait until October or until Microsoft responds with a definitive answer. I will post the official response on here when it comes back.