Read process memory without guessing at CPU load
An application feels slow. A process listing gives you measurements, but the labels matter: a large CPU total is not a current CPU percentage. Start with a precise question and report the measurement that actually answers it.
Editable pipeline · fictional data · Microsoft documentation
The task
The fixture records Name, CPU and WorkingSet64. CPU is a cumulative processor-time value; processes with different lifetimes are not directly comparable as instantaneous load. WorkingSet64 is the current working-set size in bytes, not a complete measure of committed memory or an application health verdict.
- Interpret CPU as accumulated processor time.
- Compare WorkingSet64 in bytes.
- Rank every candidate before taking the top results.
Genie tip: Interpret CPU as accumulated processor time.
See the objects move
Inspect this authored example with fictional data in the bounded browser model. The numbered stages show how its objects change.
Get-Process | Sort-Object CPU -Descending- Stage 1Get-Process
Positional values or no named parameters - Stage 2Sort-Object
-Descending
Build the reasoning
Inspect the measurements
chrome uses 486539264 bytes of working-set memory. MsMpEng has the largest CPU total, but that says nothing about which process is busiest this second.
Rank memory use
Sorting all rows puts chrome first and MsMpEng second. The ordering answers a memory question, independently of the CPU column.
Keep the top records
Only after sorting do you limit the result. The output contains two names and two byte counts.
Try it: predict, run and explain
| Name | CPU | WorkingSet64 |
|---|---|---|
| chrome | 842.31 | 486539264 |
| notepad | 0.4 | 12582912 |
| Windows PowerShell | 18.27 | 78643200 |
| spoolsv | 1.4 | 33554432 |
| MsMpEng | 950 | 220200960 |
Select your predicted objects before revealing the output. Then edit one stage and inspect the change.
Ctrl / Command + Enter runs the editor. This bounded model uses the displayed fixture; it does not run PowerShell on a computer.
Predict first, then run the pipeline.
Find the mistake
Calling CPU a percentage
The listing ranks accumulated CPU time. Use interval-based measurements when the question is current processor utilization.
Calling every stopped service broken
A disabled or on-demand service may be stopped by design. Compare current state with startup policy and the service’s role before proposing a restart.
MsMpEng has the largest CPU total. Can you conclude it causes the current slowdown?
Prove it: write it alone
Return processes whose WorkingSet64 is greater than 104857600 bytes (100 MiB), largest first. Return exactly Name and WorkingSet64. Do not use CPU as the sort key.
The checker also runs your command against a fresh fixture. Matching today’s names alone is not enough.
Show a worked solution
Read the stages, close this explanation, then write and test your own attempt.
Take it to a real environment
On Windows, a stopped automatic service is a review candidate, not an instruction to start it blindly. For process investigations, record timestamps and compare an appropriate interval. Some real process details require additional privileges; the browser fixture has no permission or process-lifetime races.
Real environment example · not executed here
Verify the details
Practise this
Find stopped automatic services
Return Name and StartType for stopped services with StartType Automatic.
The sandbox is visible now. Sign in with Google only when you run or check a task; commands and temporary files are discarded when you leave.
Run a command to inspect its result.