PnP Manager Firing Unintended IRP_MN_SURPRISE_REMOVAL IRP

Hi,

I have a scenario where USB device is connected to PC and communicating with it.

In this process application is keep on opening and closing the handle
to access a USB port and doing few cycle to read and write.

When the above process in going on in a loop, all of sudden I can see
PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is no
USB re-enumeration done manually and after that I can see PnP manager
is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to
this USB communication going down cause IRP_MN_REMOVE_DEVICE called
after add device and ideally I am expecting IRP_MN_REMOVE should occur
before IRP_MN_START_DEVICE.

Please share your input. Here are the some traces from my device driver.

00003774 853.22888184 Enter fnProcessPnPIrp()
00003775 853.22888184 Enter IRP_MN_SURPRISE_REMOVAL
00003776 853.22888184 Set event for No pending IO Event
00003777 853.22985840 Exit IRP_MN_SURPRISE_REMOVAL

00003778 853.46289063 Enter fnPnPAddDevice()
00003779 853.46325684 0 == ntStatus
00003780 853.46337891 Enter fnProcessPnPIrp()
00003781 853.46337891 Set event for No pending IO Event
00003782 853.46343994 Enter fnProcessPnPIrp()
00003783 853.46343994 Set event for No pending IO Event
00003784 853.46350098 Enter fnProcessPnPIrp()
00003785 853.46350098 Set event for No pending IO Event
00003786 853.46362305 Enter fnProcessPnPIrp()
00003787 853.46417236 Enter StartDevice()
00003788 853.46588135 Set event for No pending IO Event
00003789 853.46649170 Enter fnProcessPnPIrp()
00003790 853.46649170 Enter Capabilities or PNP device state
00003791 853.46661377 Set event for No pending IO Event
00003792 853.46661377 Exit Capabilities or PNP device state
00003793 853.46667480 Enter fnProcessPnPIrp()
00003794 853.46667480 Enter Capabilities or PNP device state
00003795 853.46667480 Set event for No pending IO Event
00003796 853.46667480 Exit Capabilities or PNP device state
00003797 853.46673584 Enter fnProcessPnPIrp()
00003798 853.46673584 Enter Capabilities or PNP device state
00003799 853.46673584 Set event for No pending IO Event
00003800 853.46673584 Exit Capabilities or PNP device state
00003801 853.46685791 Set event for No pending IO Event
00003802 854.07531738 [88CBA0F0] WskProIRPGetAddrInfo is called.

00003816 855.16186523 Enter fnProcessPnPIrp()
00003817 855.16192627 Enter IRP_MN_REMOVE_DEVICE
00003818 855.16192627 Set event for No pending IO Event
00003819 855.16192627 Set event for remove device event
00003820 855.16192627 Enter fnRemoveDevice()
00003821 855.16229248 Exit IRP_MN_REMOVE_DEVICE

Abhishek Bhadraja wrote:

I have a scenario where USB device is connected to PC and communicating with it.

In this process application is keep on opening and closing the handle
to access a USB port and doing few cycle to read and write.

When the above process in going on in a loop, all of sudden I can see
PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is no
USB re-enumeration done manually …

It sounds like your hardware is dropping off of the bus, or somehow
making the hub think it has dropped off the bus. Have you tried getting
some USB traces to see what triggers the surprise removal?

and after that I can see PnP manager
is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to
this USB communication going down cause IRP_MN_REMOVE_DEVICE called
after add device and ideally I am expecting IRP_MN_REMOVE should occur
before IRP_MN_START_DEVICE.

There are no guarantees about this. You have to be able to handle it.
Why is it a problem? The START_DEVICE is being sent to a new instance,
completely separate from the one that is being shut down.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

The pnp manager doesn’t do this on its own. It reacts to the bus driver telling it about the presence of the child. This means the usb core has detected your device has fallen off the bus. I am guessing your device under heavy load is not meeting bus timing requirements and thus is falling off.

With respect to seeing a pnp start before the remove, this is by design. First and foremost, the whole point of the surprise remove irp is to tell you
a) your device is gone
b) clean up
c) once completed, your device can be reenumerated again, so make sure anything based on identity (device itnerfaces, symbolic links, wmi) are torn down
d) wait for all open handles to close so the pnp remove can be sent

