Always-on tool for Windows 10 / 11

Find out what caused that stutter

StallScope runs before the symptom does. It records 187 metrics every second and measures, in milliseconds, the moment the machine actually stopped responding. When you remember roughly when it happened, you run one report.

Get itWhat it records

By the time Task Manager is open, it is over

"The mouse stutters sometimes." "It locks up for a second." Two things make this class of symptom hard, and neither of them is about having the right tool — they are about what time you started looking.

  • When

    The evidence is already gone

    A symptom that clears in a few seconds has left no trace by the time Task Manager finishes opening. All that remains is your memory of it, so the only move left is to sit and wait for it to happen again.

  • What

    Averages do not show it

    For the few seconds it is frozen, disk latency and queue depth spike — while CPU, memory and GPU all read perfectly normal. Watching averages, or a "current value" readout, shows nothing happening at all. Smooth those seconds into a one-minute average and they are gone.

So StallScope is not "a light, tidy monitoring tool". It is built for one thing: to already be running before the symptom, and to still have the evidence afterwards.

Features

Every design decision here is derived from those two problems.

  • Measures the freeze itself

    Every performance counter is a candidate cause and nothing more. StallScope times how late its own monitoring thread wakes up, and that is the only number that answers "did the machine actually stop?" Anything past 200ms is written to the stall log by default.

  • Never collapsed into a single figure

    Each core and each drive gets its own columns, all of them kept. "Save only the largest one" makes the distribution impossible to reconstruct later, and a single pinned core is invisible in the _Total column.

  • A window you can open mid-symptom

    The last hour is drawn from an in-memory ring buffer, so opening the window reads nothing from disk. Starting to load days of logs while the machine is frozen would defeat the purpose.

  • The tray icon is the measurement

    One bar is 12 seconds; five bars are the last minute. Bar height is the worst wake-up delay in that interval, and a bar that crossed the threshold turns red. Red bars stay for a minute, so a stall that happened while you were away is still there when you get back.

  • Episodes, ranked causes, per-process involvement

    The report pulls out the abnormal intervals, ranks candidate causes by deviation normalised against their own quiet-time spread, and shows what was running at the time. You can lower the thresholds and re-run it.

  • Runs with ordinary user rights

    No elevation is ever requested. The self-test measures the collection cost on the spot; on the development machine it came to 9.0ms per second, or 0.90% of one core.

Same symptom, different causes

Freezing is the result, not the cause. StallScope keeps every indicator from the moment it froze, side by side, so one symptom can be separated into distinct causes.

  • It froze, but disk and CPU were both fine

    If committed memory alone was pinned at its limit, the machine was waiting on an allocation. Task Manager’s default "Memory" column shows the working set, which still looks comfortable — you cannot get here without recording commit separately.

  • Disk latency and queue spike at the moment it froze

    With CPU and memory both reading normal, that is an I/O stall on the storage. The averages stay calm throughout, so it is invisible afterwards unless it was kept per drive at one-second resolution.

  • Overall CPU is low, yet it stutters

    If a single core was pinned, the problem is the thread running on it. Total utilisation and the _Total column never show this.

  • Short interruptions, over and over

    A rise in DPC or interrupt time points at driver work. It is recorded per core, so which core it happened on is still there afterwards.

What settles it is never one indicator on its own — it is that the others were normal. That is why nothing is collapsed into a summary and everything is kept side by side.

Screens

Every image below is the real rendering code’s own output, not a mockup.

  • The dashboard: a large wake-up delay chart on top, where three red spikes rise out of a calm green band and dashed lines mark the 200ms and 80ms thresholds. Below it, three charts side by side for disk latency, CPU and committed memory, and at the bottom a table of current values next to a list of recent stalls with their times and durations
    The dashboard, opened from the tray. Wake-up delay leads
  • The settings window: a text field and browse button for the data folder at the top, then four numeric fields aligned on their digits for the system and process sampling intervals, the stall threshold and the retention period, and at the bottom checkboxes for starting at logon and showing the tray icon. Each field is annotated on the right with what its value means
    Settings: output folder, intervals, thresholds and autostart
  • Five tray icon states in a row: at the left, low grey bars with one green bar for a calm machine; moving right the bars grow taller and turn amber; at the right, a row of red bars for a recorded stall. Each state is also shown at its actual 16-pixel size
    The tray icon. Calm on the left, worse towards the right

Requirements

OS
Windows 10 / 11 (64-bit)
Where it writes
One drive other than the system drive. If C: is what freezes, the recording must not freeze with it — this is the default.
Disk use
About 10MB per day compressed. Kept for 14 days by default.
Interface language
Japanese only

Get it

From the Microsoft Store

Listing in preparation

The Store handles signing and updates. One install button, and it starts recording from the next time you log on.

The Store page is not published yet. A link will appear here once it is — until then there is deliberately nothing to click.