Wdf01000.sys Causing high DPC Latency - but how can I know what driver is the problem

M

mart

Member
Joined
Jan 17, 2015
Posts
5
[h=2][/h]
Hi guys

BTW: sorry for double in Win7 forum - I posted to the wrong one......

really hope you can help me with this. I'm trying to configure a new computer for Music DAW use here. I have run ALL known and in depth system tweaks for Windows 8.1 but I still have very high latency in my realtime performance running Cubase. I'm sure of that because I'm coming from a 2008 Mac bootcamped with Windows and the same Cubase projects are running more efficiently than this system - something not right. Here are the new system specs:

Mobo: Gigabyte x99 SOC Force rev1.0. ( I had an old BIOS but flashed it to the latest)
CPU: Intel 5930x running at stock speed
Memory: 16gb Vengeance memory working at stock speed.
nVidia: GT610. I have tried windows drivers and the latest nVidia drivers. I also made sure the HDMI audio did not get installed
RME HDSPe sound card PCIe: RME generally make excellent PC drivers
Universal Audio OCTO DSP card: I have tried taking these out and tested and gotten the same result.

Running Latency monitor for a while tells me the worst offender is 'wdf01000.sys'. I've left latency monitor running just now for an hour and ISR count is 5378969 and counting. DPC count is 3412408 and counting

here is a Dropbox link to an XPERF trace I just did:
https://www.dropbox.com/sh/ymbkw8xp5...ecFKDiWGa?dl=0

Using WPA myself and trying to get to grips with it - I can also see that 'wdf01000.sys' tops the list.... unfortunately there is no further information to tell me what driver inside this framework may be causing the high load on the system. I've already spent nearly two full days trying to get to the bottom of this so I'm really hoping someone can help me out

regards

Martin​
 
Anyone able to have a look at this Xperf for me to see if more expert eyes can see the problem?
 
That binary is the binary responsible for the Kernel Mode Driver Framework - it's not actually a driver at all, so it isn't likely what's causing the DPC latency. I'll grab the ETL and look, but I won't be able to get to it for awhile. However, DPC latency in kernel mode drivers is usually caused by locks and lock request handling (WDFDEVICE locks) to do I/O operations. Usually I'd start looking at anything that processes global I/O (antivirus, antimalware, device emulation drivers) and USB devices. Audio devices can cause DPC latency too, so don't just assume.

Also, what flags did you use when capturing? I don't want to download 100MB to find out you didn't include the latency or driver flags.
 
Last edited:
I used the Latency flag on the trace only. I'll do another trace with the driver flag (will have to look this up as I'm an Xperf novice).
I'm having trouble on the same machine with things plugged into USB ports saying "Not Enough Resources for this USB device" or something similar. Might have something to do with it
 
I'm noticing that none of the symbols are providing me functional data in either the text output or in the wpa tool - did you set DisablePagingExecutive to 1 and reboot before taking this trace? If not, and this is an x64 box, these traces aren't going to be immensely useful without me doing some serious digging. If you haven't set the DisablePagingExecutive registry entry to 1 and rebooted, stop and do that now before anything else.
 
Actually, I've pulled some data out - some device driver is calling FxInterrupt::_InterruptDpcThunk over and over, which is definitely *bad*. The KMDF does not prevent WdfInterruptEnable or Disable from being called nor provide any rate limits, so a device driver is likely trying to control it's own power state without using the built-in KMDF power management, for instance (that is the usual cause of such behavior). I'm trying to track back to who's calling it, but ... we shall see.
 
....aaaaaaaaaaaaaaaaaand there's the culprit Cubase8.exe, so at least it's confirmed. I can see what it looks like by walking it through the CPU usage (sampled) DPC table, and then breaking that down further into process calls:

1. DPC/ISR by time definitely shows all of the time rolling up under the KMDF:
01.png

2. Further investigation would show that it's coming through an audio driver and subsystem:
02.png

3. Indeed, the graph would confirm when expanded:
03.png

4. I'm only showing one instance here, but this is indicative of what I found here and elsewhere - Cubase8.exe is the main culprit, and auxhost.exe also shows up often enough (nowhere near as much as cubase8, but probably 2nd most when counting):
04.png

That's about the gist of what I'm seeing here. Note that you can see obvious traces of both your PCIe card, and your USB audio device. Interesting indeed. Honestly, their code around using KMDF interrupts is the likely culprit, but you aren't going to be doing anything to fix it. As I mentioned in a previous post about the KMDF function we see in the first graph, the vendor needs to update their driver/firmware to do things "the right way" in their driver - no amount of tweaking on your part can fix that.
 
Last edited:
Note, since I cannot edit my post any longer - the problem is likely not cubase.exe, it's the audio driver (possibly drivers). It would also explain why different hardware brought different results.
 
Cluberti thank you very much for taking the time to look at that for me. Most enlightening!! I couldn't get this out of xperf myself as I wasn't sure where to look.

The process using the most is not actually my Audio device. 'UAD2pci.sys' is one of these :

www.uaudio.com/uad-plugin-ins/uad-2-pice.html

They are pcie format cards that offer lots of dsp with proprietary plugins and yes they have drivers-which are certainly taking their toll by the looks of it! I will contact the manufacturer with this info and see if they have an explanation for it.i'll report back at some stage if they have anything interesting to tell me.

As for the next busiest process -USB... I have no idea why there would be so much going on there. In fairness I have 3 usb midi keyboards attached, 2 licences (ilok) dongles, 1 printer, 1 receiver for a wireless computer keyboard, 1 receiver for a wireless remote control (software remote ). I did try disabling and disconnecting all of these to little avail though.

I've found a way currently of living with this machine by a setting inside the cubase software which looks ahead for audio to prevent glitches- but I'd still like it to be perfect!

I'll make contact with universal audio about that uad2pci.sys driver and see if they are interested in fixing their product!

Huge thanks again

Martin
 
I know this is an older thread, but, the dpc latency thing keeps on keepin' on. In my case on Windows 10 & Cubase 8.5 Pro, but, I do not have a UAD Card.

The latency issue is a huge one in "realtime" audio work for obvious reasons...when I touch the keyboard to record anything, any lag is extremely noticeable. Unfortunately,with my Asus ROG752 with an i76700HQ, the "speed" of the processor is somewhat neutered by "other processes" pre empting real time audio tasks. I have to increase the pro audio sound card buffers continually which makes recording anything from my fingers almost impossible.

Has anyone found any solutions for this ?
 
xilolee said:
Hi eightyeightkeys. :welcome:

You should open your own topic in the windows 10 sub-forum (not the one for tutorials) if you need help on this issue.
Click to expand...

I found this forum doing a Google Search with the search words "Wdf01000.sys Causing high DPC Latency" and this thread came up.

But, yes, thank-you I will do that.
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top