• Still running Windows 7 or earlier? Support for Windows 7 ended on January 14th 2020. Please review the thread here for more details.

[SOLVED] Wdf01000.sys...guess which problem? ^^

P

Payne

Member
Joined
Dec 28, 2014
Posts
6
Hey guys! My name is Max and I'm new here! I usually don't like to pester people with questions on forums, but rather read and fix problems myself. Well, today, after 8 hours I've finally reached my limit!

I have two TC Electronic interfaces: Konnekt 6 and Impact Twin. My OS is Win7 and I'm using a firewire interface with a Texas Instruments chipset(The one that TC explicitly states it's interfaces will tolerate). Point being I'm able to test my system using two different interfaces, alas, with the same negative results. I think I'll just cut the long story short and say that I found this thread on your forum: https://www.sysnative.com/forums/wi...her-dpc-latency-problem-audio-glitches-3.html
I checked my system(while running a video on youtube) with DPC Latency Checker, LatencyMon and the latter told me that the supposed culprit is the wdf01000.sys, but from what I've read it's just a lowly(lol) low level kernel driver and is not the cause for the ridiculous latency spikes I'm getting.
So as per your instructions(in the link above) I've downloaded and ran the xperf diagnostics tool.
My first question is how do I find the info about what exact drivers have been "talking" to Wdf01000.sys? It's a massive file and I just can't find the info about the driver interactions the way Tomas did in that previous post.
And my second question is-did I run the diagnostics too right? I did everything like Tomas said(again, in the link above), however, in the command prompt the thing ran for about a second or two. Then I punched in the command to generate the report file.
So, the bottom line is: I have a bunch of these report files...maybe you guys can give me some pointers on how to read them instead of uploading them?
But if you'd like to take a look at them I have another question: how do I "compress" these files before uploading? I've read in another thread of yours that I should do that.
PS: I also ran xperf as specified here: https://www.sysnative.com/forums/wi...ues-with-wpa-windows-windows-vista-7-8-a.html , however it also didn't run for too long and I haven't been able to decipher the file.
Help me, Tomas-you're my only hope!:grin1:
 
Here is a nice little picture gallery of bluescreens I've able to capture, which have been infrequent before(no bluescreens have been registered on my old interface at all), but in the last few days have become de rigueur and happen only when watching video or playing games. Super intense audio crackling and video stuttering precede these events: https://plus.google.com/u/0/1152598...6097975490332342946&oid=115259894077919512411
 
The driver causing your blue screens is likely the cause of the DPC latency as well, so it's relevant. Could you give the crash dumps please?
 
WDF_VIOLATION (10d)

This indicates that Kernel-Mode Driver Framework (KMDF) detected that Windows found an error in a framework-based driver.

Code: 
0: kd> .bugcheck
Bugcheck code 0000010D
Arguments 00000000`00000008 0000057f`f6a30fd8 00000000`00000004 fffffa80`06da5a00

