Hello,
I explain my problem. I wrote a usb driver to control a serial-usb adapter.
If I unplug the usb cable in Win XP, I dont have any problem. The process
to remove the driver is working. It calls IRP_MN_SURPRISE_REMOVAL and
IRP_MN_REMOVE_DEVICE, it deletes my FDO and destroy allocation memory.
Now, I execute a process (like hyperterminal) and open a com port. The
process to remove the drivers while I unplug the usb cable isn’t working.
The OS doesn’t call IRP_MN_SURPRISE_REMOVAL, etc. I have to reboot the
system at this point.
How can I explain this problem. Is there any solution to fix it?
Thanks
Christian
Hi, I have an other point to say,
Hello,
I explain my problem. I wrote a usb driver to control a serial-usb
adapter.
If I unplug the usb cable in Win XP, I dont have any problem. The process
to remove the driver is working. It calls IRP_MN_SURPRISE_REMOVAL and
IRP_MN_REMOVE_DEVICE, it deletes my FDO and destroy allocation memory.
Now, I execute a process (like hyperterminal) and open a com port. The
process to remove the drivers while I unplug the usb cable isn’t working.
The OS doesn’t call IRP_MN_SURPRISE_REMOVAL, etc. I have to reboot the
system at this point.
I receive 2 IRP_MN_QUERY_DEVICE_RELATIONS after plugging out the usb cable.
And after, I cannot do any thing. I have to force a reset system to enable
it again.
Christian
CG wrote:
Hello,
I explain my problem. I wrote a usb driver to control a serial-usb adapter.
If I unplug the usb cable in Win XP, I dont have any problem. The process
to remove the driver is working. It calls IRP_MN_SURPRISE_REMOVAL and
IRP_MN_REMOVE_DEVICE, it deletes my FDO and destroy allocation memory.
Now, I execute a process (like hyperterminal) and open a com port. The
process to remove the drivers while I unplug the usb cable isn’t working.
The OS doesn’t call IRP_MN_SURPRISE_REMOVAL, etc. I have to reboot the
system at this point.
How can I explain this problem. Is there any solution to fix it?
The device instance remains open until Hyperterminal closes the file,
and the driver cannot be unloaded until that happens. Your driver must
be able to continue to operate reasonably even after the device has been
unplugged. There are some characteristic USB errors you get when the
device is gone. When you see those, you need to return errors to
Hyperterminal. Eventually, the user will give up and kill the app.
If you cannot exit Hyperterminal in this case, then your driver is not
behaving properly. Do you get the IRP_MJ_CLOSE call when you exit
Hyperterminal?
This is one of the key problems with impersonating another device. Real
COM ports don’t go away in midstream, so COM apps don’t expect that
behavior.
–
CG wrote:
Hi, I have an other point to say,
I receive 2 IRP_MN_QUERY_DEVICE_RELATIONS after plugging out the usb cable.
And after, I cannot do any thing. I have to force a reset system to enable
it again.
For removal relations, right? That’s going to be your best clue as to
what has actually happened. You need to remember that state, and make
sure you don’t touch the hardware again until you are unloaded. You
need to complete any IRPs you are holding – probably with an error –
and fail any future user-mode IRPs.
Do you run with driver verifier turned on? If not, why not?
–
Hi Tom,
The device instance remains open until Hyperterminal closes the file,
and the driver cannot be unloaded until that happens. Your driver must
be able to continue to operate reasonably even after the device has been
unplugged. There are some characteristic USB errors you get when the
device is gone. When you see those, you need to return errors to
Hyperterminal. Eventually, the user will give up and kill the app.
If you cannot exit Hyperterminal in this case, then your driver is not
behaving properly. Do you get the IRP_MJ_CLOSE call when you exit
Hyperterminal?
nope, I didn’t receive this IRP. I receive only
IRP_MN_QUERY_DEVICE_RELATIONS 2 times. In fact, I don’t use hyperterminal
but my own COM applications.
After unplugging the usb cable, I am able to close my application, but I
cannot start it again. The com port is still busy. I have to reset my
system to execute again the COM application.
Christian
Hello Tim
For removal relations, right? That’s going to be your best clue as to
what has actually happened. You need to remember that state, and make
sure you don’t touch the hardware again until you are unloaded. You
need to complete any IRPs you are holding – probably with an error –
and fail any future user-mode IRPs.
Do you run with driver verifier turned on? If not, why not?
No i didn’t try with driver verifier. It will be my next step.
Regards
Christian
CG wrote:
Hi Tom,
Tim.
>If you cannot exit Hyperterminal in this case, then your driver is not
>behaving properly. Do you get the IRP_MJ_CLOSE call when you exit
>Hyperterminal?
>
>
nope, I didn’t receive this IRP. I receive only
IRP_MN_QUERY_DEVICE_RELATIONS 2 times. In fact, I don’t use hyperterminal
but my own COM applications.
After unplugging the usb cable, I am able to close my application, but I
cannot start it again. The com port is still busy. I have to reset my
system to execute again the COM application.
I’ll bet the application is still present in the Task Manager task list,
even if the window is gone. The CloseHandle call is probably waiting
for all outstanding I/O to finish, but your driver is holding an IRP
that you haven’t completed. Does the app send down ioctls to wait for
certain RS232 signals? Are you completing them with an error? You need
to take SOME kind of action in response to the
IRP_MN_QUERY_DEVICE_RELATIONS RemoveRelations call.
Next to power handling, this “surprise removal” scenario is the most
difficult part of a USB driver, because the removals always happen in
the most awkward places, and Q/A people have a particular knack for
finding those awkward places. I hate the bug reports that say, “if I
unplug/replug 10 times in 15 minutes with the machine under full load,
60% of the time the it will restart.”
–
Tim,
>
I’ll bet the application is still present in the Task Manager task list,
even if the window is gone. The CloseHandle call is probably waiting
The application is not present in task manager after closing it.
for all outstanding I/O to finish, but your driver is holding an IRP
that you haven’t completed. Does the app send down ioctls to wait for
certain RS232 signals? Are you completing them with an error? You need
to take SOME kind of action in response to the
IRP_MN_QUERY_DEVICE_RELATIONS RemoveRelations call.
How can I know that some an IRP is pending? Do I have to verify if some IRP
are pending when I receive the IRP_MN_QUERY_DEVICE_RELATIONS call?
Next, I used driver verifier and no error is reporting.
Christian
What type of query device relations are you receiving? Look in the
current stack location for the type. Are you sure you are completing
all pnp irps?
As for pending irps, it is your data structure so you can figure it out.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of CG
Sent: Tuesday, March 29, 2005 12:15 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] USB - IRP_MN_SURPRISE_REMOVAL
Tim,
>
I’ll bet the application is still present in the Task Manager task
list,
even if the window is gone. The CloseHandle call is probably waiting
The application is not present in task manager after closing it.
for all outstanding I/O to finish, but your driver is holding an IRP
that you haven’t completed. Does the app send down ioctls to wait for
certain RS232 signals? Are you completing them with an error? You
need
to take SOME kind of action in response to the
IRP_MN_QUERY_DEVICE_RELATIONS RemoveRelations call.
How can I know that some an IRP is pending? Do I have to verify if some
IRP
are pending when I receive the IRP_MN_QUERY_DEVICE_RELATIONS call?
Next, I used driver verifier and no error is reporting.
Christian
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
CG wrote:
>for all outstanding I/O to finish, but your driver is holding an IRP
>that you haven’t completed. Does the app send down ioctls to wait for
>certain RS232 signals? Are you completing them with an error? You need
>to take SOME kind of action in response to the
>IRP_MN_QUERY_DEVICE_RELATIONS RemoveRelations call.
>
>
How can I know that some an IRP is pending?
Well, your driver had better KNOW that. If you have received an IRP and
queued it up for later processing, or if you created an IRP and sent it
to the next lower driver, those IRPs *MUST* be completed before your
driver will be allowed to unload.
You said this is a simulated COM port driver? Do you have a read
request queued at all times, so you can catch asynchronous data, or just
when the user does a ReadFile? If you have a request queued, you need
to cancel it as soon as you know you are unplugged.
Do you have a DriverUnload handler in your driver?
Do I have to verify if some IRP
are pending when I receive the IRP_MN_QUERY_DEVICE_RELATIONS call?
Yes. If the query is for RemovalRelations, and you have an instance
open, then you are going to have to trigger some clean up. How are you
responding to the IRP_MN_QUERY_DEVICE_RELATIONS?
Next, I used driver verifier and no error is reporting.
No error, and it still doesn’t unload?
–