after c, the device can be reenumerated and restarted. This can happen multiple times and you can have N instances stuck in the surprise remove state. All will wait until the app closes it handle(s) to the device.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Abhishek Bhadraja
Sent: Friday, October 17, 2014 10:31 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] PnP Manager Firing Unintended IRP_MN_SURPRISE_REMOVAL IRP

Hi,

I have a scenario where USB device is connected to PC and communicating with it.

In this process application is keep on opening and closing the handle to access a USB port and doing few cycle to read and write.

When the above process in going on in a loop, all of sudden I can see PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is no USB re-enumeration done manually and after that I can see PnP manager is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to this USB communication going down cause IRP_MN_REMOVE_DEVICE called after add device and ideally I am expecting IRP_MN_REMOVE should occur before IRP_MN_START_DEVICE.

Please share your input. Here are the some traces from my device driver.

00003774 853.22888184 Enter fnProcessPnPIrp()
00003775 853.22888184 Enter IRP_MN_SURPRISE_REMOVAL
00003776 853.22888184 Set event for No pending IO Event
00003777 853.22985840 Exit IRP_MN_SURPRISE_REMOVAL

00003778 853.46289063 Enter fnPnPAddDevice()
00003779 853.46325684 0 == ntStatus
00003780 853.46337891 Enter fnProcessPnPIrp()
00003781 853.46337891 Set event for No pending IO Event
00003782 853.46343994 Enter fnProcessPnPIrp()
00003783 853.46343994 Set event for No pending IO Event
00003784 853.46350098 Enter fnProcessPnPIrp()
00003785 853.46350098 Set event for No pending IO Event
00003786 853.46362305 Enter fnProcessPnPIrp()
00003787 853.46417236 Enter StartDevice()
00003788 853.46588135 Set event for No pending IO Event
00003789 853.46649170 Enter fnProcessPnPIrp()
00003790 853.46649170 Enter Capabilities or PNP device state
00003791 853.46661377 Set event for No pending IO Event
00003792 853.46661377 Exit Capabilities or PNP device state
00003793 853.46667480 Enter fnProcessPnPIrp()
00003794 853.46667480 Enter Capabilities or PNP device state
00003795 853.46667480 Set event for No pending IO Event
00003796 853.46667480 Exit Capabilities or PNP device state
00003797 853.46673584 Enter fnProcessPnPIrp()
00003798 853.46673584 Enter Capabilities or PNP device state
00003799 853.46673584 Set event for No pending IO Event
00003800 853.46673584 Exit Capabilities or PNP device state
00003801 853.46685791 Set event for No pending IO Event
00003802 854.07531738 [88CBA0F0] WskProIRPGetAddrInfo is called.

00003816 855.16186523 Enter fnProcessPnPIrp()
00003817 855.16192627 Enter IRP_MN_REMOVE_DEVICE
00003818 855.16192627 Set event for No pending IO Event
00003819 855.16192627 Set event for remove device event
00003820 855.16192627 Enter fnRemoveDevice()
00003821 855.16229248 Exit IRP_MN_REMOVE_DEVICE


NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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

Our driver is developed to maintain one session . I am not the one who
has very good hand in device driver development.

Any direction on this will be helpful for me.

My concern on the above issue is, in normal case I can see
IRP_MN_REMOVE_DEVICE called right after IRP_MN_ SURPRISE_REMOVAL but
in the erroneous scenario it is taking 2 second to call
IRP_MN_REMOVE_DEVICE after IRP_MN_SURPRISE_REMOVAL

On Fri, Oct 17, 2014 at 1:43 PM, Tim Roberts wrote:
> Abhishek Bhadraja wrote:
>> I have a scenario where USB device is connected to PC and communicating with it.
>>
>> In this process application is keep on opening and closing the handle
>> to access a USB port and doing few cycle to read and write.
>>
>> When the above process in going on in a loop, all of sudden I can see
>> PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is no
>> USB re-enumeration done manually …
>
> It sounds like your hardware is dropping off of the bus, or somehow
> making the hub think it has dropped off the bus. Have you tried getting
> some USB traces to see what triggers the surprise removal?
>
>
>> and after that I can see PnP manager
>> is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to
>> this USB communication going down cause IRP_MN_REMOVE_DEVICE called
>> after add device and ideally I am expecting IRP_MN_REMOVE should occur
>> before IRP_MN_START_DEVICE.
>
> There are no guarantees about this. You have to be able to handle it.
> Why is it a problem? The START_DEVICE is being sent to a new instance,
> completely separate from the one that is being shut down.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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

