RE: Under what circumstances will enabling a device in "Device Manager" require a reboot

you will get CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD if you have oustanding references on any objects (driver object, device object) after the driver has been unload (e.g. DriverUnload has been called). if these references are still around when the i/o manager tries to load the driver, the driver load will fail b/c the previous oustanding references will have kept the driver image in memory (even though the driver has been “unloaded”).

what this means to you is to find out all the spots that ObReferenceObject are called and make sure they all match with a call to ObDereferenceObject.

d

It is possible to find the object that has reference to it even after
DriverUnload has been called?

setupapi.dev.log/setupapi.app.log is not of much help here.

setupapi.dev.log logs only if there is fresh installatino or update of
driver software.

setupapi.app.log -> logs some data for disable/enable, but nothing much
useful other **PROB** failed.

wrote in message news:xxxxx@ntdev…
> you will get CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD if you have oustanding
> references on any objects (driver object, device object) after the driver
> has been unload (e.g. DriverUnload has been called). if these references
> are still around when the i/o manager tries to load the driver, the driver
> load will fail b/c the previous oustanding references will have kept the
> driver image in memory (even though the driver has been “unloaded”).
>
> what this means to you is to find out all the spots that ObReferenceObject
> are called and make sure they all match with a call to
> ObDereferenceObject.
>
> d
>

I am using full verbose output.
Also I edited registry to set 0x8 as MSB meaning, to receive debug mesgs to
both log as well as debugger.
But I dont see the mesgs on debugger though.

“Praveen Kumar Amritaluru” wrote in message
news:xxxxx@ntdev…
> It is possible to find the object that has reference to it even after
> DriverUnload has been called?
>
> setupapi.dev.log/setupapi.app.log is not of much help here.
>
> setupapi.dev.log logs only if there is fresh installatino or update of
> driver software.
>
> setupapi.app.log -> logs some data for disable/enable, but nothing much
> useful other PROB failed.
>
>
> wrote in message news:xxxxx@ntdev…
>> you will get CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD if you have oustanding
>> references on any objects (driver object, device object) after the driver
>> has been unload (e.g. DriverUnload has been called). if these references
>> are still around when the i/o manager tries to load the driver, the
>> driver load will fail b/c the previous oustanding references will have
>> kept the driver image in memory (even though the driver has been
>> “unloaded”).
>>
>> what this means to you is to find out all the spots that
>> ObReferenceObject are called and make sure they all match with a call to
>> ObDereferenceObject.
>>
>> d
>>
>
>
>

the only thing you can do is set a break on address break point, ba w4

, where is the refcount for the PDEVICE_OBJECT for your driver. try deleting the your miniport WDFDEVICE in your driver's unload routine and see if that fixes things.

for all those who are curious (that would be me :wink: ), what was the problem? knowing the problem will help the community figure out the same issue in the future in a quicker fashion.

thx
d

so what was the bug and fix? again, this helps me and others figure out these types of issues in the future.

d

Doron,
He must have pointed out his bug:
“From the error message and mails I understand that some reference is
being left out which is failing driver restart and reason for the mesg:
“CM_PROB_DRIVER_FAILED_PRIOR_UNLOAD”.
Yet to figure out the issue.”


Best Regards,
hanzhu

xxxxx@Microsoft.com дµÀ:

so what was the bug and fix? again, this helps me and others figure out these types of issues in the future.

d


Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

no, he didn’t point out the *specific* bug. nor did he confirm that it was a ref count issue. I want to know the root cause so that it is something else I know to look for in the future.

d

WdfDriverMiniportUnload() was not being called from within DriverUnload
routine of the miniport.

As a result I/O manager had reference to the “Driver Object” (not
DeviceObject) and this was failing unload or reenable of the device.

Calling WdfDriverMiniportUnload() from within DriverUnload() routine got
enable/disable working.

Miniport driver had minimal changes done for KMDF by diff team member long
back, and never expected to have any issues there.

Real culprit was hiding there

Regds,

-Praveen

wrote in message news:xxxxx@ntdev…
> for all those who are curious (that would be me :wink: ), what was the
> problem? knowing the problem will help the community figure out the same
> issue in the future in a quicker fashion.
>
> thx
> d
>