Hi,
I am wondering if somehow the SetupDi Api’s for enumerating device could
have something to do with our drivers not receiving an IRP_MN_REMOVE_DEVICE
for a while? We do receive the IRP_MN_REMOVE_DEVICE IRP in our driver but I
am seeing a delay of around 5 seconds after we have received the
IRP_MN_SURPRISE_REMOVAL IRP.
If I have understood it correctly our drivers will not receive the
REMOVE_DEVICE IRP if an application is holding a handle to our drivers, thus
we have made sure to uninstall/stop all our applications that might be
holding on to a handle but we are still facing this issue.
The only thing that is left is a test application that uses the SetupDi
API’s to enumerate the devices present in the system before and after a
sleep cycle of the system.
Also, looking at the logs from our drivers we see that the test application
seems to be enumerating the devices around the time when we are handling the
IRP_MN_SURPRISE_REMOVAL IRP.
Thanks
Faik
The latency of your app closing its handles is most likely the culprit. Enumerating instances of a device interface should not delay a remove irp. What device stack are you in? one with drivers layered on top of you or just your own custom driver with its own io interface?
d
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Faik Riza
Sent: Thursday, January 14, 2010 12:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] SetupDi API’s relation to arrival of IRP_MN_REMOVE_DEVICE
Hi,
I am wondering if somehow the SetupDi Api’s for enumerating device could have something to do with our drivers not receiving an IRP_MN_REMOVE_DEVICE for a while? We do receive the IRP_MN_REMOVE_DEVICE IRP in our driver but I am seeing a delay of around 5 seconds after we have received the IRP_MN_SURPRISE_REMOVAL IRP.
If I have understood it correctly our drivers will not receive the REMOVE_DEVICE IRP if an application is holding a handle to our drivers, thus we have made sure to uninstall/stop all our applications that might be holding on to a handle but we are still facing this issue.
The only thing that is left is a test application that uses the SetupDi API’s to enumerate the devices present in the system before and after a sleep cycle of the system.
Also, looking at the logs from our drivers we see that the test application seems to be enumerating the devices around the time when we are handling the IRP_MN_SURPRISE_REMOVAL IRP.
Thanks
Faik
— NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and other seminars visit: http://www.osr.com/seminars To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
Hi Doron,
Thanks for taking time to answer.
The thing is that none of our applications are running. The only thing that
has anything to do with our drivers that is running is the DTM test, this
test is the one using the SetupDi API’s to check if the same number of
devices is present after a Sleep/Resume cycle.
As for the stack question, maybe I should have described what we are dealing
with in my original post.
This is a device with a composite bus driver enumerating a couple of more
devices. The functional devices are an NDIS driver, a coupe of Serial-to-USB
drivers and a modem driver. There are no more drivers on top of my drivers.
Also I have uninstalled all the drivers except for one of the Serial-to-Usb
driver and the bus driver (PDO’s still enumerated though), this didn’t
help.
btw, I do not see any IRP_MJ_CREATE’s comming to my driver.
Thanks
Faik
On Thu, Jan 14, 2010 at 9:59 PM, Doron Holan wrote:
> The latency of your app closing its handles is most likely the culprit.
> Enumerating instances of a device interface should not delay a remove irp.
> What device stack are you in? one with drivers layered on top of you or just
> your own custom driver with its own io interface?
>
>
>
> d
>
>
>
> From: xxxxx@lists.osr.com [mailto:
> xxxxx@lists.osr.com] *On Behalf Of *Faik Riza
> Sent: Thursday, January 14, 2010 12:30 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] SetupDi API’s relation to arrival of
> IRP_MN_REMOVE_DEVICE
>
>
>
> Hi,
>
> I am wondering if somehow the SetupDi Api’s for enumerating device could
> have something to do with our drivers not receiving an IRP_MN_REMOVE_DEVICE
> for a while? We do receive the IRP_MN_REMOVE_DEVICE IRP in our driver but I
> am seeing a delay of around 5 seconds after we have received the
> IRP_MN_SURPRISE_REMOVAL IRP.
>
> If I have understood it correctly our drivers will not receive the
> REMOVE_DEVICE IRP if an application is holding a handle to our drivers, thus
> we have made sure to uninstall/stop all our applications that might be
> holding on to a handle but we are still facing this issue.
>
> The only thing that is left is a test application that uses the SetupDi
> API’s to enumerate the devices present in the system before and after a
> sleep cycle of the system.
>
> Also, looking at the logs from our drivers we see that the test application
> seems to be enumerating the devices around the time when we are handling the
> IRP_MN_SURPRISE_REMOVAL IRP.
>
> Thanks
> Faik
> — NTDEV is sponsored by OSR For our schedule of WDF, WDM, debugging and
> other seminars visit: http://www.osr.com/seminars To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>