[Release] Stuttometer: Real-time micro-stutter diagnostic

[drop]

Hey everyone,

I built an open-source diagnostic utility called Stuttometer to solve a common frustration with tracking down intermittent micro-stutters and frame-pacing variance in Windows games.

Current profiling tools often leave a gap when diagnosing sporadic hitches:
• LatencyMon measures idle DPC/ISR execution, not active in-game frame delivery.
• PresentMon / CapFrameX show when a frametime spike occurs, but cannot identify the kernel or driver stall that caused it.
• Windows Performance Recorder (WPR/xperf) offers full system traces, but recording multi-gigabyte ETL files continuously is impractical for catching unpredictable hitches.

Stuttometer runs continuously in the background using a lightweight, lock-free in-memory flight recorder (~23 MB RAM, zero runtime heap allocations). When a frametime spike, cadence judder (oscillating frame delivery), compositor glitch, or audio dropout occurs, it freezes that capture window and correlates surrounding events:

• DPC / ISR Spikes: Identifies culpable drivers (nvlddmkm.sys, amdkmdag.sys, storport.sys, etc.).
• D3D12 Shader / PSO Compilation: Catches synchronous runtime pipeline creation stalls.
• GPU VRAM Paging & Demotion: Detects VidMm overcommit and PCIe thrashing.
• Thread Starvation & Memory Hitches: Flags involuntary context-switch preemption, hard page faults, and working-set trims.

Written in C++20 with a standalone native Win32 dark-mode GUI and a CLI version. Free and open-source under GPLv3.

You can find the source code and pre-built binaries on GitHub: https://github.com/xdr0p/stuttometer

Feedback from anyone testing frame pacing consistency or diagnosing elusive driver hitches on high-refresh/VRR displays is very welcome!

[kyube]

--snip--

LLM-generated glorified front-end for .etl analysis. Redundant to use over WPA or the easier-to-digest xtw.
Not only that, the claim of "multi-GB file" is clearly false for anyone who made recordings.
What exactly are you trying to solve with this? I don't see a common user occurring use-case which isn't encapsulated with aforementioned tooling.

[drop]

--snip--

LLM-generated glorified front-end for .etl analysis. Redundant to use over WPA or the easier-to-digest xtw.
Not only that, the claim of "multi-GB file" is clearly false for anyone who made recordings.
What exactly are you trying to solve with this? I don't see a common user occurring use-case which isn't encapsulated with aforementioned tooling.

Thanks for the feedback, but there are a couple of misunderstandings about how Stuttometer works:

1. It is not an ETL front-end or post-processor. Stuttometer does not parse or output .etl files. It consumes ETW events live via EVENT_TRACE_REAL_TIME_MODE directly into a pre-allocated, lock-free C++20 ring buffer with zero runtime allocations during active tracing.
2. Regarding the "multi-GB" file reference: When hunting intermittent stutters with WPR/xperf in file mode with a full diagnostic provider set (DPC/ISR, CSwitch, DxgKrnl, Disk, Page Faults), traces generate tens of MB/s and quickly balloon into multiple gigabytes over a normal session. While WPR has a circular memory buffer mode, it lacks real-time frametime/judder triggering—by the time you manually react to an intermittent stutter, the event window in a small buffer is often lost.
3. Why it's not redundant: PresentMon/CapFrameX measure frame pacing without kernel driver correlation. LatencyMon tracks DPC/ISR execution times in isolation without frame pacing or GPU flip awareness. Stuttometer's purpose is specifically to bridge the two: detecting frame spikes, judder, and audio underruns in real time and automatically freezing a 250 ms cross-subsystem correlation window.

The codebase is open source (GPLv3) if you'd like to inspect the ETW session manager, ring buffer implementation, or correlation heuristics directly you can check it out on github