So once upon a time, a PFE had a problem with his video game stuttering. The game would be playing fine and then suddenly, the sound would skip until he rebooted his PC. Nothing in the event log, device manager reports all good…
So we collected an xperf trace using the following flags:
xperf -on Latency+DISPATCHER -f kernel.etl -stackwalk CSwitch+ReadyThread+ThreadCreate+Profile -BufferSize 1024 -MaxBuffers 1024 -MaxFile 1024 -FileMode Circular
Reproduced the problem..(-FileMode Circular, you see, makes xperf collect a black box trace, auto-overwriting itself, oldest data drops…)
Then post repro, run
xperf –d results.etl
Easy as pie!
DPCs are way high here. It’s a 4 processor box with very high DPCs on one processor and spikes in other CPUs…
(DPCs are discussed a bit here and here.)
So I was interested…
So here we have a gap of time where CPUs were ‘busy’ doing a DPC operation, interrupt, or processing a stack. For something like .8 seconds, long enough to be a sound gap noticeable to the human ear…
An analysis of the stacks revealed we were grinding in DPC\USBPort.sys, but in the stack it was referencing USBAudio.sys.
A quick search found he was running an old version of USBAudio.sys, and this hotfix was available:
The audio applications stop responding in Windows 7 or in Windows Server 2008 R2 after you resume the computer from the S3 sleep mode
http://support.microsoft.com/kb/2122063
The symptoms didn’t match exactly, but once he updated that driver, the problem vanished…
thanks