when does a PDO become a PDO ?

Discussion in 'Windows Vista Drivers' started by shahar, Aug 8, 2004.

  1. shahar

    shahar Guest

    I am writing a bus filter and I would like to call functions like:
    IoGetDeviceProperty, IoQueryDevicePnpState and IoRequestDeviceEject
    on pdo's that my filter sees in IRP_MN_QUERY_DEVICE_RELATIONS queries that
    are sent to the bus I'm filtering.
    The problem is that I attach to the bus long after it is started and I can't
    know if this is the first time that the pdo is reported or if it was reported
    a long time ago and maybe even started already.
    Calling any of the functions I mentioned on a PDO that was not reported to
    the pnp manager yet will generate a bugcheck.
    My questions is: How can I know if the pnp manager already knows about the
    PDO ? when exactly is it alright to call those functions with the pdo ?
    I will also be very glad if someone can explain why do those functions
    bugcheck when using an uninitialized pdo instead of just returning with a
    failed status.

    Thank you,
    shahar, Aug 8, 2004
    1. Advertisements

  2. My questions is: How can I know if the pnp manager already knows about the
    PDOs are only the devices reported in MN_QUERY_DEVICE_RELATIONS/BusRelations
    Maxim S. Shatskih, Aug 8, 2004
    1. Advertisements

  3. shahar

    Mark Roddy Guest

    Attaching to the bus FDO 'long after it started' is a design flaw you ought
    to fix. Make your inquiries when you see a start device for the PDO in
    question, as that will guarantee that the PDO is in fact a PDO.

    I have no idea why Microsoft bugchecks on an invalid PDO rather than
    returning an error. I suppose it is a gentle warning that you are doing
    things the wrong way :)


    Mark Roddy
    Windows 2003/XP/2000 Consulting
    Hollis Technology Solutions 603-321-1032
    Mark Roddy, Aug 8, 2004
  4. shahar

    shahar Guest

    My product is attaching to a very specific type of bus. I only attach to the
    device stack after I am informed by a pnp notification I registered
    (IoRegisterPnpNotification) for a device interface that this specific bus
    registers. Since I will be notified only after the device completes it's
    IRP_MN_START_DEVICE, it is not possible for me to be there before that, thus
    I am forced to do things this way.

    Is there another way to check if the pnp knows about the PDO ?
    shahar, Aug 9, 2004
  5. shahar

    Mark Roddy Guest

    Comments inline.


    Mark Roddy
    Windows 2003/XP/2000 Consulting
    Hollis Technology Solutions 603-321-1032

    Like I said, this is the wrong approach. You have designed yourself into a
    corner here.
    Not that I know of. Go back and rethink how you are attaching to the bus
    driver FDO.
    Mark Roddy, Aug 9, 2004
  6. shahar

    shahar Guest

    Even if I will find a sollution for attaching to the device stack before it
    starts I will still have to deal with a scenario where the device stack is
    already started because this will surely be the case when my product is first
    installed on a computer (I do not want to force a restart when my product is

    Are you saying that there is no safe way to install a bus filter on a
    running system ?
    shahar, Aug 9, 2004
  7. Are you saying that there is no safe way to install a bus filter on a
    running system ?

    It depends on whether the device can be stopped (query-removed) at runtime
    and restarted. In order to insert the filter, the device stack has to be
    torn down and rebuilt. If the device cannot be stopped at runtime then setup
    the registry and reboot the system so that the filter gets loaded as part of
    the bus driver function stack.

    This posting is provided "AS IS" with no warranties, and confers no rights.
    Eliyas Yakub [MSFT], Aug 9, 2004
  8. My guess is that you are planning to use IoAttachDevice to attach to the bus
    fdo. This is a deprecated function for PNP drivers. How would you make sure
    there are no open handles to the device when you are attaching?
    Eliyas Yakub [MSFT], Aug 9, 2004
  9. shahar

    Mark Roddy Guest

    Like I said, and as you are now also hearing from other quarters: you have
    designed yourself into a corner. If the stack cannot be stopped then you
    cannot reliably insert or remove a filter. Those are the current
    constraints. Stopping or rebooting is currently the only reliable solution.


    Mark Roddy
    Windows 2003/XP/2000 Consulting
    Hollis Technology Solutions 603-321-1032
    Mark Roddy, Aug 10, 2004
  10. Variants:

    - register yourself for a device ID generated by the bus driver of a "special"
    - otherwise, use PnP notification, it will work fine in all cases.
    Maxim S. Shatskih, Aug 10, 2004
  11. PnP interface arrival notification handles this automatically.
    Maxim S. Shatskih, Aug 10, 2004
  12. shahar

    shahar Guest

    I am using IoAttachDeviceToDeviceStack. Why did you think I would use the
    deprecated function ? What if there are open handles to the device ?
    shahar, Aug 10, 2004
  13. shahar

    shahar Guest

    I still do not understand why I cannot attach to a running stack:
    I get a device name in the pnp notification, I get the device object using
    IoGetDeviceObjectPointer, and I attach to the device stack using
    IoAttachDeviceToDeviceStack. What is wrong with that ?
    I already implemented all of this and it all works perfectly under any
    scenario I tested. My only problem is with calling IoGetDeviceProperty on
    child PDO's of the bus. Calling IoGetDeviceProperty doesn't even cause any
    problem, I just get STATUS_INVALID_DEVICE_REQUEST when calling it with a PDO
    for a device that the PNP Manager never heard about, the only problem is that
    the Driver Verifier bug checks on it.
    shahar, Aug 10, 2004
  14. You do not know what IRPs are in progress in the stack, for instance.
    Maxim S. Shatskih, Aug 10, 2004
  15. shahar

    shahar Guest

    why should I care what IRP's are in progress ? There should be no problem for
    any driver to complete the IRP, any completion routines that were registered
    will be called, it is not my bussiness. New IRP's will first go through my
    driver and any IRP's that were in progress will be completed without
    involving me.
    As I wrote before, I already wrote this driver and it works fine.
    shahar, Aug 10, 2004
  16. Just because your current implementation works doesn't mean it's correct.
    How do you know those new IRPs that go thru your driver has enough stacks
    locations? Another driver could have preallocated IRPs based on the stack
    size of the top level deviceobject of your stack and it could assume that
    value to be static. If you sneak in a filter without informing anybody, you
    will end up crashing the system if that driver tries to send the IRP to the
    top of the stack that it found at runtime. You could argue that the driver
    that preallocated the IRPs should have used the same device object for
    sending the IRP that it used for creating the IRPs. But that's not the
    reality. We all make assumptions based on what we observe. I'm sure there
    are other issues in sneaking filter that I don't know of.
    Eliyas Yakub [MSFT], Aug 10, 2004
  17. shahar

    Max Paklin Guest

    Say, my driver needs to send an IRP to your stack once in a while. I might
    decide to allocate IRP once and reuse it for subsequent calls. Now if you
    added another driver to the stack and I don't know about it the stack size
    of my IRP is insufficient. Next time when I send my IRP to the stack the OS
    will crash.

    -- Max.
    Max Paklin, Aug 10, 2004
  18. I can't imagine your customers would have been consoled by the fact that
    they could install your driver without rebooting the system if it just
    crashed moments later with a NO_MORE_IRP_STACK_LOCATIONS bugcheck.

    You can always point out to them that it ran fine in all the scenarios you
    came up with, and that's why you thought it would be fine to attach after
    start despite the number of experienced developers who suggested that you
    follow the normal bus filter design.

    Peter Wieland [MSFT], Aug 10, 2004
  19. shahar

    shahar Guest

    You are completely right, releasing a product that might bug check is totally
    unacceptable, there is no argue here.
    You guys suggestions are great, and I don't know how I could have managed
    without them.
    Still, I am motivated to find a way to attach to a started device stack that
    will not put me in risk of a bug check.
    The issue raised here (that a NO_MORE_IRP_STACK_LOCATIONS bug check might
    happen) is very important and it cannot be ignored, but I want to try and
    think of a way to prevent this bug check.
    My suggestion from the last post was to detect somehow in my dispatch
    function that the number of stack locations available in the IRP is smaller
    than the size of the device stack and in this case to prevent the bug check
    in one of three ways:
    1) Calling IoSkipCurrentIrpStackLocation. This way I will not use my stack
    location and the IRP will go down the stack and complete as if I was never
    there. This is a bit problematic for me because I don't like the idea of not
    setting a completion routine when I need to (I am writing a security product,
    and this will be a big security hole).
    2) Allocating a new IRP with a big enough stack, copying the parameters from
    my stack location to the first stack location of the new IRP and sending the
    new IRP to the next device in the device stack (just like a PDO delegates an
    IRP to it's parent FDO).
    3) This is the most ugly one I think, I don't know if it's even allowed -
    Saving the completion routine and context defined in the current stack
    location in a variable, overwriting the current stack location with my
    completion routine and context, and having the saved completion routine
    called myself when my completion routine is called.

    The second option seems like the best one for me, what do you think ? Is it
    possible/legal ?
    One question remains - How do I detect that there are not going to be enough
    stack locations for the rest of the drivers down the stack ?
    I have no problem to figure out how many stack locations are needed, I get
    this from the StackSize memeber in the device object,
    but how do I know how many stack locations are allocated for the IRP ?
    I remember from the documentation that IoForwardIrpSynchronously() returns
    FALSE if there is not enough place to copy the current irp stack location to
    the next location.
    How does this function knows that it cannot copy the stack location ?

    I am sorry that I have to be a nag here and try to find a solution when you
    suggest to give up the installation without reboot, but this is a very
    important requirement for my product and I want to be sure that it cannot be

    Are there any other problems that might happen when attaching to a started
    device stack except for the NOT_ENOUGH_IRP_STACK_LOCATIONS bug check ?

    Thanks a lot for you advice and suggestions.
    shahar, Aug 11, 2004
  20. shahar

    Mark Roddy Guest

    Shahar has exercised the Rule of Three, as in 'three strikes - you're out'.
    He's heard the same answer at least three times from at least three
    different sources, some of them inside Microsoft, some of them outside, all
    of them at least mildly credible, and he insists on plunging off this abyss
    of his own creation. Have a nice trip, I sure hope I never use your product.


    Mark Roddy
    Windows 2003/XP/2000 Consulting
    Hollis Technology Solutions 603-321-1032
    Mark Roddy, Aug 11, 2004
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.