none
Device fails to enumerate with CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD error. RRS feed

  • Question

  • A virtual USB Host Controller PDO is removed (IRP_MN_SURPRISE_REMOVAL) and its functional driver unloads, but apparently there is a device object with a reference count against it (the functional driver) and it never gets removed from memory.  I can see it under windbg when I list modules from a forced crashdump.  So when the bus enumerator of this PDO re-enumerates it, the device manager refuses to startup the functional driver because it didn't properly unload.  I don't know why the device manager even calls the functional driver's unload handler but that's another topic.  So the device node that I see for that PDO shows a new PDO 

    I suspect that there could be an open handle that references the PDO but I have no way of examining it since the only PDO I now see is the one from the re-enumeration.  Does anyone know if there's a way to backtrace the history of a stale (or perhaps better said, "deleted") device object?

    I am able to locate the driver object because the driver actually saves its driver object pointer in memory.  But when I dump the driver object there are no devices objects attached to it.   So that isn't very helpful.

    I wish the device node would finger the problematic device object that prevented the driver from unloading.  Perhaps I can dig a little deeper and might get lucky, but I'm hoping somebody has already been through this and can help me.

     

     


    Tim

    Friday, May 3, 2019 2:23 AM

All replies

  • Did you write the bus driver. Is it a WDF or WDM driver?

    The "Device Manager", which is an MMC plug-in, doesn't interact with the drivers or device objects; that is the job of the PnP manager and the I/O manager. Device Manager can trigger some events, such as device unload or enumeration, but that is all handled by the PnP manager.

    Look at the object header of the device object and see whether there is a handle or kernel reference on it. If it is a handle, you can easily track that down. If there is an outstanding reference then you could set a data write breakpoint on the device object's reference counter when you create the device object to see who is incrementing it.

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, May 3, 2019 2:43 AM
    Moderator
  • Wow!  That was a quick reply.  Thanks so much!

    Yes.  I wrote the bus enumerator as well as the functional driver.  They are both WDM drivers.  The problem is that the bus enumerator created a new PDO and its functional driver won't load because it's still in memory because of an earlier device object with a reference count (at least if my understanding of CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD is correct).


    Tim

    Friday, May 3, 2019 3:32 AM
  • Bummer. WDM is much harder to diagnose than WDF.

    There are many reasons why you'll see CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD, but as you guessed they ultimately have to do with the driver failing to unload because of a dangling reference.

    Have you tried running your driver with Driver Verifier enabled?

     -Brian


    Azius Developer Training www.azius.com Windows device driver, internals, security, & forensics training and consulting. Blog at www.azius.com/blog

    Friday, May 3, 2019 3:38 AM
    Moderator
  • I thought about driver verifier, but the failure happens with a customer and they're reluctant to change anything.  I asked the customer to force a crashdump when this condition arose and they sent me the crashdump and that's all I have to go on.  Any suggestions on how the customer might track down that dangling reference?  Perhaps something from sysinternals?

    Tim

    Friday, May 3, 2019 12:53 PM
  • This is purely a leaked Ob ref. It can’t be an open handle, an open handle would have kept the FDO in surprise removed state and only when closed would the remove irp come. You can turn on Ob tracking/debugging for the next time, but you should review the code for unmatched Ob calls and API calls that take a ref (like IoCreateWorkItem) which are not paired with the api call that releases the reference.

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

    Friday, May 3, 2019 2:23 PM