BDA (AVStream) minidriver for USB device: Initialization issue

I’m trying to develop a BDA compliant AVStream driver for a digital TV tuner USB device.
As of now I have a separate BDA minidriver and a USB client driver, and I’m trying to integrate the two into a single driver.
I had a couple of questions in this regard:

  1. I want to create my own FDO and attach to stack, since I’m using the device extension for my USB client driver context. This is what I’ve done to achieve the same:
    a. In DriverEntry call KSInitializeDriver with my device descriptor
    b. Overwrite AvStream’s AddDevice routine with my own
    c. In my AddDevice,
    i. Create my FDO
    ii. Initialize driver extension (for USB)
    iii. Attach to stack
    iv. Call KSInitializeDevice to create the AvStream device

What I have observed is that, my create dispatch (AVStrMiniDeviceAdd) registered in the device descriptor gets called as expected, once the AddDevice is done. Then my start dispatch gets called and I get an IRQL_NOT_LESS_OR_EQUAL bug check where I call BdaCreateFilterFactoryEx from my Start (AVStrMiniDeviceStart) Dispatch.

  1. If I don’t do a KsInitializeDriver as part of driver entry, other steps remaining the same, my Start dispatch is not called.

Given the above,

  1. Is there something I’m missing when providing my own AddDevice instead of AvStream’s default AddDevice handler (KSAddDevice)? In particular, is there something I need to do to initialize the KSDEVICE_HEADER? I’m unclear about where, as in which data structure, this belongs and who should be allocating and initializing it.

  2. I’m aware that if I’m relying on AVStream to create the device, I should not be using the device extension. However when I’m creating the FDO myself, isn’t the device extension available for my use?

xxxxx@gmail.com wrote:

I’m trying to develop a BDA compliant AVStream driver for a digital TV tuner USB device.
As of now I have a separate BDA minidriver and a USB client driver, and I’m trying to integrate the two into a single driver.

  1. I want to create my own FDO and attach to stack, since I’m using the device extension for my USB client driver context. This is what I’ve done to achieve the same:

    Given the above,
  1. Is there something I’m missing when providing my own AddDevice instead of AvStream’s default AddDevice handler (KSAddDevice)? In particular, is there something I need to do to initialize the KSDEVICE_HEADER? I’m unclear about where, as in which data structure, this belongs and who should be allocating and initializing it.

  2. I’m aware that if I’m relying on AVStream to create the device, I should not be using the device extension. However when I’m creating the FDO myself, isn’t the device extension available for my use?

You are fighting the tools here, swimming upstream, against the
current. AVStream filters and devices can both have context structures
(in KSDEVICE.Context and KSFILTER.Context). Your life will be much
easier if you simply move your device extension structure into the
context for the filter or device, as appropriate, and let AVStream
handle the AddDevice as usual.


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

c. In my AddDevice,
i. Create my FDO
ii. Initialize driver extension (for USB)
iii. Attach to stack
iv. Call KSInitializeDevice to create the AvStream device

the cause maybe at step i, AVstream has create a FDO and attach to stack for you, and send FDO to you by “NTSTATUS (*PFNKSDEVICECREATE)(IN PKSDEVICE Device);” input para “IN PKSDEVICE Device”, so you only need step ii to init context structures(in Tim’s mail), and about iv, please see wdk help below, you should call KsInitializeDriver driverentry and needn’t KSInitializeDevice.

Most minidrivers do not call this function directly. Only call KsInitializeDevice if your minidriver does not use KsInitializeDriver for initialization, handles AddDevice independently, and does not use KsAddDevice or KsCreateDevice in its AddDevice handler.

KsInitializeDevice must be called at IRQL = PASSIVE_LEVEL.

Ben
conexant china

2007-09-05

Tim,

I’d been trying exactly that, creating my device extention as part of KS device context. I’ve got it working now.

thanks,
-Lakshmi