Hi,
I am developing a simple KMDF bulk USB driver.
I have noticed that if an app has a handle to my driver, the driver won’t close even when the device is removed from the machine.
only once CloseHandle() is called the driver is properly closed.
Is this the expected behavior?
I would think that the driver should close once there is no device under it, no matter anyone having handles to it.
Many thanks
This is expected behavior, and the only way things can be. Opening a device
can cause the driver to allocate data, once you start I/O requests can be
queued etc. If on removal of the device the was removed there would be no
mechanism for cleaning up all the actions that the open and I/O imply.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I am developing a simple KMDF bulk USB driver.
> I have noticed that if an app has a handle to my driver, the driver won’t
> close even when the device is removed from the machine.
> only once CloseHandle() is called the driver is properly closed.
>
> Is this the expected behavior?
> I would think that the driver should close once there is no device under
> it, no matter anyone having handles to it.
>
> Many thanks
>
As Don said, it is expected behaviour. What you can do is to close
handle from app when you receive a message about your device removal.
Look for WM_DEVICECHANGE.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@giant-steps.com
Sent: Tuesday, March 25, 2008 8:38 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] CreateFile() handle problemHi,
I am developing a simple KMDF bulk USB driver.
I have noticed that if an app has a handle to my driver, the
driver won’t close even when the device is removed from the machine.
only once CloseHandle() is called the driver is properly closed.Is this the expected behavior?
I would think that the driver should close once there is no
device under it, no matter anyone having handles to it.Many thanks
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online
at http://www.osronline.com/page.cfm?name=ListServer
Your application must register for notifications on the file handle it has opened to be notified of the device being surprise removed. This requires a window. Furthermore, this type of registration is required to gracefully remove the device (disable or uninstall in device manager).
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, March 25, 2008 12:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CreateFile() handle problem
This is expected behavior, and the only way things can be. Opening a device
can cause the driver to allocate data, once you start I/O requests can be
queued etc. If on removal of the device the was removed there would be no
mechanism for cleaning up all the actions that the open and I/O imply.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
wrote in message news:xxxxx@ntdev…
> Hi,
>
> I am developing a simple KMDF bulk USB driver.
> I have noticed that if an app has a handle to my driver, the driver won’t
> close even when the device is removed from the machine.
> only once CloseHandle() is called the driver is properly closed.
>
> Is this the expected behavior?
> I would think that the driver should close once there is no device under
> it, no matter anyone having handles to it.
>
> Many thanks
>
—
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
I don’t want to open next “antonish” thread but I can imagine different
implementation. Driver could call an API “invalidate all handles” and OS
would close all opened handles to invalidated device. It’d allow driver
to cleanup and possibly unload immediatelly. Apps would make a cleanup
when receive invalid handle error.
Current way has problems. App has to register for device change
notifications. It needs a window. Services at Vista can’t have windows
so other way how to receive notification has to be used. Similarly with
command line apps. Hideous when one has to create a library to be used
in all apps and services.
Yes, above is maily problem with the way how notifications are
implemented. But what OP presumes makes sense and I’d prefer it in some
cases. Once we had a problem with USB re-enumeration after ESD and
following surprise removal and after long discussion with MS support
they found re-enumeration was blocked by the driver which didn’t unload
fast enough because app has an opened handle. We were requested to close
handle ASAP to solve problem. There is something bad when app can
influence OS behaviour this way.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, March 25, 2008 8:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CreateFile() handle problemThis is expected behavior, and the only way things can be.
Opening a device
can cause the driver to allocate data, once you start I/O
requests can be
queued etc. If on removal of the device the was removed
there would be no
mechanism for cleaning up all the actions that the open and I/O imply.–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to replywrote in message news:xxxxx@ntdev…
> > Hi,
> >
> > I am developing a simple KMDF bulk USB driver.
> > I have noticed that if an app has a handle to my driver,
> the driver won’t
> > close even when the device is removed from the machine.
> > only once CloseHandle() is called the driver is properly closed.
> >
> > Is this the expected behavior?
> > I would think that the driver should close once there is no
> device under
> > it, no matter anyone having handles to it.
> >
> > Many thanks
> >
>
>
>
> —
> 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
>
> Services at Vista can’t have windows so other way how to receive notification has to be used
Not true on 2 accounts. First, a service can have a window. It just can’t create a window in another session. Second, your ControlHandlerEx can receive device change notifications by registering with your service’s handle.
D
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, March 25, 2008 1:33 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problem
I don’t want to open next “antonish” thread but I can imagine different
implementation. Driver could call an API “invalidate all handles” and OS
would close all opened handles to invalidated device. It’d allow driver
to cleanup and possibly unload immediatelly. Apps would make a cleanup
when receive invalid handle error.
Current way has problems. App has to register for device change
notifications. It needs a window. Services at Vista can’t have windows
so other way how to receive notification has to be used. Similarly with
command line apps. Hideous when one has to create a library to be used
in all apps and services.
Yes, above is maily problem with the way how notifications are
implemented. But what OP presumes makes sense and I’d prefer it in some
cases. Once we had a problem with USB re-enumeration after ESD and
following surprise removal and after long discussion with MS support
they found re-enumeration was blocked by the driver which didn’t unload
fast enough because app has an opened handle. We were requested to close
handle ASAP to solve problem. There is something bad when app can
influence OS behaviour this way.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Tuesday, March 25, 2008 8:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CreateFile() handle problemThis is expected behavior, and the only way things can be.
Opening a device
can cause the driver to allocate data, once you start I/O
requests can be
queued etc. If on removal of the device the was removed
there would be no
mechanism for cleaning up all the actions that the open and I/O imply.–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to replywrote in message news:xxxxx@ntdev…
> > Hi,
> >
> > I am developing a simple KMDF bulk USB driver.
> > I have noticed that if an app has a handle to my driver,
> the driver won’t
> > close even when the device is removed from the machine.
> > only once CloseHandle() is called the driver is properly closed.
> >
> > Is this the expected behavior?
> > I would think that the driver should close once there is no
> device under
> > it, no matter anyone having handles to it.
> >
> > Many thanks
> >
>
>
>
> —
> 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
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, March 25, 2008 9:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problem> Services at Vista can’t have windows so other way how to
receive notification has to be used
Not true on 2 accounts. First, a service can have a window.
It just can’t create a window in another session.
Really? My user mode coworkers informed me this was changed in Vista. At
least our library which received notifications via window stopped
working. I’m not quite sure, thought. Maybe window could be created but
received no notifications. Or even function returned OK but no window
was created. Anyway, they had to implement different way how to receive
notifications and I’m sure they wouldn’t do it if not absolutely
necessary 
Second,
your ControlHandlerEx can receive device change notifications
by registering with your service’s handle.
This is what I meant by the other way.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
I am positive that the window receiving notifications still works, the Bluetooth helper service uses this technique to receive notification messages
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, March 25, 2008 1:49 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problem
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, March 25, 2008 9:39 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problem> Services at Vista can’t have windows so other way how to
receive notification has to be used
Not true on 2 accounts. First, a service can have a window.
It just can’t create a window in another session.
Really? My user mode coworkers informed me this was changed in Vista. At
least our library which received notifications via window stopped
working. I’m not quite sure, thought. Maybe window could be created but
received no notifications. Or even function returned OK but no window
was created. Anyway, they had to implement different way how to receive
notifications and I’m sure they wouldn’t do it if not absolutely
necessary
Second,
your ControlHandlerEx can receive device change notifications
by registering with your service’s handle.
This is what I meant by the other way.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
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
> I don’t want to open next “antonish” thread
Thanks for a “compliment”…
…but I can imagine different implementation. Driver could call an API “invalidate all handles”
and OS >would close all opened handles to invalidated device. It’d allow driver to cleanup
and possibly unload immediatelly. Apps would make a cleanup when receive invalid handle error.
Unreasonable approach…
The very idea of keeping a reference to an object is to tell it that it cannot go away because someone needs it - it knows how many open references to it are held, but it does not have to know identities of
its clients. It is process’s responsibility to keep track of those to whom it has open references, and release them when it does not need them any more or gets terminated. This model is really reasonable and convenient . What you propose to do is to make things work the other way around - you want to make an object responsible for tracking all open references to itself which is inefficient and cumbersome approach that makes some things (for example, handle duplication) rather problematic. Therefore, the existing model is much more reasonable - I don’t see any reason why it should get changed…
Anton Bassov
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, March 25, 2008 9:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problemI am positive that the window receiving notifications still
works, the Bluetooth helper service uses this technique to
receive notification messages
OK, I’ll ask them what was the exact problem. I’m sure it was serious
because we spent few hours designing a new interface just for this
purpose.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Tuesday, March 25, 2008 10:03 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile() handle problemThe very idea of keeping a reference to an object is to tell
it that it cannot go away because someone needs it - it knows
how many open references to it are held, but it does not have
to know identities of
its clients. It is process’s responsibility to keep track of
those to whom it has open references, and release them when
it does not need them any more or gets terminated. This model
is really reasonable and convenient .
Sure. But we speak about the case when the resource disappears and can’t
be used anymore. From app point of view any access to the handle in this
state leads to an error. Returned by driver which waits until all apps
close their handles so it can be finally unloaded.
What you propose to do
is to make things work the other way around - you want to
make an object responsible for tracking all open references
to itself which is inefficient and cumbersome approach that
makes some things (for example, handle duplication) rather
problematic.
Problematic but possible. OS could, for example, search handle tables.
Well, I see. You mean also pointer references. In this model only
handles could be allowed. From object point of view nothing would
change; references would disappear when handles are closed no matter if
handle owner or OS (when driver ask it) does it. Handle owner would also
see it similarly as now. Resource disappeared so any access to the
handle leads to an error. HW error or invalid handle, who cares.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> Problematic but possible. OS could, for example, search handle tables. Well, I see. You mean also pointer > references. In this model only handles could be allowed.
There is no problem with maintaining “referee’s” list - instead of simply incrementing reference on an object, the system could add caller’s EPROCESS to the list of processes that have an outstanding reference to an object in either pointer or reference form. The question is how the OS has to inform the processes that a given object is about to get deleted. The only possible option is APC, so that the target process has to register a callback with the OS. At this point we have a logical question arises:
What is the reason to inform the process that a given object got invalidated via a callback if it is going to find it out when it tries to access it anyway???
Although technically there is no problem with doing all that whatsoever, it just gives absolutely unnecessary headache to the processes, especially when it comes to duplicating handles - consider the scenario when object gets deleted after process X duplicated a handle to it into the process Y but before process Y has registered a notification callback for a given object. Now compare all that to the existing reference counting scheme, and you will see that the existing scheme is so much more reasonable…
Anton Bassov
Many thanks to all of you for the help and interest.
Vista device change notification problem:
FWIW I found our 1394 application stopped receiving devce change
notifications from our driver when we changed to Vista. Luckily our timeout
strategy kept things working until we noticed the delay and started to
investigate. I tried update to Vista SP1 and notifications started working
again. Therefore I would suspect that Vista pre SP1 may fail to send
notifications, or at least may delay them beyond the 5 second timeout period
we were using.
Mike
----- Original Message -----
>>>>>>>>>
Really? My user mode coworkers informed me this was changed in Vista. At
least our library which received notifications via window stopped
working. I’m not quite sure, thought. Maybe window could be created but
received no notifications. Or even function returned OK but no window
was created. Anyway, they had to implement different way how to receive
notifications and I’m sure they wouldn’t do it if not absolutely
necessary
Second,
your ControlHandlerEx can receive device change notifications
by registering with your service’s handle.
This is what I meant by the other way.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> I have noticed that if an app has a handle to my driver, the driver won’t
close even
when the device is removed from the machine.
only once CloseHandle() is called the driver is properly closed.Is this the expected behavior?
Yes.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>Your application must register for notifications on the file handle it has
opened to
be notified of the device being surprise removed. This requires a window.
…or being a service.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
>Problematic but possible. OS could, for example, search handle tables.
Exactly so. FSDs do exactly this on dismount.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Wednesday, March 26, 2008 3:18 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] CreateFile() handle problem> Problematic but possible. OS could, for example, search
handle tables. Well, I see. You mean also pointer >
references. In this model only handles could be allowed.There is no problem with maintaining “referee’s” list -
instead of simply incrementing reference on an object, the
system could add caller’s EPROCESS to the list of processes
that have an outstanding reference to an object in either
pointer or reference form. The question is how the OS has
to inform the processes that a given object is about to get
deleted. The only possible option is APC, so that the target
process has to register a callback with the OS. At this point
we have a logical question arises:What is the reason to inform the process that a given object
got invalidated via a callback if it is going to find it out
when it tries to access it anyway???
Eh? I never said processes should be informed by OS about object
deletion. It is a problem you invented and finally found it is no
problem 
What I said was OS itself would close handles, invalidate entries in
handle table which’d be finally freed when handle owner closes them.
You’re right current implementation is correct and works. What I see as
a problem is the dependence of kernel modules on user mode apps
behaviour. Driver can’t commit suicide until all apps close all handles.
What I described would allow to make a cut and leave apps alone with
their handles. Which are useless in any case. It’d solve problem with
device change notification which is cumbersome at least.
Anyway, it is academic discussion. I only wanted to show Don current
design isn’t the only possible.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, March 25, 2008 9:52 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] CreateFile() handle problemI am positive that the window receiving notifications still
works, the Bluetooth helper service uses this technique to
receive notification messages
OK, I asked what was the problem. Nobody remembered exactly It seems
that to create window from service it has to be marked as interactive.
Which became problematic at Vista for normal installer process. Also,
coworkers were under impression this is becoming obsolete and may
disappear with the next OS or even SP version. Probably because of docs
or some other info from MS. Finally, it seems the main reason for the
change were power broadcasts and not device change notifications.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim
S. Shatskih
Sent: Wednesday, March 26, 2008 8:14 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] CreateFile() handle problem>Problematic but possible. OS could, for example, search
handle tables.Exactly so. FSDs do exactly this on dismount.
Interesting. Can you be more specific? I can’t find it quickly in
FastFat sources. Thanks.
(BTW, I see at Vista every dismount is forced dismount but don’t see
handle table searching)
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]