Fix Console Window Host (conhost.exe) High CPU Usage on Windows

Console Window Host can attract attention for two different reasons: it appears several times in Task Manager, or one instance keeps using the processor after the work you started should have finished. These are different situations. Multiple entries alone do not establish a problem. Persistent CPU activity is a reason to investigate the particular console session and the software using it.

This guide explains how to check conhost.exe, trace the activity behind it, and choose a fix without removing a Windows component. Start with the process that is actually busy; a high CPU total at the top of Task Manager does not mean every process underneath it is responsible.

Try These First

1. Press Ctrl + Shift + Esc and sort Task Manager by CPU. Check the value beside Console Window Host, not just the total.
2. If you recognize an active installation, build, backup, or other command-line job, check its progress before interrupting it.
3. Save your work. Close an idle console session you recognize and watch whether the CPU activity stops.
4. If the problem returns, note when it happens: immediately after sign-in, on a schedule, or after launching a particular app.
5. Do not delete conhost.exe, download a replacement executable, or disable unrelated Windows services.

What Is conhost.exe?

conhost.exe is Windows Console Host, commonly displayed as Console Window Host. It provides Windows console services for text-based programs, including input and output handling. In the classic console experience, it also provides the window in which those programs appear. Command Prompt and PowerShell are the programs running within that environment; they are not interchangeable names for the host.

With a modern terminal, the visible interface and console servicing can belong to different components. A background console host therefore does not necessarily have a matching visible window. Microsoft explains this separation in its console and terminal definitions.

Separate console sessions can account for multiple instances. An installer or background helper can also use console infrastructure without asking you to open a command prompt.

Why Console Window Host May Use High CPU

The host processes console activity, so an application producing excessive output is one useful lead. Repeated progress updates, a rapidly scrolling error message, or a script that retries without a pause can keep the console busy. Microsoft describes the host's input, output, and rendering responsibilities in Inside the Windows Console. The troubleshooting approach below follows from those responsibilities; these symptoms are leads to test, not a diagnosis by themselves.

Other possibilities include an application or console bug, a recurring background job, damaged Windows components, or an unwanted program. A malicious program can imitate a familiar filename or use the genuine console host. Conversely, a hidden window, multiple instances, or a process that starts again does not by itself prove infection.

Use the timing to narrow the search:

Step 1: Verify the Busy Process and Its File

In Task Manager, find the busy Console Window Host entry. Right-click it and choose Go to details, if available. Record its PID—the process identifier—so you can distinguish it from other conhost.exe instances. Right-click that entry and select Open file location.

On a typical installation, the active Windows copy is:

C:\Windows\System32\conhost.exe

Windows can be installed on a different drive. Additional Windows servicing or architecture-specific copies also mean that finding another file with this name is not sufficient evidence of malware. Inspect the executable used by the running process, not a similarly named file found through Search.

Open the file's Properties and inspect Digital Signatures, if that tab is present. You can also check the actual path in PowerShell:

Get-AuthenticodeSignature -LiteralPath 'C:\Windows\System32\conhost.exe' |
    Format-List Status, Path, SignerCertificate

Replace the example path if Task Manager opened a different file. Look for a valid Microsoft signature. PowerShell can check catalog signatures as well as embedded signatures, so a missing Properties tab is not conclusive. See Microsoft's Get-AuthenticodeSignature documentation.

A valid signature verifies the file's signature; it does not establish that the program using the console is harmless. An unexpected path in a download or temporary folder needs investigation, especially when the signature or origin is also unclear. If those checks raise concerns, move to Step 6 before ordinary software troubleshooting.

Step 2: Find the App or Script Behind the Activity

Task Manager can show additional context. On Processes, right-click a column heading and enable Command line, where available. On Details, use Select columns to enable PID, Image path name, and Command line.

The host's own command line may contain internal arguments rather than a recognizable script name. For an additional lead, run this read-only PowerShell query:

$snapshot = Get-CimInstance Win32_Process
$byId = @{}
foreach ($process in $snapshot) {
    $byId[[uint32]$process.ProcessId] = $process
}

foreach ($consoleHost in $snapshot) {
    if ($consoleHost.Name -ne 'conhost.exe') { continue }
    $creator = $byId[[uint32]$consoleHost.ParentProcessId]
    $plausible = $creator -and $creator.CreationDate -and
        $consoleHost.CreationDate -and
        ($creator.CreationDate -le $consoleHost.CreationDate)

    [pscustomobject]@{
        ConhostPID = $consoleHost.ProcessId
        ParentPID = $consoleHost.ParentProcessId
        ParentName = if ($plausible) { $creator.Name } else { 'Unavailable' }
        ParentCommandLine = if ($plausible) { $creator.CommandLine } else { $null }
    }
}

Match ConhostPID to the busy instance. Some fields may require an elevated PowerShell window. Avoid publishing unredacted command lines: they can contain personal paths or credentials.

Treat the result as a clue. A parent can exit, and Windows can reuse its PID; the timestamp comparison filters out one obvious mismatch but cannot turn a changing process list into a complete history. The creator also need not be the application currently generating the console output. These process properties and PID limitations are documented in Win32_Process.

For more context on Windows 11, Microsoft's Process Explorer provides process inspection tools. Check its current system requirements before using it on an older Windows release. Never terminate csrss.exe or another critical Windows process just because it appears in a relationship you are examining.

Step 3: Stop the Problem at Its Source

Once you have a likely application, make one controlled change and watch the result.

