none
Weird Bus Driver Behavior RRS feed

  • Question

  • Hi

    I have a driver that I added bus driver functionally based on the toaster sample. Usually everything is working fine, my child devices are exposed (PDO is created) on Win8.1, but sometime on Shutdown flows, the child devices are not exposed (PDO is not created).

    According my logs it seem like the driver is calling the right functions (like in a working flow logs), in my init flow, in the  DPC I’m getting the list of the child devices and I do the following (PedusoCode):

    WdfChildListBeginScan(WdfFdoGetDefaultChildList(DeviceContext->device));
    
    count = WdfCollectionGetCount(DeviceContext->BusChildWhiteList);
    
    
    for
    (i = 0; i<count; ++i)
    {
        childObj = WdfCollectionGetItem(DeviceContext->AllowedDevices, i);
    
      if (isChildDeviceExist(DeviceContext, childObj))
      {
       [...]
       status = WdfChildListAddOrUpdateChildDescriptionAsPresent(.....) // Error Handing...
      }
    
    }
    
    
    
                    WdfChildListEndScan(WdfFdoGetDefaultChildList(DeviceContext->device));|
    
    
    
    

    Now when the issue occur I see the following in WinDbg:

    0: kd> !wdfchildlist 0x00001ffffef7f4b8

    Treating handle as a KMDF handle!

    Dumping WDFCHILDLIST 0x00001ffffef7f4b8

    ---------------------------------------

    Owning !wdfdevice 0x00001ffffef225a8

    ID description size 0x18

    State:

    -----

    List is unlocked, changes will be applied immediately

    Currently in the middle of a scan or enumeration (1 total),

     *** all changes pended all are complete ***

    No child descriptions in the list.

    Pending insertions:

    ------------------

    ID description 0xffffe000007eedd8

     +Description found in last scan

    It seem like the WdfChildListEndScan() Function was not called, but I don’t understand how it is possible.

    Also I don’t see issue in the WDF Log:

    24: FxPowerIdleMachine::ProcessEventLocked - WDFDEVICE 0x00001FFFFEF225A8 !devobj 0xFFFFE00001080940 entering power idle state FxIdleDisabled from FxIdleDisabled

    25: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFFEF225A8 !devobj 0xFFFFE00001080940 entering PnP State WdfDevStatePnpEnableInterfaces from WdfDevStatePnpHardwareAvailable

    26: FxPkgPnp::PnpEnterNewState - WDFDEVICE 0x00001FFFFEF225A8 !devobj 0xFFFFE00001080940 entering PnP State WdfDevStatePnpStarted from WdfDevStatePnpEnableInterfaces

    27: FxPkgPnp::Dispatch - WDFDEVICE 0x00001FFFFEF225A8 !devobj 0xFFFFE00001080940, IRP_MJ_PNP, 0x00000014(IRP_MN_QUERY_PNP_DEVICE_STATE) IRP 0xFFFFE000012CEE10

    28: FxPkgFdo::HandleQueryPnpDeviceStateCompletion - WDFDEVICE 0x00001FFFFEF225A8 !devobj 0xFFFFE00001080940 returning PNP_DEVICE_STATE 0x0 IRP 0xFFFFE000012CEE10

    29: FxPkgPnp::Dispatch - WDFDEVICE 0x00001FFFFEF225A8 !devobj 0xFFFFE00001080940, IRP_MJ_PNP, 0x00000007(IRP_MN_QUERY_DEVICE_RELATIONS) type BusRelations IRP 0xFFFFE00000FE47B0

    ---- end of log ----

    Any suggestion what can be the cause of this issue?

    2nd question

    According to MSDN, the driver must call WdfDeviceSetBusInformationForChildren(), but according to the toaster sample it is optional. Does driver need to call it or not?


    Wednesday, January 29, 2014 6:20 PM

Answers

  • issue solved:
    there was additional calls in the DPC to BeginScan() and EndScan()
    that cause the device to disappear


    Thanks for the support.

    • Marked as answer by Baget Sunday, February 2, 2014 9:40 AM
    Sunday, February 2, 2014 9:40 AM

All replies

  • I would suggest you investigate further first.

    There is a tool in the WDK called WdfVerifier (that's a link to its documentation).  Find your driver on the WDF Drivers tab, right click it and select the option "All recommended verification features are enabled" on the menu that pops up.  Then click OK or use Enter key.  If your driver was loaded, the tool will then ask if it should disable and re-enable the devices using it- you can choose what you want to do about that.  If it wasn't loaded, the settings will take effect next time you load it.

    Then try this scenario again.  If a framework rule was violated, you will get a break or bugcheck.  If there were no violations, the driver log (which was increased in size by that selection) has much more information in it about what went on (it will have entries when you begin and end scan, and update the descriptions, for instance- and also report what it does in the bus relations query).

    Between those, you (and WDF team, should this somehow be our problem) will have more usable information for resolving this problem.

    You can turn all those settings off when you're done by loading the tool, right clicking your driver and selecting "Set to Default Settings", then pressing OK or using the Enter key.

    For your second question, I would recommend you call that DDI, but I've observed that bus drivers usually work even when you don't.  For one thing, a lot of the impact can come from drivers loaded on your bus driver's PDOs, and I don't know what those are.  So best to be safe and call it- if it's unique, create a GUID for it, use that for the bus type GUID and call it a PnpBus for its type.

    Thursday, January 30, 2014 12:29 AM
  • it seem like the WdfVerifier causing a timing issue, which make the issue disappear.
    also I think that if there was an issue that the verifier will find, I would see it in the WDF Framework Logs, no?
    Thursday, January 30, 2014 3:30 PM
  • "I think that if there was an issue that the verifier will find, I would see it in the WDF Framework Logs, no?"

    Not always.  Many verifications are only performed when the verifier is turned on.

    The settings I requested also generate more trace information in the log than the default settings will.

    If there's a timing issue here, then using the verifier has simply exposed it as one, and that's also useful information.  It also seems odd it didn't surface before, because there's not much overhead in the verification or log code for this scenario.

    Could you please reply with the log from the session where it did not occur?

    Also, can you please clarify what you mean by "Shutdown flow"?

    Thursday, January 30, 2014 8:02 PM
  • issue solved:
    there was additional calls in the DPC to BeginScan() and EndScan()
    that cause the device to disappear


    Thanks for the support.

    • Marked as answer by Baget Sunday, February 2, 2014 9:40 AM
    Sunday, February 2, 2014 9:40 AM
  • Some followup for anyone viewing this thread:

    The settings I recommended above can help find problems of this sort- the verbose log output will show every call to beginscan and endscan, for instance- including nested count- and also show more detail on what gets reported back to pnp in the resulting bus queries.  I own multiple bus drivers and have helped debug others, and the log is very useful for problems of this nature.

    Also, I have reviewed more closely how bus information from WdfDeviceSetBusInformationForChildren is used, and we are changing the usage guidance on MSDN to reflect that- changes should go live in a couple of days from today.

    Specifically, it is not required- bus driver will work without it- but it makes it easier for child devices and apps to identify your bus- information you or they may find useful in the future.


    Thanks for raising that issue.
    Tuesday, February 4, 2014 10:33 PM