Task Scheduler Error 0X00041301: Task Won't Stop Running

1. The task's process is stuck in memory (most common)

This is the one I see 9 times out of 10. The task started fine, but something inside it — a script, an executable, a PowerShell command — didn't exit cleanly. Windows still thinks that process belongs to the task, so it blocks any new attempt to start it.

Here's how to find and kill that orphaned process.

1. Open Task Manager. Press Ctrl+Shift+Esc. If you get the compact view, click “More details” at the bottom.
2. Go to the “Details” tab. This shows every running process with its PID (process ID).
3. Now open Task Scheduler. Press Win+R, type taskschd.msc, hit Enter.
4. Find the task that's giving you the 0X00041301 error. Look in Task Scheduler Library on the left. Double-click the task.
5. Go to the “Settings” tab. Check the box that says “Allow task to be run on demand”. Click OK.
6. Right-click the task and choose “Run”. Wait a second. Then right-click it again and choose “End”. This sometimes forces the orphaned process to show its hand.
7. If that didn't kill it, you need to find the actual process. Go back to Task Manager's Details tab. Look for the program the task launches — for example, powershell.exe, cmd.exe, python.exe, or a custom .exe. Sort by “Command line” column if you can see it (right-click the column headers, select “Select columns”, then check “Command line”).
8. Once you find the matching process, right-click it and choose “End task”. Confirm if prompted.

After you kill the process, go back to Task Scheduler, right-click the task again, and try “Run”. It should start without the error now. If not, move to the next cause.

2. The task is configured to stop itself, but it's waiting on something

Some tasks have a “Stop if running longer than” setting. That sounds like a safety net, but it can backfire. The task hits that time limit, Windows sends a stop signal, but the program inside ignores it. Now the task is marked “Running” even though it's doing nothing.

Let's check and fix that setting.

1. Open Task Scheduler (taskschd.msc). Locate the stuck task.
2. Double-click it, go to the “Settings” tab.
3. Look for the section “If the task is already running, then the following rule applies:”. The default is “Do not start a new instance”. That's fine. The problem is further down.
4. Find “If the task does not stop when requested, force it to stop”. Make sure that box is checked. It should look like this:

   ☑ If the task does not stop when requested, force it to stop

5. Also check “Stop the task if it runs longer than:”. If it's set to something short like 1 hour, and the task legitimately needs more time, that's your culprit. Uncheck this box, or set it to something reasonable like “3 days”.
6. Click OK. Now try to end the task: right-click it, choose “End”. If it doesn't end, you're back to the first fix (killing the process manually).

I've seen this a lot with backup tasks and database maintenance scripts. They run for hours, hit the artificial time limit, but the underlying SQL query or file copy keeps chugging. The task gets stuck in a half-dead state.

3. The task's security context is corrupted

Less common, but when it happens it's a real head-scratcher. The task runs under a specific user account. If that account gets messed up — password changed, account disabled, profile corrupted — the task can't start a new instance because the old one's token is still in use.

Here's the fix.

1. In Task Scheduler, double-click the stuck task.
2. Go to the “General” tab.
3. Look at “When running the task, use the following user account:”. Write down that account name.
4. Click “Change User or Group”. Type the same account name, click “Check Names” to validate it. Click OK.
5. Now enter the password for that account twice. Click OK.
6. You should see a message like “The task has been updated with the new credentials”.

That re-establishes the security token. Now try to end the task (right-click, “End”). If it still says running, you may need to reboot. Yes, reboot. It's annoying, but it clears out the old security context completely.

One more thing: if the account was disabled or deleted, create a new local user account with admin rights (or use SYSTEM, but be careful with that). Then set the task to use that new account.

Quick-reference summary

If none of that works, check if you're running the task from a batch file that launches a child process and exits. Task Scheduler tracks the parent process. If the parent dies but the child lives, you'll get this error. Wrap the whole thing in a start /wait command, or use a single script that does everything synchronously.

I've been fixing this error for years. Start with cause #1. It's almost always a hung process.