Windows 10 audio seeing crash with AddStreamResource but not with PcAddStreamResource

I am working on an audio miniport driver for Windows 10. During the initalization of the driver in StartDevice() function i am providing the driver owned resources to Windows by calling AddStreamResource() function after retrieving IID_IPortClsStreamResourceManager interface.

I am providing all the resources in the PCSTREAMRESOURCE_DESCRIPTOR properly. But i am seeing a crash with Access violation. Below is the code.

PCSTREAMRESOURCE_DESCRIPTOR Streamresource;
PCSTREAMRESOURCE hRes = NULL;
PDEVICE_OBJECT pdo = NULL;

//m_pDeviceObject is a device FDO.
PcGetPhysicalDeviceObject(m_pDeviceObject, &pdo);
ASSERT(pdo != NULL);
PCSTREAMRESOURCE_DESCRIPTOR_INIT(&Streamresource);
Streamresource.Pdo = pdo;
Streamresource.Type = ePcStreamResourceThread;
Streamresource.Resource.Thread = (PETHREAD )m_Thread;
ntStatus = m_pPortClsStreamResourceManager->AddStreamResource(
NULL, &Streamresource, &hRes);

This function is crashing with SYSTEM_THREAD_EXCEPTION_NOT_HANDLED error code.

However if i call the function PcAddStreamResource() with the same parameters, it doesn’t crash and the driver loads properly.
I validated that m_pPortClsStreamResourceManager, PDO and m_thread are not NULL.

Below is the crash dump.

BugCheck 7E, {ffffffffc0000005, fffff800d650a160, ffffd0005dbac3d8, ffffd0005dbabbf0}

Probably caused by : portcls.sys ( portcls!PcGetPhysicalDeviceObject+0 )

Followup: MachineOwner

nt!DbgBreakPointWithStatus:
fffff802`39bd6900 cc int 3
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff800d650a160, The address that the exception occurred at
Arg3: ffffd0005dbac3d8, Exception Record Address
Arg4: ffffd0005dbabbf0, Context Record Address

Debugging Details:

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: fffff800d650a160

BUGCHECK_P3: ffffd0005dbac3d8

BUGCHECK_P4: ffffd0005dbabbf0

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
portcls!PcGetPhysicalDeviceObject+0
fffff800`d650a160 488b4140 mov rax,qword ptr [rcx+40h]

EXCEPTION_RECORD: ffffd0005dbac3d8 – (.exr 0xffffd0005dbac3d8)
ExceptionAddress: fffff800d650a160 (portcls!PcGetPhysicalDeviceObject)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000040
Attempt to read from address 0000000000000040

CONTEXT: ffffd0005dbabbf0 – (.cxr 0xffffd0005dbabbf0)
rax=ffffd0005dbac648 rbx=ffffe001d0064520 rcx=0000000000000000
rdx=ffffd0005dbac650 rsi=0000000000000000 rdi=ffffd0005dbac7a8
rip=fffff800d650a160 rsp=ffffd0005dbac618 rbp=0000000000000000
r8=ffffd0005dbac7a8 r9=ffffe001d0064520 r10=0000000000000000
r11=fffff800d64e400b r12=0000000000000000 r13=ffffe001d167ea80
r14=ffffe001cddbfca0 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
portcls!PcGetPhysicalDeviceObject:
fffff800d650a160 488b4140 mov rax,qword ptr [rcx+40h] ds:002b:0000000000000040=???
Resetting default scope

CPU_COUNT: 4

CPU_MHZ: 5a0

CPU_FAMILY: 6

CPU_MODEL: 4c

CPU_STEPPING: 3

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000040

READ_ADDRESS: 0000000000000040

