Good idea. Can you submit it as a feature suggestion in Feedback Hub and send
me a link?
Another way to get some transparency is to look at ETW logs from portcls, which
should reveal (a) whether the miniport was invoked and (b) what it returned
(the status code, not the mapped error result.)
From: Tim Roberts<mailto:timr@xxxxxxxxx>
Sent: Friday, January 4, 2019 10:44 AM
Subject: [wdmaudiodev] Re: HLK - Audio Codec - KS Position Test errors.
cedric demiere wrote:
Successfully instantiated KSPIN_DATAFLOW_IN pin\
KSPIN_DATAFLOW_IN pin is currently in state KSSTATE_STOP; want it to be in
Setting KSPIN_DATAFLOW_IN pin to state KSSTATE_ACQUIRE
Setting KSPIN_DATAFLOW_IN pin to state KSSTATE_PAUSE
KSPIN_DATAFLOW_IN pin is currently in state KSSTATE_PAUSE; want it to be in
Setting KSPIN_DATAFLOW_IN pin to state KSSTATE_RUN
sizeof(dp->WritePacketInfo))) - Value (1117)
avcore\audiocore\test\wdmaudio\portcls\kspostst\pintest.cpp Line: 2340
And, as an unrelated side note to those Redmond folks who are listening. I
heartily applaud the new philosophy within the kernel groups to release
subsystems as open source. Having the source for KMDF and friends, for
example, is a huge win for debugging and answering tricky questions. It would
be a HUGE benefit to the driver community if the WHQL/HCK/HLK test suites could
be released in source form as well. We have the file name and line number, but
that information is of absolutely no use without the source. I, personally,
have single-stepped through the tests in windbg to isolate what turned out to
be a test bug in the Media Foundation tests, but that would not have been
necessary if I could have gone to github to look up the tests.
Even more, being able to see what the tests expect would help driver writers
answer that most difficult of questions, "what do I really have to support to
be treated as an X device?" It just seems unfair to have to meet the
expectations of a test we can't actually inspect.
Tim Roberts, timr@xxxxxxxxx<mailto:timr@xxxxxxxxx>
Providenza & Boekelheide, Inc.