The removal cannot happen until all open handles to the device have been
closed.

Mark Roddy

On Fri, Oct 17, 2014 at 1:54 PM, Abhishek Bhadraja <
xxxxx@gmail.com> wrote:

Our driver is developed to maintain one session . I am not the one who
has very good hand in device driver development.

Any direction on this will be helpful for me.

My concern on the above issue is, in normal case I can see
IRP_MN_REMOVE_DEVICE called right after IRP_MN_ SURPRISE_REMOVAL but
in the erroneous scenario it is taking 2 second to call
IRP_MN_REMOVE_DEVICE after IRP_MN_SURPRISE_REMOVAL

On Fri, Oct 17, 2014 at 1:43 PM, Tim Roberts wrote:
> > Abhishek Bhadraja wrote:
> >> I have a scenario where USB device is connected to PC and communicating
> with it.
> >>
> >> In this process application is keep on opening and closing the handle
> >> to access a USB port and doing few cycle to read and write.
> >>
> >> When the above process in going on in a loop, all of sudden I can see
> >> PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is no
> >> USB re-enumeration done manually …
> >
> > It sounds like your hardware is dropping off of the bus, or somehow
> > making the hub think it has dropped off the bus. Have you tried getting
> > some USB traces to see what triggers the surprise removal?
> >
> >
> >> and after that I can see PnP manager
> >> is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to
> >> this USB communication going down cause IRP_MN_REMOVE_DEVICE called
> >> after add device and ideally I am expecting IRP_MN_REMOVE should occur
> >> before IRP_MN_START_DEVICE.
> >
> > There are no guarantees about this. You have to be able to handle it.
> > Why is it a problem? The START_DEVICE is being sent to a new instance,
> > completely separate from the one that is being shut down.
> >
> > –
> > Tim Roberts, xxxxx@probo.com
> > Providenza & Boekelheide, Inc.
> >
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
> >
> > OSR is HIRING!! See http://www.osr.com/careers
> >
> > 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
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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
>

who is responsible for closing all the handle. the device driver itself.

Can you give some example of closing handle.

On Fri, Oct 17, 2014 at 2:29 PM, Mark Roddy wrote:
> The removal cannot happen until all open handles to the device have been
> closed.
>
> Mark Roddy
>
> On Fri, Oct 17, 2014 at 1:54 PM, Abhishek Bhadraja
> wrote:
>>
>> Our driver is developed to maintain one session . I am not the one who
>> has very good hand in device driver development.
>>
>> Any direction on this will be helpful for me.
>>
>> My concern on the above issue is, in normal case I can see
>> IRP_MN_REMOVE_DEVICE called right after IRP_MN_ SURPRISE_REMOVAL but
>> in the erroneous scenario it is taking 2 second to call
>> IRP_MN_REMOVE_DEVICE after IRP_MN_SURPRISE_REMOVAL
>>
>> On Fri, Oct 17, 2014 at 1:43 PM, Tim Roberts wrote:
>> > Abhishek Bhadraja wrote:
>> >> I have a scenario where USB device is connected to PC and communicating
>> >> with it.
>> >>
>> >> In this process application is keep on opening and closing the handle
>> >> to access a USB port and doing few cycle to read and write.
>> >>
>> >> When the above process in going on in a loop, all of sudden I can see
>> >> PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is no
>> >> USB re-enumeration done manually …
>> >
>> > It sounds like your hardware is dropping off of the bus, or somehow
>> > making the hub think it has dropped off the bus. Have you tried getting
>> > some USB traces to see what triggers the surprise removal?
>> >
>> >
>> >> and after that I can see PnP manager
>> >> is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to
>> >> this USB communication going down cause IRP_MN_REMOVE_DEVICE called
>> >> after add device and ideally I am expecting IRP_MN_REMOVE should occur
>> >> before IRP_MN_START_DEVICE.
>> >
>> > There are no guarantees about this. You have to be able to handle it.
>> > Why is it a problem? The START_DEVICE is being sent to a new instance,
>> > completely separate from the one that is being shut down.
>> >
>> > –
>> > Tim Roberts, xxxxx@probo.com
>> > Providenza & Boekelheide, Inc.
>> >
>> >
>> > —
>> > NTDEV is sponsored by OSR
>> >
>> > Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>> >
>> > OSR is HIRING!! See http://www.osr.com/careers
>> >
>> > 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
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> 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 Visit the list at:
> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
> http://www.osr.com/careers 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