FOLLOWUP_IP:
portcls!PcGetPhysicalDeviceObject+0
fffff800`d650a160 488b4140 mov rax,qword ptr [rcx+40h]

BUGCHECK_STR: AV

DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE

ANALYSIS_VERSION: 10.0.10240.9 x86fre

LAST_CONTROL_TRANSFER: from fffff800d650f76b to fffff800d650a160

STACK_TEXT:
ffffd0005dbac618 fffff800d650f76b : ffffd0005dbac7a0 0000000000001000 ffffe001cf9e19e0 0000000000000000 : portcls!PcGetPhysicalDeviceObject
ffffd0005dbac620 fffff800d6458c65 : 0000000000000000 0000000000000001 ffffe001cddbfdf0 fffff80200000000 : portcls!CPortWaveRT::AddStreamResource+0x2b
ffffd0005dbac650 fffff800d643f3f5 : ffffe001d0063000 ffffe001cddbfca0 ffffe001cf81c210 ffffe001d167ea80 : xxxxxx!CAudioEnginePnw::Init+0x1245 [c:\users\ushaikhx\desktop\threshold_10135\source-jay\audio\audiorealtek\audiodriver-coreisolation\lpepnw.cpp @ 435]
ffffd0005dbac7f0 fffff800d642b89a : ffffe001cf9e1740 ffffe001cf81c210 ffffc000d2aee480 ffffe001cddbfca0 : xxxxxx!CSstAdapterCommon::Init+0x4b5 [c:\users\ushaikhx\desktop\threshold_10135\source-jay\audio\audiorealtek\audiodriver-coreisolation\common.cpp @ 141]
ffffd0005dbac9e0 fffff800d642e1ca : ffffe001cf81c210 ffffc000d2aee480 ffffe001cddbfca0 ffffe001d167ea80 : xxxxxx!!CAudioAdapter::Init+0x4aa [c:\users\ushaikhx\desktop\threshold_10135\source-jay\audio\audiorealtek\audiodriver-coreisolation\adapter.cpp @ 604]
ffffd0005dbacb20 fffff800d65115c1 : ffffe001cddbfca0 ffffe001d167ea80 ffffc000d2aee480 0000000000000000 : xxxxxx!CAudioAdapter::StartDevice+0x23a [c:\users\ushaikhx\desktop\threshold_10135\source-jay\audio\audiorealtek\audiodriver-coreisolation\adapter.cpp @ 888]
ffffd0005dbacbb0 fffff800d651396d : ffffc000d2aee480 ffffc000d548d3c0 0000000000000000 0000000000000000 : portcls!PnpStartDevice+0xb1
ffffd0005dbacc10 fffff80239afd054 : ffffe001cd9a7040 fffff80239afcb58 0000000000000000 0000000000000000 : portcls!EnqueuedIoWorkItemCallback+0x2d
ffffd0005dbacc40 fffff80239afc769 : fffff80239e5d340 ffffe001cd9a7040 fffff80239afcf60 0000000000000000 : nt!IopProcessWorkItem+0xf4
ffffd0005dbaccb0 fffff80239b69698 : 0000000000000000 0000000000000080 fffff80239e5d340 ffffe001cd9a7040 : nt!ExpWorkerThread+0xe9
ffffd0005dbacd40 fffff80239bd6306 : ffffd0005da34180 ffffe001cd9a7040 ffffd0005da40bc0 0000000000000000 : nt!PspSystemThreadStartup+0x58
ffffd0005dbacda0 0000000000000000 : ffffd0005dbad000 ffffd0005dba7000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: portcls!PcGetPhysicalDeviceObject+0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: portcls

IMAGE_NAME: portcls.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 559f3a45

STACK_COMMAND: .cxr 0xffffd0005dbabbf0 ; kb

BUCKET_ID_FUNC_OFFSET: 0

FAILURE_BUCKET_ID: AV_portcls!PcGetPhysicalDeviceObject

BUCKET_ID: AV_portcls!PcGetPhysicalDeviceObject

PRIMARY_PROBLEM_CLASS: AV_portcls!PcGetPhysicalDeviceObject

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:av_portcls!pcgetphysicaldeviceobject

FAILURE_ID_HASH: {4876d867-80a6-e48d-f660-fef38180e433}

Followup: MachineOwner

What i can’t figure out is why AddStreamResource function is calling PcGetPhysicalDeviceObject, when i already used this function , retrieved the PDO and passed it to AddStreamResource.

xxxxx@gmail.com wrote:

I am working on an audio miniport driver for Windows 10. During the initalization of the driver in StartDevice() function i am providing the driver owned resources to Windows by calling AddStreamResource() function after retrieving IID_IPortClsStreamResourceManager interface.

I am providing all the resources in the PCSTREAMRESOURCE_DESCRIPTOR properly. But i am seeing a crash with Access violation. Below is the code.

PCSTREAMRESOURCE_DESCRIPTOR Streamresource;
PCSTREAMRESOURCE hRes = NULL;
PDEVICE_OBJECT pdo = NULL;

//m_pDeviceObject is a device FDO.
PcGetPhysicalDeviceObject(m_pDeviceObject, &pdo);
ASSERT(pdo != NULL);

The dump says that m_pDeviceObject is NULL. Where did it come from?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Tim,

This member was passed to this function from StartDevice function. However
I couldn’t understand two points.

  1. I am calling PcGetPhysicalDeviceObject once before calling
    AddStreamResource. And then the tPstack trace in the crash dump shows that
    AddStreamResource is calling PcGetPhysicalDeviceObject once again. If the
    crash is because of PcGetPhysicalDeviceObject, then the earlier invocation
    of PcGetPhysicalDeviceObject should not have passed either because i am
    passing m_pDeviceObject to that as well.i.e. the below code itself
    should’ve crashed.

PcGetPhysicalDeviceObject(m_pDeviceObject, &pdo); - *// If m_pDeviceObject
is NULL, then this function should’ve crashed before addstreamresrouce*
ASSERT(pdo != NULL);
PCSTREAMRESOURCE_DESCRIPTOR_INIT(&Streamresource);
Streamresource.Pdo = pdo;
Streamresource.Type = ePcStreamResourceThread;
Streamresource.Resource.Thread = (PETHREAD )m_Thread;
ntStatus = m_pPortClsStreamResourceManager->AddStreamResource(
NULL, &Streamresource, &hRes); *// Why does this
function call PcGetPhysicalDeviceObject once again? Also from where *
*
does function get m_pDeviceObject in this case?*
.
Is it possible that m_pDeviceObject was proper while the driver is calling
PcGetPhysicalDeviceObject, and it has become NULL by the time
AddStreamResource was called?

  1. Why is the function AddStreamResource calling PcGetPhysicalDeviceObject
    again? After all i am passing the PDO as one of the parameters to
    AddStreamResource. Is it expected behavior ?

J.S.R.Sarma.
9916109893.

On Thu, Oct 1, 2015 at 11:38 PM, Tim Roberts wrote:

> xxxxx@gmail.com wrote:
> > I am working on an audio miniport driver for Windows 10. During the
> initalization of the driver in StartDevice() function i am providing the
> driver owned resources to Windows by calling AddStreamResource() function
> after retrieving IID_IPortClsStreamResourceManager interface.
> >
> > I am providing all the resources in the PCSTREAMRESOURCE_DESCRIPTOR
> properly. But i am seeing a crash with Access violation. Below is the code.
> >
> > PCSTREAMRESOURCE_DESCRIPTOR Streamresource;
> > PCSTREAMRESOURCE hRes = NULL;
> > PDEVICE_OBJECT pdo = NULL;
> >
> > //m_pDeviceObject is a device FDO.
> > PcGetPhysicalDeviceObject(m_pDeviceObject, &pdo);
> > ASSERT(pdo != NULL);
>
> The dump says that m_pDeviceObject is NULL. Where did it come from?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

jayanth sharma wrote:

This member was passed to this function from StartDevice function.
However I couldn’t understand two points.

  1. I am calling PcGetPhysicalDeviceObject once before calling
    AddStreamResource. And then the tPstack trace in the crash dump shows
    that AddStreamResource is calling PcGetPhysicalDeviceObject once
    again. If the crash is because of PcGetPhysicalDeviceObject, then the
    earlier invocation of PcGetPhysicalDeviceObject should not have passed
    either because i am passing m_pDeviceObject to that as well.i.e. the
    below code itself should’ve crashed.

My apologies. I didn’t read your stack trace closely enough, so I
assumed it was YOUR call to PcGetPhysicalDeviceObject that was failing.
I see now that was wrong.

*// Why does this function call PcGetPhysicalDeviceObject once again?
Also from where **
*
*
does function get m_pDeviceObject in this case?*
.
Is it possible that m_pDeviceObject was proper while the driver is
calling PcGetPhysicalDeviceObject, and it has become NULL by the time
AddStreamResource was called?

It doesn’t use your m_pDeviceObject. It has its own.

  1. Why is the function AddStreamResource calling
    PcGetPhysicalDeviceObject again? After all i am passing the PDO as one
    of the parameters to AddStreamResource. Is it expected behavior ?

If you disassemble that function, you’ll see that AddStreamResource
doesn’t use the PDO from the structure. Instead, it fetches a device
object from its own context structure within portcls.sys, and passes
that to PcGetPhysicalDeviceObject. It then hands the returned PDO to
PcAddStreamResource.

I don’t know where its internal device object comes from. I’m guessing
IPort::Init. Did you pass the correct DeviceObject there?


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I will check there. But i think i am passing a correct device object to
Init because that part of code has not been changed since very long.

I am planning thinking to run this code on Windows 8 and see if it runs. If
it runs smoothly perhaps the code needs to be changed suitably for Windows
10.

BTW, I didn’t dissemble the function AddStreamResource yet, but if it
doesn’t take the PDO that i am passing via the structure, then i am curious
, why to pass that object at all?

J.S.R.Sarma.
9916109893.

On Fri, Oct 2, 2015 at 11:47 PM, Tim Roberts wrote:

> jayanth sharma wrote:
> >
> > This member was passed to this function from StartDevice function.
> > However I couldn’t understand two points.
> >
> > 1. I am calling PcGetPhysicalDeviceObject once before calling
> > AddStreamResource. And then the tPstack trace in the crash dump shows
> > that AddStreamResource is calling PcGetPhysicalDeviceObject once
> > again. If the crash is because of PcGetPhysicalDeviceObject, then the
> > earlier invocation of PcGetPhysicalDeviceObject should not have passed
> > either because i am passing m_pDeviceObject to that as well.i.e. the
> > below code itself should’ve crashed.
>
> My apologies. I didn’t read your stack trace closely enough, so I
> assumed it was YOUR call to PcGetPhysicalDeviceObject that was failing.
> I see now that was wrong.
>
>
> > *// Why does this function call PcGetPhysicalDeviceObject once again?
> > Also from where **
> > *
> >
> > does function get m_pDeviceObject in this case?

> > .
> > Is it possible that m_pDeviceObject was proper while the driver is
> > calling PcGetPhysicalDeviceObject, and it has become NULL by the time
> > AddStreamResource was called?
>
> It doesn’t use your m_pDeviceObject. It has its own.
>
>
> > 2. Why is the function AddStreamResource calling
> > PcGetPhysicalDeviceObject again? After all i am passing the PDO as one
> > of the parameters to AddStreamResource. Is it expected behavior ?
>
> If you disassemble that function, you’ll see that AddStreamResource
> doesn’t use the PDO from the structure. Instead, it fetches a device
> object from its own context structure within portcls.sys, and passes
> that to PcGetPhysicalDeviceObject. It then hands the returned PDO to
> PcAddStreamResource.
>
> I don’t know where its internal device object comes from. I’m guessing
> IPort::Init. Did you pass the correct DeviceObject there?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

I don’t know where its internal device object comes from. I’m guessing
IPort::Init. Did you pass the correct DeviceObject there?

Regarding the point of from where the second device object is being
retrieved by the system,
I am creating a thread using PsCreateSystemThread earlier to calling
AddStreamResource and retrieving the corresponding KTHREAD object by using
ObReferenceObjectByHandle. I am passing this thread object t o the
resource_descriptor structure, after type casting it to ETHREAD object.

Is it possible that system is trying to retrieve the device object from
this m_Thread object somehow and failing because of some parameters passed
to this call? If there is such possibility, then I will look into the
PsCreateSystemThread call and it’s parameters.

Also I will try to pass interrupt as a resource, Instead of a thread object
to the resource descriptor structure and see if AddStreamResource() call
passes. However the resource descriptor structure expects KINTERRUPT object
but in my driver an INTERRUPTSyNC object is being created. I am new to this
object. How to retrieve the corresponding KINTERRUPT object from
INTERRUPTSYNC object? Can I call GetKInterrupt() method on this object to
get it?

On Sat, 3 Oct 2015 at 08:16 jayanth sharma wrote:

> I will check there. But i think i am passing a correct device object to
> Init because that part of code has not been changed since very long.
>
> I am planning thinking to run this code on Windows 8 and see if it runs.
> If it runs smoothly perhaps the code needs to be changed suitably for
> Windows 10.
>
>
> BTW, I didn’t dissemble the function AddStreamResource yet, but if it
> doesn’t take the PDO that i am passing via the structure, then i am curious
> , why to pass that object at all?
>
>
>
>
> J.S.R.Sarma.
> 9916109893.
>
> On Fri, Oct 2, 2015 at 11:47 PM, Tim Roberts wrote:
>
>> jayanth sharma wrote:
>> >
>> > This member was passed to this function from StartDevice function.
>> > However I couldn’t understand two points.
>> >
>> > 1. I am calling PcGetPhysicalDeviceObject once before calling
>> > AddStreamResource. And then the tPstack trace in the crash dump shows
>> > that AddStreamResource is calling PcGetPhysicalDeviceObject once
>> > again. If the crash is because of PcGetPhysicalDeviceObject, then the
>> > earlier invocation of PcGetPhysicalDeviceObject should not have passed
>> > either because i am passing m_pDeviceObject to that as well.i.e. the
>> > below code itself should’ve crashed.
>>
>> My apologies. I didn’t read your stack trace closely enough, so I
>> assumed it was YOUR call to PcGetPhysicalDeviceObject that was failing.
>> I see now that was wrong.
>>
>>
>> > *// Why does this function call PcGetPhysicalDeviceObject once again?
>> > Also from where **
>> > *
>> >
>> > does function get m_pDeviceObject in this case?

>> > .
>> > Is it possible that m_pDeviceObject was proper while the driver is
>> > calling PcGetPhysicalDeviceObject, and it has become NULL by the time
>> > AddStreamResource was called?
>>
>> It doesn’t use your m_pDeviceObject. It has its own.
>>
>>
>> > 2. Why is the function AddStreamResource calling
>> > PcGetPhysicalDeviceObject again? After all i am passing the PDO as one
>> > of the parameters to AddStreamResource. Is it expected behavior ?
>>
>> If you disassemble that function, you’ll see that AddStreamResource
>> doesn’t use the PDO from the structure. Instead, it fetches a device
>> object from its own context structure within portcls.sys, and passes
>> that to PcGetPhysicalDeviceObject. It then hands the returned PDO to
>> PcAddStreamResource.
>>
>> I don’t know where its internal device object comes from. I’m guessing
>> IPort::Init. Did you pass the correct DeviceObject there?
>>
>> –
>> Tim Roberts, xxxxx@probo.com
>> Providenza & Boekelheide, Inc.
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>

If you want to trace at passing a variable from your driver to kernel components but hard to locate the entry point, combine use VM snapshot with memory breakpoint may help to monitor internal objects usage.

hmm…any more clues on this?

J.S.R.Sarma.
9916109893.

On Sun, Oct 4, 2015 at 4:54 PM, wrote:

> If you want to trace at passing a variable from your driver to kernel
> components but hard to locate the entry point, combine use VM snapshot with
> memory breakpoint may help to monitor internal objects usage.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

jayanth sharma wrote:

I will check there. But i think i am passing a correct device object
to Init because that part of code has not been changed since very long.

I am planning thinking to run this code on Windows 8 and see if it
runs. If it runs smoothly perhaps the code needs to be changed
suitably for Windows 10.

BTW, I didn’t dissemble the function AddStreamResource yet, but if it
doesn’t take the PDO that i am passing via the structure, then i am
curious , why to pass that object at all?

IPortClsStreamResourceManager::AddStreamResource does one or two lookups
and then passes control to PcAddStreamResource. Perhaps it uses the PDO
member.

Or maybe it was designed by committee.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

jayanth sharma wrote:

Regarding the point of from where the second device object is being
retrieved by the system, I am creating a thread using
PsCreateSystemThread earlier to calling AddStreamResource and
retrieving the corresponding KTHREAD object by using
ObReferenceObjectByHandle. I am passing this thread object to the
resource_descriptor structure, after type casting it to ETHREAD object.

Have you taken care to distinguish between ETHREAD and PETHREAD, and
KTHREAD and PETHREAD? It’s easy to miss a level of indirection in those
types. I don’t think that would affect this, however. Did you
double-check IPort::Init?

Is it possible that system is trying to retrieve the device object
from this m_Thread object somehow and failing because of some
parameters passed to this call? If there is such possibility, then I
will look into the PsCreateSystemThread call and it’s parameters.

No. It’s getting it from a member variable in the object that
implements IPortClsStreamResourceManager. Thread structures don’t have
device objects in them.

Also I will try to pass interrupt as a resource, Instead of a thread
object to the resource descriptor structure and see if
AddStreamResource() call passes.

The object type is irrelevant. The crash is happening in the COM
wrapper, long before it ever looks into the structure itself.

However the resource descriptor structure expects KINTERRUPT object
but in my driver an INTERRUPTSyNC object is being created. I am new to
this object. How to retrieve the corresponding KINTERRUPT object from
INTERRUPTSYNC object? Can I call GetKInterrupt() method on this object
to get it?

Yes. Actually, you get a PKINTERRUPT, but that’s what you want, anyway.

The whole AddStreamSource concept is brand-new. What led you to think
you needed it at all?

You might consider asking your question on the [wdmaudiodev] mailing
list. Some of the Microsoft audio team hangs out there, and they might
be aware of implementation issues in this new class that aren’t known to
the general public.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

*Have you taken care to distinguish between ETHREAD and PETHREAD,
andKTHREAD and PETHREAD? It’s easy to miss a level of indirection in
thosetypes. I don’t think that would affect this, however. Did
youdouble-check IPort::Init?*

Yes. I double checked both of them. They are fine.

*The whole AddStreamSource concept is brand-new. What led you to think**you
needed it at all?*

I am working on porting an existing driver to Windows 10. As a part of
this, i want to use the low latency audio feature of Windows 10.
I have a couple of questions.

  1. In the RESOURCE_DESCRIPTOR structure, there is a member *ResourceSet*.
    MSDN asks us to keep it NULL and “says only device scoped resources are
    supported at this time”. Below is the link.

https://msdn.microsoft.com/en-us/library/windows/hardware/mt298191(v=vs.85).aspx

Does “device scoped resources” mean only the resources created by my driver
and not the resources of other audio stacks?

  1. PcAddStreamResource function lets us register only one resource at a
    time. If i want to register multiple resources in my driver, (multiple
    threads, interrupt objects, etc), I will have to call this function
    multiple times once for each resource?

I will try mailing these queries in [wdmaudiodev] as well.

J.S.R.Sarma.
9916109893.

On Tue, Oct 6, 2015 at 12:30 AM, Tim Roberts wrote:

> jayanth sharma wrote:
> > Regarding the point of from where the second device object is being
> > retrieved by the system, I am creating a thread using
> > PsCreateSystemThread earlier to calling AddStreamResource and
> > retrieving the corresponding KTHREAD object by using
> > ObReferenceObjectByHandle. I am passing this thread object to the
> > resource_descriptor structure, after type casting it to ETHREAD object.
>
> Have you taken care to distinguish between ETHREAD and PETHREAD, and
> KTHREAD and PETHREAD? It’s easy to miss a level of indirection in those
> types. I don’t think that would affect this, however. Did you
> double-check IPort::Init?
>
>
> > Is it possible that system is trying to retrieve the device object
> > from this m_Thread object somehow and failing because of some
> > parameters passed to this call? If there is such possibility, then I
> > will look into the PsCreateSystemThread call and it’s parameters.
>
> No. It’s getting it from a member variable in the object that
> implements IPortClsStreamResourceManager. Thread structures don’t have
> device objects in them.
>
>
> > Also I will try to pass interrupt as a resource, Instead of a thread
> > object to the resource descriptor structure and see if
> > AddStreamResource() call passes.
>
> The object type is irrelevant. The crash is happening in the COM
> wrapper, long before it ever looks into the structure itself.
>
>
> > However the resource descriptor structure expects KINTERRUPT object
> > but in my driver an INTERRUPTSyNC object is being created. I am new to
> > this object. How to retrieve the corresponding KINTERRUPT object from
> > INTERRUPTSYNC object? Can I call GetKInterrupt() method on this object
> > to get it?
>
> Yes. Actually, you get a PKINTERRUPT, but that’s what you want, anyway.
>
> The whole AddStreamSource concept is brand-new. What led you to think
> you needed it at all?
>
> You might consider asking your question on the [wdmaudiodev] mailing
> list. Some of the Microsoft audio team hangs out there, and they might
> be aware of implementation issues in this new class that aren’t known to
> the general public.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

jayanth sharma wrote:

  1. In the RESOURCE_DESCRIPTOR structure, there is a member
    *ResourceSet*. MSDN asks us to keep it NULL and “says only device
    scoped resources are supported at this time”. Below is the link.

https://msdn.microsoft.com/en-us/library/windows/hardware/mt298191(v=vs.85).aspx
https:
>
> Does “device scoped resources” mean only the resources created by my
> driver and not the resources of other audio stacks?

I don’t think anyone outside of Microsoft knows the answer to that.
It’s speculating about a “reserved” parameter in a brand new API.

> 2. PcAddStreamResource function lets us register only one resource at
> a time. If i want to register multiple resources in my driver,
> (multiple threads, interrupt objects, etc), I will have to call this
> function multiple times once for each resource?

Yes. There can’t be all that many. It’s not really clear to me what
you gain by “registering” the resource anyway, but that’s the skeptic in
me coming out.

> I will try mailing these queries in [wdmaudiodev] as well.

That’s really the right answer.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</https:>