Custom Windows ISO Stripping and Background Service Elimination for Latency: Edge Cases, Failure Modes, and Root-Cause Debugging

[Ethan Richardson]

I’ve been running a stripped Windows 11 LTSC build with a custom ISO for the last few months, disabling Telemetry, Windows Update services, and Superfetch, but I’m hitting inconsistent results in-game. My core question: how are you all handling interrupt affinity for your NIC and storage controllers after a strip-out? When I pin IRQ priorities to a single core, I see occasional input spikes in the first 10-15 minutes of a session before things stabilize, which smells like thread contention between the driver pool and my game’s main loop. Have you experienced this, and what’s your affinity strategy—do you isolate the gaming core and leave IRQ steering alone, or do you manually distribute controllers?

On the telemetry front, I’ve killed the Diagnostics Tracking service and DisarmBackgroundTaskRegistration, but Task Manager still shows surprise activity from svchost instances I can’t trace. What’s your process for identifying which services actually matter versus which are safe to disable without breaking input drivers or voice comms? And for anyone debugging latency spikes, what tools do you rely on—xperf ETW tracing, Process Explorer’s IO graph, or something custom? I’d specifically love to hear about edge cases where a “safe” disable caused a boot failure or driver rollback.

"Just click their heads." – Ancient CS wisdom"

[Author]

Posts