Win2k has the same behavior as XP, you will not get the remove until
after the last open handle has been closed. As for 9x, I have seen
implementations where the remove was succeeded w/outstanding opens and
references were kept on the devobj that were released in the close path.
d
-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Friday, February 07, 2003 11:36 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Concept of Remove Lock
Thanks for your comments.
I agree. Deferring the remove IRP is ok. But, I think in earlier WDM
implementations (Win98, ME) I got a remove IRP while an app has open
handles to the device. I will check that on W2K again…
If a remove lock is used on W9x then the app holds up a system worker
thread that is responsible for handling PnP add/remove. This will hang
the PnP manager including Device Manager. I experienced this problem
several times with USB devices.
I also agree on your bottom line. Complete parameter validation and
proper implementation of IRP cancellation is essential to reliable
drivers. Furthermore, generally I tie all resources associated with an
app to the file object for which the app has a handle. On cleanup/close,
all resources will be released. This conforms with your recommendations.
Udo Eberhardt
Peter Wieland wrote:
You’re correct that a hung happ could hold up the remove process,
though
not for the reason you’re stating.
Until all handles to a device are closed, WinXP (and I thought Win2k)
won’t send a remove IRP to the stack. Fortunately the administrator
can
kill the hung application - as long as cancel the drivers support
cancellation or speedy completion of the outstanding IO. Killing the
App will close the handle which will allow remove to continue.
The bottom line is that you can’t ever trust a user-mode application.
So you need to validate any parameters it sends you (for example).
You
can allow it to perform locking operations and you can allow it to do
things which might block other processes as long as you can recover
from
that. So it’s acceptable to have your driver wait on an event which
will be set by a user-mode client, as long as you can detect the
termination of that client (perhaps when it closes its handle to your
device) and abort the operation.
-p
-----Original Message-----
From: Udo Eberhardt [mailto:xxxxx@thesycon.de]
Sent: Friday, February 07, 2003 9:38 AM
To: NT Developers Interest List
I repeat from my posting to another topic:
In general, a driver should not rely on a particular behavior of an
app.
This is a basic principle of device driver design.
BTW, this raises interesting questions regarding the concept of remove
locks. IMHO, the remove lock concept violates the principle mentioned
above. Execution of kernel-mode code in a device driver is blocked (on
the remove lock) until a particular operation (CloseHandle) is
performed
by an app? Sounds strange to me. What happens if the app never closes
the handle? Or if the app hangs? A kernel-mode worker thread will be
blocked in such cases. There are only a few of them, right?
Any comments? Mr. Oney?
–
Udo Eberhardt
Thesycon GmbH, Germany
xxxxx@thesycon.de
www.thesycon.de
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com]On Behalf Of Walter Oney
>Sent: Friday, February 07, 2003 6:09 PM
>To: NT Developers Interest List
>Subject: [ntdev] Re: Processing more than one IRP
>
>
>
>>Fernando Roberto da Silva wrote:
>> Can I receive another IRP at the same device while an early IRP
>>was marked as pending ?
>
>In general yes, but there are some qualifications. If an app opens a
>handle without FILE_FLAG_OVERLAPPED, all the Win32 API calls will be
>synchronous. If another thread in the same process attempts to do I/O
>using the same handle, it will be held up until previous I/O finishes.
>
>–
>Walter Oney, Consulting and Training
>Basic and Advanced Driver Programming Seminars Now teaming with John
>Hyde for USB Device Engineering Seminars Check out our schedule at
>http://www.oneysoft.com
>
>—
>You are currently subscribed to ntdev as: xxxxx@thesycon.de To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
You are currently subscribed to ntdev as: xxxxx@microsoft.com To
unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@thesycon.de
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com