SCHED_S_TASK_NO_MORE_RUNS (0x00041304) — Fixed
This error means Windows Task Scheduler won't run the task again — it's expired. The fix is to update the task's trigger to run indefinitely.
Yeah, getting the 0x00041304 error is annoying — especially when a task you depend on just silently stops running. The culprit here is almost always the task's trigger expiration. Windows Task Scheduler won't run a task if its end date has passed, and it throws this error when you try to run it manually. Here's the fix.
The Fastest Fix: Update the Trigger
- Open Task Scheduler (hit Win, type "Task Scheduler", press Enter).
- Find your broken task in the left pane — it's usually under Task Scheduler Library.
- Right-click the task, select Properties.
- Go to the Triggers tab. You'll see the expired trigger listed with a status like "Disabled" or "Expired".
- Double-click that trigger. Under Advanced settings, uncheck Expire or set the end date far in the future — like 5 years from now.
- Hit OK on both windows. Then right-click the task and select Run — it should fire immediately.
If the task still won't run, delete the trigger entirely and create a new one from scratch. That clears any hidden corruption in the trigger XML.
Why This Happens
Windows Task Scheduler is strict about end dates. Even if you set the trigger to repeat every hour for a year, once the end date passes, the scheduler treats the task as done. The 0x00041304 code literally means "no more runs scheduled." It's a common gotcha — you set up a task, forgot to set it to never expire, and a year later it's dead.
Another scenario: you migrated a task from an older server (like Windows Server 2008 or 2012) to a newer one (2016/2019/2022). The old task might have had a hardcoded end date from years ago that came along for the ride.
Less Common Variations
Trigger was disabled manually
Sometimes someone disabled the trigger by accident. Check the trigger's Enabled checkbox. If it's unchecked, re-enable it. This is rarer but I've seen it after a group policy update that disabled certain triggers.
Task uses 'Run whether user is logged on or not' and credential issue
If the trigger looks fine but the task still fails with 0x00041304, check the task's credentials. Password changes on the service account can cause the scheduler to silently kill the task. It'll show as available but won't run. Re-enter the password in the task's General tab under User account.
Corrupt task XML
I've seen this twice in 14 years — the task's XML gets mangled, usually from a bad export-import cycle. The trigger XML shows an end date that's already passed, but the UI won't let you edit it properly. Fix: export the task, delete it, then re-import the XML after manually editing the <EndBoundary> element to a future date. Here's how the XML snippet looks:
<Triggers>
<CalendarTrigger>
<StartBoundary>2024-01-01T08:00:00</StartBoundary>
<EndBoundary>2024-12-31T23:59:00</EndBoundary> <!-- Change this date -->
<Enabled>true</Enabled>
...
</CalendarTrigger>
</Triggers>
Change EndBoundary to something like 2030-01-01T00:00:00 or remove the line entirely. Save the XML, then import it back.
Prevention
Stop setting end dates unless you have a specific reason. For recurring tasks — daily backups, maintenance scripts, cleanups — always uncheck the Expire box. If you do need an end date, put a calendar reminder to extend it before it expires.
Also, document your tasks in a spreadsheet or wiki. Include fields for trigger type, start/end dates, and the service account. It takes 10 minutes and saves you from hunting down forgotten tasks later.
One more thing: if you're managing multiple machines, use PowerShell to audit all tasks for upcoming expirations. Run this on a schedule:
Get-ScheduledTask | Where-Object {$_.Triggers.EndBoundary -ne $null -and $_.Triggers.EndBoundary -lt (Get-Date).AddDays(30)} | Select-Object TaskName, @{N='Expires';E={$_.Triggers.EndBoundary}}
That spits out every task expiring within 30 days. Fix them before they break.
Was this solution helpful?