none
(WHCK) PNP_* tests failures on STATUS_INSUFFICIENT_RESOURCES RRS feed

  • Question

  • I have a bus driver which his child open an IOTarget to his parent as part of his loading process.

    The parent saves its connections in a wdfcollection.

    When the test open more than 256 handles the wdfcollectionAdd fails with  STATUS_INSUFFICIENT_RESOURCES what cause to the IOTarget opening to fails. as a result the child device will be with yellow bang.

    The test have a filter on STATUS_INSUFFICIENT_RESOURCES, and when he try to open a handle to the parent driver and fails with STATUS_INSUFFICIENT_RESOURCES the test pass, but when the child is yellow bang and the test try to open a handle to the child that test fails.(Even so this is an expected behavior from the test).

    I'm wondering what wrong here, My driver behavior or WHCK test? How can I solve the issue?

    Thanks a lot

    C.S

    Tuesday, May 26, 2015 11:27 AM

All replies

  • I would first see if you have a memory leak in this path, perhaps wdf objects being leaked that only clean up when the driver unloads. Which hck tests are run?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Tuesday, May 26, 2015 2:18 PM
  • Thanks for your quick reply.

    First of all I found that my description was wrong I don’t get the STATUS_INSUFFICIENT_RESOURCES from the WDFCollectionAdd API, I get it because my driver support maximum of 255 handles by definition.

    I see the issue in multiple tests, one of them is  "PNP Remove Device Test"

    I don't think that this is a memory leak because I know for sure that someone opened 255 handles to my driver (I guess that the test do it), I see for sure that when the handles were closed before my child loading the test doesn't fail.

    The issue always occur when my child try to open an IOTarget to the parent after that 255 handles were already used.

    The Parent Driver (Which the WHCK is running on) log is:

    --> EvtDeviceFileCreate Entry

    --> ClientsAllocateHostClientId Entry

    ClientsAllocateHostClientId: WdfCollectionAdd 1

    HostCientID: 1

    <-- ClientsAllocateHostClientId Exit with STATUS_SUCCESS

    <-- EvtDeviceFileCreate Exit with STATUS_SUCCESS

    --> EvtDeviceFileCreate Entry

    --> ClientsAllocateHostClientId Entry

    ClientsAllocateHostClientId: WdfCollectionAdd 2

    HostCientID: 2

    <-- ClientsAllocateHostClientId Exit with STATUS_SUCCESS

    <-- EvtDeviceFileCreate Exit with STATUS_SUCCESS

    --> EvtDeviceFileCreate Entry

    --> ClientsAllocateHostClientId Entry

    ClientsAllocateHostClientId: WdfCollectionAdd 255

    HostCientID: 255

    <-- ClientsAllocateHostClientId Exit with STATUS_SUCCESS

    <-- EvtDeviceFileCreate Exit with STATUS_SUCCESS

    <-- EvtDeviceFileCreate Exit with STATUS_SUCCESS

    --> EvtDeviceFileCreate Entry

    --> ClientsAllocateHostClientId Entry

    <-- ClientsAllocateHostClientId Exit with 0xc000009a(STATUS_INSUFFICIENT_RESOURCES)

    <-- EvtDeviceFileCreate Exit with 0xc000009a(STATUS_INSUFFICIENT_RESOURCES)

    This is expected behavior so I can’t understand why the test fails. Isn’t it acceptable behavior? Maybe I have a problem with my architecture?

    Thanks

    Tuesday, May 26, 2015 7:04 PM
  • Some questions to clarify things -

    What exactly is the cause of the test failure you mentioned, ie. what does the test log say? Is it because the child device is in a failed state (since it couldn't open the target device)?

    Have you verified that you maintain the count of open handles properly by decrementing it in EvtFileCleanup/EvtFileClose and that it is indeed the test driver that is opening that many handles to your device?

    Thursday, May 28, 2015 1:28 AM