Culprit
Why is this Windows machine slow? Drop a PerfMon CSV and get a straight answer: what is eating the CPU, whether the machine is out of RAM, whether the disk is the real bottleneck, and which processes are responsible. No install, no account, no Log Parser.
Runs entirely in your browser. Nothing is uploaded, stored, or sent to us.1Build your capture script
Pick how long to record and what to look at. The script below updates as you choose. Run it in PowerShell on the affected machine (Windows PowerShell or PowerShell 7, no admin rights needed) and have the user reproduce the slowness while it runs, otherwise you measure an idle machine.
Under 2 minutes risks missing the stall entirely. Five is a good default.
Faster sampling catches short spikes and makes a bigger file.
Already have a .blg from PerfMon? Convert it first with relog input.blg -f CSV -o output.csv.
A .blg is a binary format your browser cannot read.
2Drop the CSV here
This handles one machine. RFF handles the fleet.
Capturing a CSV per complaint works until you have three hundred machines. RFF keeps a rolling performance history on every endpoint, so when someone says it was slow an hour ago, you can just look.
Start free for 100 endpointsHow to find out why a Windows PC is slow
Windows has all the data you need to explain a slow machine, buried in Performance Monitor behind counters most people never learn. This tool wraps that: you run a short capture, drop the file, and it reads the counters the way an experienced engineer would and tells you the answer in one sentence.
What it checks
- CPU - whether the processor is pinned, and which process is responsible. It accounts for core count, so a process using "300%" on a 12-core machine is correctly read as three of twelve cores, not a crisis.
- Memory - whether the machine is starved for RAM, which is the hidden cause behind a lot of "slow disk" complaints, because Windows pages to disk when it runs out of memory.
- Disk - read and write latency, the counters that actually prove a storage bottleneck. Anything over 25ms is felt as a freeze. Queue depth is used as supporting evidence only, because "queue over 2" is HDD-era folklore that misleads on SSD and NVMe.
- Top consumers - the processes eating the most CPU and RAM, named, so you know what to close or investigate.
Capture while it is actually slow
The single most common way this wastes an afternoon is capturing while the machine feels fine. Slowness is usually intermittent, so start the capture and have the person reproduce the problem while it runs. A one-instant snapshot proves nothing; a few minutes of data can show a bottleneck clearly.
FAQ
Why is my Windows computer running slow?
The four usual causes are a pinned CPU, running out of RAM (which forces paging to disk), a slow or failing disk, and a single process eating everything. This tool reads a short PerfMon capture and tells you which one it is, in plain words, with the top processes named.
How do I capture performance data on Windows?
Run the one-line PowerShell script on this page while the machine is slow. It uses Get-Counter to record CPU, memory, and disk for a few minutes and writes a CSV to your Desktop. No admin rights needed, and it works in both Windows PowerShell 5.1 and PowerShell 7.
Is my data uploaded anywhere?
No. The CSV is read and analysed entirely in your browser. Nothing is uploaded, stored, or sent to us. You can confirm it in your browser developer tools: there is no upload request.
Can it read a .blg file from PerfMon?
Not directly - a .blg is a binary format the browser cannot read. Convert it first with "relog input.blg -f CSV -o output.csv", then drop the CSV here.
My CPU looks idle but one app is slow. Why?
A single-threaded process pinned at one CPU core is only a small fraction of a multi-core machine, so overall CPU looks fine while that one application is unusable. The analyzer detects this case specifically and calls it out.
Open source
Culprit is MIT-licensed at github.com/deadarcher/culprit. The analysis engine on this page is byte-identical to the one in the repo, and our CI fails the build if they ever drift. Self-host it with one line of Docker:
docker run --rm -p 8080:80 ghcr.io/deadarcher/culprit:latest Wrong verdict on a real capture? Open an issue, with the CSV if you can share it - that is exactly the feedback that tunes the thresholds.