1. Save work in the application and check whether its current operation is still progressing.
2. Stop a recognized job using its own Cancel or Stop control. For a command you started interactively, Ctrl + C often requests cancellation; its effect depends on the program.
3. Close that console session normally and recheck the same workload in Task Manager.
4. If the application is unresponsive, use End task only after identifying it and accepting that unsaved work or the current operation may be lost.
5. Reopen the application. If the same action recreates the problem, update or repair that application and inspect its settings or logs.

For a script you maintain, look for a retry loop, repeated errors, or excessive console output. Use the tool's documented logging controls to reduce unnecessary output while retaining useful errors. A lower host CPU reading after that change supports the output-related explanation; it does not prove the underlying job is now working correctly.

Avoid ending every console host at once. Doing so removes the evidence linking a particular session to the symptom and may interrupt unrelated work.

Step 4: Check What Launches at Sign-In or on a Schedule

If the issue begins after sign-in, open Task Manager → Startup apps. In the older interface, the tab is called Startup. Temporarily disable one recognized, recently added application, restart when convenient, and check again. Restore its previous setting if it makes no difference.

If the timing is periodic, open Task Scheduler from Start. In Task Scheduler Library, inspect likely tasks' Triggers and Actions. The executable, script path, arguments, and last run time are more useful than an unfamiliar task name alone. Check the owning application's logs for the same time period.

Change only a task whose purpose and owner you understand. A legitimate backup or management job may need its configuration repaired rather than its trigger removed. On a work-managed PC, give IT the PID, timestamps, and relevant application details before changing managed jobs.

Step 5: Update the Relevant Software, Then Repair Windows if Needed

Install available Windows updates appropriate to your edition and support status, and restart if required. Update the application that reproduces the issue. If the problem is specific to Windows Terminal or a separately installed PowerShell version, check that product's updates too.

When multiple unrelated console applications fail, or other signs point to Windows file damage, open Command Prompt as administrator and run:

DISM.exe /Online /Cleanup-Image /RestoreHealth

After DISM completes successfully, run:

sfc /scannow

Let each operation finish. Record any error code instead of repeatedly rerunning a failed repair. Restart after repairs and reproduce the original task. This order follows Microsoft's System File Checker instructions. These tools repair Windows components; they do not correct the logic of a third-party script.

Repair operations can create their own activity. If DismHost.exe becomes the busy process while servicing is running, see the separate Dism Host Servicing Process guide.

Step 6: Scan if the File or Its Origin Looks Suspicious

Open Windows Security → Virus & threat protection → Scan options. Select Full scan, then Scan now. Review detections and follow the security app's remediation guidance. If another antivirus product is your active provider, use its equivalent scan.

For persistent suspected malware, Microsoft Defender Offline scan runs after a restart in the recovery environment. Save your work first. After Windows returns, review Protection history and check whether the unwanted activity recurs. Microsoft describes these choices in its virus and threat protection guide.

Do not create an antivirus exclusion for conhost.exe to suppress the symptom. The target of the investigation is the suspicious file or activity, not the mere presence of a console host.

Step 7: Use a Clean Boot if the Trigger Remains Unclear

A clean boot is a temporary diagnostic test for background software conflicts. Record your existing startup configuration first; on a managed PC, involve IT.

1. Search Start for System Configuration and open it.
2. On Services, select Hide all Microsoft services before disabling the remaining services for the test.
3. On Startup, select Open Task Manager and record and disable the enabled startup apps.
4. Restart and repeat the action that previously triggered the problem.
5. If the symptom disappears, restore items in groups and retest to isolate the cause.
6. Restore the previous configuration when finished, keeping only a deliberately identified problem item disabled while you repair it. Leave the Boot tab and advanced boot settings alone.

Some functionality will be unavailable during this test. A quiet system is meaningful only if you also reproduce the original workload. Follow Microsoft's linked guide for its full isolation and normal-startup procedure.

How to Tell Whether the Fix Worked

Repeat the task that caused the slowdown, then let it finish. Observe both overall CPU and the particular console host for several minutes. Repeat the check after sign-in if startup was the trigger. For a scheduled issue, check the next scheduled run.

The useful result is that sustained, unexplained activity no longer returns and the application still completes its work. Brief spikes and multiple console hosts can remain normal. If the problem persists, collect the executable path, signature result, PID, timing, related app version, and reproducible steps for the software vendor or IT.

FAQ

Is conhost.exe a virus?

The Windows component is legitimate. A matching filename is not proof of trust, and a genuine console host can be used by unwanted software. Check the running file and the activity behind it.

Can I disable Console Window Host permanently?

Do not remove or rename the Windows executable. Console Window Host is not a standalone service you should disable in Services. Correct the application, job, or file responsible for the unwanted activity.

Why is it running when no Command Prompt window is open?

A background tool or a terminal session may use console infrastructure without displaying a classic Command Prompt window. Investigate its origin if its resource use or launch pattern is unexpected.

Why does conhost.exe reappear after I end it?

A program or scheduled job may create another console session. Repeatedly ending the host will not change that trigger. Identify what launches it and whether that launch is intended.

Does changing process priority fix the problem?

It may change how the system shares CPU time, but it does not repair a loop, remove unwanted software, or fix an application defect. Use the cause-based checks above before changing scheduling behavior.

What if Task Manager shows a different busy process?

Follow that process instead. Related guides cover SysMain high CPU usage and OMA-DM Client activity; their fixes address different Windows components.