Abhishek Bhadraja wrote:

who is responsible for closing all the handle. the device driver itself.

No, it’s the application that opened the driver in the first place. The
driver cannot unload as long as an application thinks the file handle is
still open, even though there’s no hardware for the driver to talk to.
Your driver has to be able to handle this.

Can you give some example of closing handle.

You can’t be serious.

CloseHandle( hDevice );


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Abhishek Bhadraja wrote:

Our driver is developed to maintain one session . I am not the one who
has very good hand in device driver development.

Any direction on this will be helpful for me.

You have to be able to handle this. It’s just that simple. Why is this
an issue? What problems are you seeing because the first instance
happens to stick around?

My concern on the above issue is, in normal case I can see
IRP_MN_REMOVE_DEVICE called right after IRP_MN_ SURPRISE_REMOVAL but
in the erroneous scenario it is taking 2 second to call
IRP_MN_REMOVE_DEVICE after IRP_MN_SURPRISE_REMOVAL

It’s not an “erroneous scenario”. It’s perfectly normal. No one ever
promised that the first device would be removed before the second one is
created. Your driver MUST handle this.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

I am sorry for the silly question… but got a good input from you… I
was bit confused between driver and application…

Thanks a lot for the input

On Fri, Oct 17, 2014 at 3:02 PM, Tim Roberts wrote:
> Abhishek Bhadraja wrote:
>> who is responsible for closing all the handle. the device driver itself.
>
> No, it’s the application that opened the driver in the first place. The
> driver cannot unload as long as an application thinks the file handle is
> still open, even though there’s no hardware for the driver to talk to.
> Your driver has to be able to handle this.
>
>
>> Can you give some example of closing handle.
>
> You can’t be serious.
>
> CloseHandle( hDevice );
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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

If you don’t have any globals and all state is rooted in the device extension or lower allocations, you can easily handle two instances.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Abhishek Bhadraja
Sent: Friday, October 17, 2014 10:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] PnP Manager Firing Unintended IRP_MN_SURPRISE_REMOVAL IRP

Our driver is developed to maintain one session . I am not the one who has very good hand in device driver development.

Any direction on this will be helpful for me.

My concern on the above issue is, in normal case I can see IRP_MN_REMOVE_DEVICE called right after IRP_MN_ SURPRISE_REMOVAL but in the erroneous scenario it is taking 2 second to call IRP_MN_REMOVE_DEVICE after IRP_MN_SURPRISE_REMOVAL

On Fri, Oct 17, 2014 at 1:43 PM, Tim Roberts wrote:
> Abhishek Bhadraja wrote:
>> I have a scenario where USB device is connected to PC and communicating with it.
>>
>> In this process application is keep on opening and closing the handle
>> to access a USB port and doing few cycle to read and write.
>>
>> When the above process in going on in a loop, all of sudden I can see
>> PnP manager is firing a IRP_MN_SURPRISE_REMOVAL IRP though there is
>> no USB re-enumeration done manually …
>
> It sounds like your hardware is dropping off of the bus, or somehow
> making the hub think it has dropped off the bus. Have you tried
> getting some USB traces to see what triggers the surprise removal?
>
>
>> and after that I can see PnP manager
>> is firing IRP_MN_START_DEVICE before IRP_MN_REMOVE_DEVICE and due to
>> this USB communication going down cause IRP_MN_REMOVE_DEVICE called
>> after add device and ideally I am expecting IRP_MN_REMOVE should
>> occur before IRP_MN_START_DEVICE.
>
> There are no guarantees about this. You have to be able to handle it.
> Why is it a problem? The START_DEVICE is being sent to a new
> instance, completely separate from the one that is being shut down.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> 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

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

OSR is HIRING!! See http://www.osr.com/careers

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