Code: 
0: kd> k
Child-SP          RetAddr           Call Site
fffff800`0317d298 fffff880`00ec2889 nt!KeBugCheckEx
fffff800`0317d2a0 fffff880`00ebe464 Wdf01000!FxDmaTransactionBase::Initialize+0xf5
fffff800`0317d300 fffff880`02c1f36e Wdf01000!imp_WdfDmaTransactionInitialize+0x2c0
fffff800`0317d3b0 fffff880`02c16c04 1394ohci!IsochTx::HandleIsochAttachBuffers+0x3ce
fffff800`0317d450 fffff880`02c16069 1394ohci!Isoch::HandleIsochAttachBuffers+0x100
fffff800`0317d4b0 fffff880`00e81c36 1394ohci!Isoch::WdfEvtIoInternalDeviceControl+0x121
fffff800`0317d520 fffff880`00e811ff Wdf01000!FxIoQueue::DispatchRequestToDriver+0x542
fffff800`0317d5a0 fffff880`00e8955e Wdf01000!FxIoQueue::DispatchEvents+0x66f
fffff800`0317d620 fffff880`00efd3d2 Wdf01000!FxIoQueue::QueueRequestFromForward+0x23e
fffff800`0317d670 fffff880`00efd6ba Wdf01000!FxIoQueue::ForwardRequestWorker+0x112
fffff800`0317d6e0 fffff880`00edfef3 Wdf01000!FxIoQueue::ForwardRequest+0x46
fffff800`0317d710 fffff880`02c128c4 Wdf01000!imp_WdfRequestForwardToIoQueue+0x1d7
fffff800`0317d780 fffff880`02c12605 1394ohci!Dispatch::DispatchIrbRequest+0xa8
fffff800`0317d7d0 fffff880`00e81c36 1394ohci!Dispatch::WdfEvtIoInternalDeviceControl+0x131
fffff800`0317d840 fffff880`00e811ff Wdf01000!FxIoQueue::DispatchRequestToDriver+0x542
fffff800`0317d8c0 fffff880`00e8c2fb Wdf01000!FxIoQueue::DispatchEvents+0x66f
fffff800`0317d940 fffff880`00e8251a Wdf01000!FxIoQueue::QueueRequest+0x2ab
fffff800`0317d9b0 fffff880`00e7e79a Wdf01000!FxPkgIo::Dispatch+0x4da
fffff800`0317da20 fffff880`00e7e866 Wdf01000!FxDevice::Dispatch+0x19a
fffff800`0317da60 fffff880`00e83fef Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff800`0317daa0 fffff880`02c10178 Wdf01000!imp_WdfRequestSend+0x3fb
fffff800`0317db30 fffff880`02c103af 1394ohci!ChildDevice::DispatchIrbRequest+0x60
fffff800`0317db80 fffff880`02c0f289 1394ohci!ChildDevice::HandleIrbRequest+0x1db
fffff800`0317dbc0 fffff880`00e81c36 1394ohci!ChildDevice::WdfEvtIoInternalDeviceControl+0x141
fffff800`0317dc30 fffff880`00e811ff Wdf01000!FxIoQueue::DispatchRequestToDriver+0x542
fffff800`0317dcb0 fffff880`00e8c2fb Wdf01000!FxIoQueue::DispatchEvents+0x66f
fffff800`0317dd30 fffff880`00e8251a Wdf01000!FxIoQueue::QueueRequest+0x2ab
fffff800`0317dda0 fffff880`00e7e79a Wdf01000!FxPkgIo::Dispatch+0x4da
fffff800`0317de10 fffff880`00e7e866 Wdf01000!FxDevice::Dispatch+0x19a
fffff800`0317de50 fffff880`04fcd11a Wdf01000!FxDevice::DispatchWithLock+0xa6
fffff800`0317de90 fffffa80`078cc8b0 TCNear+0x1c11a

Your audio interface software is dispatching a request. The operation within Wdf01000 occuring on the direct memory access object is not in the correct state, and this is the reason for the bug check.

Update this driver or disable it/remove the device and see if the crashes and latency stop.
 
It seems this work is being performed at an IRQL of 2, this would seem to be the cause of the latency as well.
 
Code: 
0: kd> !irql
Debugger saved IRQL for processor 0x0 -- 2 (DISPATCH_LEVEL)

Most callers (and anything they call) cannot exceed PASSIVE_LEVEL, correct. However I believe this is due to the fact that the caller in this case (audio interface driver) is going through various dispatch support routines which require it to be at DISPATCH_LEVEL.
 
Your audio interface software is dispatching a request. The operation within Wdf01000 occuring on the direct memory access object is not in the correct state, and this is the reason for the bug check.

Update this driver or disable it/remove the device and see if the crashes and latency stop.
Click to expand...

You mean the audio interface driver? I've done that a few times. In fact, turning the devices off removes the latency spikes completely, but guys, that sorta defeats the purpose lol. Or should I bring this up with the manufacturer and tell them that they sold me a glitchy piece of crap?

I want to stress again that I experience this with BOTH of my interfaces-they're from the same manufacturer and both use the same driver, as far as I know.

Bottom line: what should I do? lol
 
It's a driver issue, so there's nothing we can do. Contacting the manufacturer won't do anything unless they can supply a different/working driver.
 
Yeah I kinda just want to let them know what the problem is so they can work on it.

Thank you very much for your assistance!

I think I'll just roll the driver back to some previous version, I've done this thing before, I just don't remember what the issue was.

Happy Holidays!
 

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

Back
Top