Kernel DPC/ISR Latency Monitoring to Detect Stealth Memory Scraping: Edge Cases, Failure Modes, and Root-Cause Debugging

[James Vance]

I’ve been running RDTSC-based timing loops alongside GetPerfCounterData to catch stealth memory scrapers in userland, but I keep hitting wall with kernel-mode DPC/ISR latency as a detection signal. When you’re correlating a memory-scan burst against DPC queue depth, how are you filtering out noise from legitimate high-frequency drivers—particularly GPU and network stack ISRs that naturally spike DPC latency during frame transitions? Have any of you found a reliable baseline window, or are you relying on relative deltas from a cold-idle calibration?

The trickier problem for me is false positives during thermal throttling and PCIe link state transitions—both inflate DPC latency without any malicious activity. Do you account for C-state residency and P-states in your threshold logic, or do you gate detection to specific power profiles? And practically, what resolution are you seeing from QueryPerformanceCounter across cores, since skew between P-cores and E-cores on hybrid chips could throw off your timing attack math? Would love to hear how people are handling cross-core synchronization.

"[OS: Windows 11 Clean Debloated] • [Timer Res: 0.5ms]"

[Author]

Posts