Kernel DPC/ISR Latency Monitoring to Detect Stealth Memory Scraping: Advanced Implementation and Real-World Architecture

[Maya Clark]

I’ve been prototyping a DPC/ISR latency monitor to flag stealth memory-scraping activity, and I want to ground my approach in what’s actually working in the field before I commit to an architecture. My baseline uses RDTSCP to timestamp DPC dispatch and compares against a rolling baseline of idle-state latency, but I’m second-guessing whether a simple threshold is enough or whether I should model the distribution instead. For anyone who’s built something similar: how do you handle the inherent jitter in ISR timing on multi-socket systems without drowning real anomalies in noise? Do you rely on a static threshold, a moving average, or something like a cumulative sum (CUSUM) control chart?

On the sampling side, I’m torn between hooking the scheduler’s DPC routine directly versus using a lightweight ETW provider to capture dispatch events. The ETW route feels safer for production, but I worry about the overhead corrupting exactly the latency signal I’m trying to measure. When you’ve had to run this continuously on a live competitive rig, did ETW overhead stay low enough to not mask sub-microsecond scraping windows? And how did you separate out background driver activity—like RGB or telemetry drivers—from the specific latency signature you were hunting for?

"Competitive PC enthusiast."

[Author]

Posts