Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Dmytro Koval
High CPU usage is a symptom, not a diagnosis. How to read what the Task Manager percentage counts, the four load shapes and what each points at, how to open System, svchost.exe, WMI Provider Host and System interrupts, when a throttled clock or a starved vCPU is the cause, and when sustained load is a security signal.
Updated: October 2026
The fan spins up, Task Manager shows a number in the red, and the ticket says the laptop is "slow". Ending the top process clears it until lunch, then it's back. This guide is about reading high CPU usage before you touch anything: what the number counts, which of four patterns you're looking at, and how to open the processes that hide the answer.
The percentage in Task Manager is time, not effort. Windows samples how much of the last second each logical processor spent running something other than the idle thread, then averages across all of them. On an 8-core, 16-thread laptop, one process holding one thread flat out shows as roughly 6% of the total. The machine can feel stuck on that one task while the overall number looks calm.
This is why the Processes tab changed in 2025. Until then it measured work against the base clock and per process, so a single busy core could show as 100% and turbo-boosted cores could read above it before being clipped. Microsoft's Insider announcement in February 2025 moved Task Manager to "the standard metrics to display CPU workload consistently across all pages and aligning with industry standards and third-party tools". The old figure survives as an optional CPU Utility column on the Details tab, hidden by default. Per Windows Latest, the new formula reached every Windows 11 24H2 machine with the May 2025 update, so a guide written before that and a screenshot taken after it won't agree.
The threshold matters too. Microsoft's high CPU guidance, updated February 2026, treats usage that "consistently remains at 80 percent or higher for extended periods" as the problem and calls temporary spikes normal. So the first thing to establish isn't the name at the top of the list. It's whether you're looking at a spike or a plateau, and how many cores are carrying it.
Open Task Manager's Performance tab, right-click the CPU graph and switch it to logical processors. Then watch it for a minute. The pattern narrows the cause faster than sorting the Processes tab, because the same process name can mean four different things depending on how the load behaves.
| What you see | What it usually means | Confirm with |
|---|---|---|
| Plateau under load, drops when the user stops | The work is real: a build, an export, a big spreadsheet, a video call | Resource Monitor's Average CPU column, sorted descending |
| Plateau at idle, nothing open | A background job that never finished, a stuck service, or a miner | Process Explorer, with the process tree showing who started it |
| Sawtooth or regular spikes every few seconds or minutes | A poller: monitoring agent, WMI query loop, a scheduled task, an indexer | WMI-Activity log, Task Scheduler history, Event Viewer timestamps |
| One core pinned at 100%, the rest idle | A single-threaded job, or one driver's deferred work landing on one core | Logical-processor view in Task Manager, then LatencyMon or WPA |
| High total with no process owning it | Interrupts, DPCs, a throttled clock, or vCPU contention on a hypervisor | Performance Monitor's % Interrupt Time and % DPC Time, then the host |
Two of these rows are easy to misread. "Plateau under load" gets ended by a technician who thinks the export is a runaway, and the user runs it again tomorrow. "High total with no owner" gets written up as a software problem when the machine is simply running at a fraction of its clock. We'll come back to both.
Resource Monitor earns its place here because Task Manager shows the current second and Resource Monitor's Average CPU column shows the last minute. A process that's busy on average is the one to investigate, which is the same ordering Microsoft's guidance recommends. Launch it with resmon, open the CPU tab, and sort by Average CPU.
Browsers deserve their own line in that table because they break the pattern. Chrome and Edge run every tab and extension as its own process, so one runaway tab holds a core while the browser's total looks spread out. Each browser has a task manager of its own on Shift+Esc that names the tab or extension, and our Chrome memory guide covers the fleet-side settings that keep tabs from piling up.
Each tool resolves one level deeper, and each one has a blind spot the next one covers.
Task Manager gives you a process name and, on Windows 11, the service inside a Service Host when you expand the row. That's the right first move, and a ticket with a real application at the top ends there. When the name is a real application, the fix lives with that application, and our guide on lowering CPU usage covers the usual ones with the policy that stops the repeat.
Process Explorer from Sysinternals resolves a process into its threads. Right-click the process, open Properties, go to the Threads tab and sort by CPU. The busy thread's start address names the DLL or driver it began in, and the Stack button shows the functions it's running. Microsoft's Process Explorer guide notes the stack view doesn't update by itself and refreshes at most once a second, so for anything that flickers you step up again. One more tell worth knowing: in Process Explorer's graphs, red is kernel-mode time and green is user-mode. A red spike with no application to blame is a driver or the OS, not the user's software.
Windows Performance Recorder and Windows Performance Analyzer, both in the Windows ADK, sample where the CPU is every millisecond and attribute it to a process, thread, module and function, including drivers. Microsoft's guidance is to record for only three to five minutes while the problem is happening, because the trace file grows fast. Darien's Tips walks through WPA's CPU usage views, which is the part that trips people up the first time.
Recording a trace takes two commands from an elevated prompt, and the second one needs to run while the load is still there:
codewpr -start CPU -filemode wpr -stop C:\temp\highcpu.etl
Open the file in WPA, expand CPU Usage (Sampled), and group by process, then thread, then module. The module column is where a driver finally gets a name.
The rule for picking a depth: stop at the first tool that gives you a name you can act on. A ticket that gets past Task Manager is almost always one of four containers.
A sawtooth is the easiest shape to diagnose and the easiest to ignore, because by the time you connect the spike has passed. Something is running on a schedule. The job is to find the clock.
Start with timestamps. Note the minute and second of three spikes from Task Manager, then look for a match. Task Scheduler's history tab lists every task that started in that window, and Get-ScheduledTask | Get-ScheduledTaskInfo sorted by LastRunTime gives the same list without the console. Event Viewer's System and Application logs often carry a service start or an agent check-in at the same second. Monitoring agents, backup clients, inventory scans and the Windows Search indexer all work on intervals, and an interval that lines up with the spikes is your answer.
When the spike belongs to WMI Provider Host, the asker is sometimes Windows itself. In this January 2025 thread, laptops ramped up for no visible reason until WMIMon showed a stream of hardware inventory queries against motherboard and USB device IDs. The calls stopped when the Windows Update service did, and the poster recognized them as the detection checks HP ships with its driver packs.
The fix for a poller is never to end the process. It's to change the interval, move the job out of the workday, or stop two tools from asking the same question. A monitoring agent and a security agent both inventorying hardware every five minutes is a common setup and a wasteful one.
Four names in Task Manager aren't the culprit. They're the box the culprit is in.
The System process has no executable of its own. As Mark Russinovich put it in his write-up of a laptop that kept spiking, it "exists solely to host operating system threads for the memory manager, cache manager, and other subsystems, as well as device driver threads". His culprit turned out to be a Broadcom network driver, found by watching which System threads were busy, then profiling which kernel module they were executing in. The modern version of that trace is a WPR capture read in WPA, where the driver's name appears next to its share of CPU. Third-party filter drivers from security, backup and VPN products are the usual suspects when System is busy and nothing else is.
Service Host is a shell around one or more services. On a machine with more than 3.5 GB of RAM, Windows gives nearly every service its own host, so expanding the row in Task Manager names the service directly. Older or shared hosts need splitting with sc config <service> type= own before you can tell which service is working. Our svchost.exe guide covers the mapping and how to tell the real file from a lookalike.
WmiPrvSE.exe answers questions. It only burns CPU because something keeps asking, and Microsoft's WMI high CPU guide is built around finding the asker. Note the busy instance's PID in Task Manager, open it in Process Explorer and read the WMI Providers tab to see which provider DLL it hosts. Then open Event Viewer at Applications and Services Logs, Microsoft, Windows, WMI-Activity, Operational. Each query event carries a ClientProcessId. Match it with Get-Process -Id <pid> while the load is happening, because the ID stops meaning anything once the client exits.
In this May 2026 thread, a domain controller sat at 100% with WMI Provider Host at 40 to 50% and the Event Log service behind it. The operational log showed the same query against the Security event log repeating from one client PID. The top reply named the fix before anyone touched the WMI repository: find the process behind that PID, which is usually a monitoring agent or a security tool polling logon events.
When the log is quiet, Microsoft points at WMIMon, a free tool that prints every WMI call live with the client PID, namespace and class. Restarting the Winmgmt service buys you until the next poll. It doesn't fix anything.
This row isn't a process at all. It's the time the CPU spent handling hardware interrupts and the deferred work drivers queue behind them. Microsoft's driver documentation explains the mechanism: an interrupt service routine "must execute as quickly as possible", so drivers queue deferred procedure calls, DPCs, that run later at a lower priority. A driver that queues a lot of them, or one whose DPCs take too long, shows up here instead of under its own name.
Confirm it in Performance Monitor with the Processor counters % Interrupt Time and % DPC Time. If either one carries the load, the question becomes which driver, and that's LatencyMon or a WPA trace with the DPC and ISR tables open. Network adapters, storage controllers and audio drivers come up more often than anything else, and so does a device that's failing. The thread below is the shape to recognize: a Windows Server with System interrupts above 70%, a backend that isn't heavy, and the replies pointing at the host's hardware, storage wait and a bad driver rather than the application.
Sometimes the process list is innocent. The CPU is doing ordinary work at a fraction of its speed, so ordinary work fills it.
Heat does this first. Intel's processor temperature guidance puts the junction limit for its parts "between 100°C-110°C", and says that on reaching it "the processor typically reduces frequency and power to prevent overheating". The chip is protecting itself, not failing. But a core running at a third of its clock needs three times as long for the same task, and the usage percentage climbs to match. Compare Speed with Base speed on Task Manager's Performance tab while the machine is busy. A tool like HWiNFO goes further and shows which limit is active: thermal, power or current.
Blocked vents, a dead fan, dried thermal paste and a power plan pushed by policy all end in the same throttled clock. The power plan case, with a fleet of laptops capped by a pushed policy, is covered in our lower CPU usage guide.
Virtual machines do it differently. A VM's CPU percentage is measured against the vCPUs the hypervisor promised, not the cores it delivered. When the host is oversubscribed, the guest waits for a slot, and inside the guest that wait can read as load with no process to blame. The top reply in the System interrupts thread above made exactly that point about a cheap VPS. On your own Hyper-V or vSphere host, the counters to read are on the host side: CPU ready time in vSphere, Hyper-V Hypervisor Virtual Processor counters on Hyper-V. Inside the guest you'll keep chasing a ghost.
A plateau at idle with a process name you don't recognize is a security question before it's a performance one. MITRE ATT&CK catalogues it as Resource Hijacking, updated October 2025, with compute hijacking as the first sub-technique: cryptocurrency mining on machines the attacker doesn't own. The detection guidance reads like a CPU ticket. Sustained load alongside mining tools or obfuscated scripts, outbound connections to mining pools, and persistence through scheduled tasks or scripts.
Five things to check before you end it. Where the executable lives: System32 is expected, AppData, Temp, ProgramData and Public are not. Whether the name is spelled right: svchost lookalikes are a documented trick. What started it, which Process Explorer's tree shows and Task Manager doesn't. Whether it's talking to the internet, which Resource Monitor's Network tab shows per process, or Get-NetTCPConnection -OwningProcess <pid> lists without the console. And whether it comes back after a reboot, because a miner with persistence will.
If two of those fail, stop treating it as a performance ticket. Isolate the machine, let the EDR quarantine, and work out how it arrived. Ending the process and moving on leaves the persistence in place, and the malware removal guide covers the order that doesn't.
The opposite mistake is worth a line too. System Idle Process is the share of time the CPU had nothing to do, which is why it sits at the top of the Details tab on a healthy machine. A reading of 97% there means the machine was 3% busy. Every help desk has received the ticket asking for it to be removed.
Run it in this order. Each step either names the cause or rules out a whole branch.
When MsMpEng.exe, the Defender engine, is the name you land on, Microsoft's own session walks through its performance analyzer, the tool that shows which files and paths the scan is spending time on.
The version of this ticket that costs the most is the one you can't reproduce. The user swears the fan ran all afternoon, you connect at five and it's at 3%. The fix is to capture the evidence when it happens rather than after. A script that fires on sustained load and records the top five processes with their paths, parents and the core count, plus the current clock speed, turns "it was slow" into a diagnosis you can read the next morning. The core of that script is one query. It lists the busiest processes with the two fields Task Manager never shows, the path and the parent:
powershellGet-CimInstance Win32_Process | Sort-Object -Property @{e={$_.KernelModeTime + $_.UserModeTime}} -Descending | Select-Object -First 5 Name, ProcessId, ParentProcessId, ExecutablePath
OpenFrame can run that script across a client's devices and collect the output, so the pattern across twenty laptops shows up without twenty remote sessions.
The patterns in a fleet are the same four from this post. A sawtooth on every machine at the same minute is a poller in your own stack. A plateau at idle on one machine is that machine's problem. A throttled clock on one hardware model is a firmware or power policy problem. Reading the shape first works at scale for the same reason it works on one laptop.
High CPU usage is a symptom with four shapes, and the shape tells you where to look. Establish spike or plateau and how many cores before you read a single process name. Open the containers rather than blaming them, confirm interrupts with the counters that measure them, and check the clock and the hypervisor when nothing owns the load. An unfamiliar name at idle gets the security checks first.
Once you have a name, the lower CPU usage guide linked above has the fix for each one and the policy that stops it coming back.
Head of Product Engineering
Hi! My name is Dmytro, but everyone calls me Dima. I’m a Software Developer and together with the development team, I help bring Flamingo to life — putting it on its feet from a technical perspective. Originally from Lviv, Ukraine 🇺🇦, but currently based in Spain, where I’ve been enjoying the blend of great weather, culture, and nature. I’m passionate about the mountains and love traveling — exploring new places and cultures really inspires me. These experiences constantly recharge me and give me a fresh perspective, both personally and professionally.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.