Background Intelligent Transfer Service High CPU: Find the BITS Job

Background Intelligent Transfer Service (BITS) high CPU usage is a reason to check the transfer and the app behind it, not permanently disable the service. First confirm that Task Manager shows sustained CPU load rather than only network activity. Check Windows Update and any running installer for progress or an error. If the slowdown keeps returning, inspect the BITS jobs, compare their progress and identify the responsible application before cancelling anything. A busy BITS service alone does not mean the PC is infected.

What BITS does—and what the CPU graph cannot tell you

BITS moves files in the background for Windows and applications. It can resume transfers after a lost connection or restart, and Windows can use it to download updates. Microsoft describes a service designed to account for network usage and connection cost; “background” does not mean that every application using it will always be invisible to the user. [1]

Think of BITS as the delivery mechanism. The important question is which application requested the delivery and whether it is making progress. Stopping the mechanism may lower activity temporarily while leaving the original failed update or installer unchanged.

1. Open Task Manager with Ctrl + Shift + Esc. Sort by CPU while the slowdown is happening. Compare that with the Network and Disk columns.
2. Expand the busy Service Host entry. If several services share the host, the process’s CPU total does not prove that BITS alone is responsible. Use the Service Host identification steps to match the current process ID to its services.
3. Check the Windows Update page and any installer or app download queue you opened. Note the time, progress, error message and whether the load settles when the download finishes or you use the app’s own pause control.

If CPU stays modest but the connection is saturated, follow the Service Host network-usage guide. Bandwidth controls and delivery settings address a different bottleneck from sustained processor load.

Inspect BITS jobs without changing them

For persistent unexplained activity, open Windows PowerShell as administrator from Start. On a work-managed PC, ask IT to inspect organization-owned transfers. The following commands read the queue; they do not cancel downloads:

Import-Module BitsTransfer
$jobs = Get-BitsTransfer -AllUsers
$jobs | Format-List JobId,DisplayName,JobState,OwnerAccount

Get-BitsTransfer normally shows only the current user’s jobs. -AllUsers requires administrator rights and includes jobs belonging to other accounts. Keep the full JobId when comparing results; similar display names can describe different jobs. [2]

OwnerAccount identifies an account, not necessarily the application. A system account or familiar display name is a clue, not a verdict. Correlate the job with the installer/update queue and the time the symptom begins. Do not assume that every system-owned transfer is Windows Update, or that an unfamiliar name proves malware.

To compare progress, run this read-only view, then run it again after a short observation period under similar conditions:

$jobs = Get-BitsTransfer -AllUsers
$jobs | Format-List JobId,BytesTransferred,BytesTotal

Compare the same JobId across both observations. Increasing transferred bytes are evidence of progress; a single unchanged reading is not enough to label a job stuck. Connection loss, a pause or network policy can delay work. If an error needs investigation, $jobs | Format-List * shows more detail, which may include private paths or server information—keep it local or redact it before sharing.

No jobs listed? Confirm you used an elevated Windows PowerShell session and -AllUsers. A job may also have finished between observations. Recheck while the symptom is present; an empty queue does not prove that every service in the same host is idle. If the module is unavailable, record the error and use the application/update repair route instead of downloading a replacement module from an unknown site.

Read the state before choosing a fix

The state describes the transfer’s lifecycle, not its CPU consumption. Use it together with progress and the application error. Microsoft’s BITS state documentation distinguishes these cases: [3]

• Queued or Connecting: waiting to run or trying to contact the server. Check whether the app is waiting for connectivity or another download.
• Transferring: actively moving data. Compare the byte counts before interrupting it.
• TransientError: a recoverable failure that BITS can retry. Investigate the connection, policy or reported error; this state is not itself evidence of corruption.
• Suspended: paused. Let the creating application control whether it should resume.
• Error: the job needs intervention. Record the error and repair or retry through the application that created it.
• Transferred: the transfer succeeded but still needs finalization. Let its application finish handling the files; do not cancel it just because it remains visible.

Example: one installer job shows increasing bytes while another repeatedly reports the same error with no progress. Investigate the failing app first rather than clearing both jobs. If the error disappears but CPU remains high, return to process identification: the job state alone has not established the cause.

Recover the affected app or job

Start with the control closest to the problem. Let a progressing update finish and complete a requested restart. For a repeatedly failing app download, use that app’s supported cancel, retry, update or repair option. If the issue occurs only when a particular installer runs, record that trigger before changing Windows services.

For a personal PC where BITS appears unresponsive after the responsible app has been closed and no installation is actively applying changes, save your work and try one normal restart. Alternatively, an administrator can open services.msc, find Background Intelligent Transfer Service and choose Restart if available. This temporarily interrupts transfers; it does not clear the job queue. Keep the configured startup type unchanged. If the service will not restart, record the error rather than forcing it or deleting its files.

Selected-job cancellation is an optional fallback. Use it only after you have identified an abandoned or repeatedly failing transfer and know the owning app can recreate the download. Prefer its own cancel control. Do not cancel a managed update, another user’s job or an unidentified job merely because it looks old.

Microsoft’s Remove-BitsTransfer cancels the selected job and removes its associated transfer files, including files already downloaded within that job. You may need to download them again. It is not an uninstall command. [4] To inspect one exact job before considering cancellation:

$jobId = Read-Host 'Paste the exact JobId you checked'
$job = Get-BitsTransfer -AllUsers |
    Where-Object JobId -eq $jobId
$job | Format-List *

Confirm the output contains only the intended job and that its owner, name and transfer details match your investigation. If nothing matches, stop and obtain a fresh inventory. Preview the action with $job | Remove-BitsTransfer -WhatIf. Only when you intend to discard that transfer, run $job | Remove-BitsTransfer -Confirm and review the confirmation.

Avoid blanket “reset all users” recipes and deleting BITS queue databases as routine performance fixes. They can discard unrelated work. If Windows Update itself keeps failing, use its troubleshooting workflow with the actual error code; if an application immediately recreates the job, investigate that application instead of repeatedly erasing its queue.

When a malware scan makes sense

A normal BITS job, high CPU reading or unfamiliar account label is not a malware detection. A scan becomes more relevant when the slowdown began after an unknown installer or fake update, recurring security warnings appear, or other unwanted changes accompany the activity. A remaining app, service or scheduled task can restart unwanted work even after you close the visible program.

In that situation, download and install Gridinsoft Anti-Malware, update its database, run a Full Scan, review and remove detected threats, then restart. This is the practical cleanup path; you do not need to manually hunt through every job or registry entry first.

If your concern is a lookalike process rather than a transfer, use the svchost.exe safety guide. Do not delete C:\Windows\System32\svchost.exe to stop BITS. A scan with no detections does not guarantee that every threat is absent or diagnose a Windows performance fault.

Confirm the cause is addressed

Repeat the original app or update action after the repair and restart. Check the same resource column, confirm that the intended download completes and watch whether the same failure returns. Leave BITS available for legitimate transfers. A permanently disabled service can hide the symptom while breaking the work that needed it.

References

1. Microsoft. “Background Intelligent Transfer Service.” Microsoft Learn, updated May 25, 2021; accessed September 30, 2026. BITS purpose and transfer behavior.
2. Microsoft. “Get-BitsTransfer.” Microsoft Learn, accessed September 30, 2026. Job inventory and administrator permissions.
3. Microsoft. “BITS Job states.” Microsoft Learn, updated March 5, 2021; accessed September 30, 2026. Transfer states and lifecycle.
4. Microsoft. “Remove-BitsTransfer.” Microsoft Learn, accessed September 30, 2026. Cancellation and associated file deletion.