Taskhostw.exe High CPU: How to Fix Windows Task Scheduler Spikes

If taskhostw.exe is using high CPU, first identify the busy process and the Windows task it is hosting. Note the PID and time of the spike, then compare them with Task Scheduler’s running tasks and history. Check whether the work is repeating on a trigger, retrying after a failure, or starting after a missed schedule. Fix the identified task or its application, then confirm that it completes without the recurring load.

taskhostw.exe is the Host Process for Windows Tasks. It can host COM-handler tasks; it is not the Task Scheduler service itself, and not every scheduled program runs inside it. Seeing several copies, or a brief spike after sign-in, does not by itself establish a fault.

Identify the busy taskhostw.exe instance

1. Press Ctrl + Shift + Esc to open Task Manager. Select Details and search for taskhostw.exe.
2. While the problem is happening, note the busy row’s PID, CPU reading, and the time. If the process exits and returns, record the new PID.
3. Watch more than one reading. Does CPU stay elevated, rise at regular intervals, or settle after one short run?
4. If memory is the concern, compare the same instance over time using a memory-size column. Working set delta (memory) shows a change between updates, not the process’s total RAM.

In our Windows 11 capture, both instances were at 0% CPU. This is an identification example; it does not show the high-load symptom or an improvement after a fix. There is no single CPU percentage or RAM amount that proves this host is malfunctioning.

Find the scheduled task behind the spike

1. Search Start for Task Scheduler and open it. Select Task Scheduler (Local).
2. In the Actions pane, select Display All Running Tasks. Record the relevant task names and paths while the CPU spike is present. A short task may finish before you open this view.
3. Find a candidate in Task Scheduler Library, including its subfolders. Select it and inspect History, Last Run Time, and Last Run Result.
4. If history is disabled, return to the root and select Enable All Tasks History, using administrator permission if requested. Wait for the next normal occurrence. Enabling history records future events; it cannot reconstruct earlier missing entries.
5. Compare the task’s start, action, completion or failure events with the load. Record its full path and any error code. Matching timestamps are a lead, not proof that the task consumed the CPU.

For more detail, open Event Viewer and browse to Applications and Services Logs > Microsoft > Windows > TaskScheduler > Operational. Follow the same task and instance through its events. Microsoft recommends task history, status and exported task definitions as core Task Scheduler troubleshooting evidence.

Optional: match the running task’s engine PID

If the task name remains unclear, open Windows PowerShell and run this read-only check during the spike. Replace 2788 with the PID you recorded. It does not start, stop or modify tasks.

$targetProcessId = 2788
$scheduler = New-Object -ComObject 'Schedule.Service'
$scheduler.Connect()
$scheduler.GetRunningTasks(1) |
    Where-Object { $_.EnginePID -eq $targetProcessId } |
    Select-Object Name, Path, EnginePID

EnginePID identifies the process running a task. Results depend on your permissions and currently running tasks; the flag 1 includes hidden tasks that you are allowed to see. An empty result does not rule out a task that has already ended or is outside your security context. See Microsoft’s GetRunningTasks documentation.

Our local check associated SystemSoundsService and CacheTask with the same taskhostw.exe PID. Both used COM-handler actions. Neither was shown to be faulty: this illustrates why a shared host can leave more than one candidate. An Actions tab showing a custom handler instead of a normal program path can be expected; Task Scheduler supports both handler and executable actions.

Choose the next step from the run pattern

Correct an unintended repetition interval

Once you have identified a task, right-click it and select Export before editing. Keep the XML as a record of its definition and note the original values. Prefer the owning application’s scheduling controls when available. For Windows-managed tasks, investigate the responsible component before changing Microsoft’s defaults.

1. Open the task’s Properties > Triggers. Check every enabled trigger, not just the first one.
2. Select a relevant trigger and choose Edit. Inspect Repeat task every and for a duration of under Advanced settings.
3. Compare the interval with the recurring starts in History. Also check whether separate triggers launch the same work.
4. For a task you own, remove unintended repetition or choose an interval suited to the actual work. If you change or disable a trigger, record which scheduled runs will no longer happen.
5. Save the change and observe the next expected cycle. Restore the original setting if it does not address the problem.

The five-minute interval shown is an example, not a recommended default. Repetition defines scheduled start opportunities; it does not mean Windows waits until the preceding run finishes before counting another interval. The task’s instance policy also matters. Microsoft explains the interval/duration relationship in Repeating a Task.

Fix the failed action before tuning its retries

If each burst follows a failure, record the failed action and its result before changing the schedule. A missing program, unavailable resource or defective application component needs a different fix from an overly frequent trigger. Interpret the code in context: 0x41301 means the task is running, not that it has failed. Microsoft lists the Task Scheduler status and error constants.

1. Open the task’s Actions tab to identify the program or handler responsible for the work. Check the owning application’s logs or support information for the recorded error.
2. Repair the specific cause: for example, correct a stale path in your own task after moving a program, restore an expected resource, or update the identified application.
3. Open Settings and inspect If the task fails, restart every and Attempt to restart up to. These govern failure retries separately from the trigger’s normal repetition.
4. If an optional task you own is repeatedly failing, temporarily reduce its retries while investigating, documenting the original values and the work that may remain undone. Reassess after repairing the action.

Fewer attempts may reduce the symptom while leaving the work broken. Confirm a successful outcome before calling this a fix. A retry interval works with a retry count, as described in Microsoft’s RestartInterval documentation.

Check why the task runs after a missed start

A task starting after the PC wakes is not automatically misfiring. Check its Triggers first: sign-in or another event may be the intended trigger. Under Settings, also inspect Run task as soon as possible after a scheduled start is missed. Where applicable, this allows late execution after a missed schedule; it is not a guarantee of an immediate run.

Microsoft documents StartWhenAvailable and its applicability limits. If a task you own repeatedly catches up at an inconvenient time, reconsider its schedule or application settings. Turning catch-up off can leave missed work undone, including backups or synchronization, so compare that consequence with the temporary load.

Prevent unwanted overlapping instances

If a task can take longer than the gap between starts, inspect the rule at the bottom of Properties > Settings. It applies to instances of that task, not to every process named taskhostw.exe.

These behaviors follow Microsoft’s instance-policy definitions. For your own task that should never overlap, ignoring a new instance may be suitable. If every run is required, investigate the runtime and schedule instead of silently dropping work. This setting will not repair a handler that stays busy within one existing run.

Repair the identified component, then verify the result

For a task installed by another application, update or repair that application and check whether its own settings control the schedule. For a Microsoft task, keep the task path, error details and Windows version, check for relevant Windows updates, and seek component-specific guidance. Do not disable an entire task folder or the Task Scheduler service to suppress the host.

A temporary disable test is appropriate only for an identified optional task when you understand the consequence. Record its enabled state, disable that task, observe the next expected occurrence, and re-enable it if the test does not help. A reduction in CPU is supporting evidence, not proof that all work in a shared host came from that task.

Before testing again, change only one setting. Compare the same sign-in, wake or idle conditions across the interval that previously caused the spike. Check both the task’s completion and its intended output, such as a backup or report. A quiet CPU is not a successful outcome if the task stopped doing its job.

If the file itself looks suspicious, right-click the taskhostw.exe row in Task Manager and use Open file location, then inspect the file’s properties and signature. Our local System32 copy had a valid Microsoft Windows signature. A familiar name alone does not authenticate another copy; investigate an unexpected location or invalid signature with Windows Security. Do not delete the Windows executable as a CPU fix.

Frequently asked questions