DPC triangle…

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


The symptoms didn’t match exactly, but once he updated that driver, the problem vanished…

1 comment

Leave a comment

Your email address will not be published. Required fields are marked *

Exit mobile version