Serious problem with IO manager and device removal

Hi All
Scenario:
i)PnP NIC PcCard USB driver with an IO manager interface created with
NdisMRegisterDevice().

ii)Application opens device with CreateFile() and gets a valid handle.

iii) Stop NIC driver with Safely Remove Hardware. (Driver Halt
function gets called and devext is freed)

iv) Application calls DeviceIoControl() on the STILL VALID HANDLE.

v) NIC driver image stil in memory, so IOCTL handler called which
refgerences the now invalid devext.

vi) CRASH.

Now, to quote the DDK: "Note that, if a handle to the device object
created with NdisMRegisterDevice is open, the driver that created the
device object cannot be unloaded."

Oh yeah, even NdisMDeregisterDevice() returns 0 if an application
still has the handle open.

And further: "Before opening a handle to the device object, a user-mode
application should therefore register for device event notification,
specifying GUID_NDIS_LAN_CLASS as the interface class GUID. On
receiving a DBT_DEVICEQUERYREMOVE device event for the device object,
the application should close the handle"


So it is up to the good behaviour of an application to controlll wether
the kernel crashes or not. Hmmm not a very good idea.

I suggest the IO manager returns INVALID_HANDLE_VALUE if the device got
unloaded and an app calls an IO manager function on it.

Don
Fri May 27 08:07:01 CDT 2005

So your create a second device object, and have an application open it. Now
you unload the hardware for the NIC's device object and get pissed that when
your driver gets a request from the second device object and tries to access
resources from the NIC yoiu crash? Sorry, if you are using the device
object from NdisMRegisterDevice to access things that depend on the NIC's
path, you need to have code in the MiniportHalt routine or the PNP support
stuff to flag that the world is gone, so requests to your second device
object don't go hitting stuff that is no longer there.

This is not a bug in the I/O manager, this is a poorly written driver.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply



<m.sykes@option.com> wrote in message
news:1117184813.539732.15190@g14g2000cwa.googlegroups.com...
> Hi All
> Scenario:
> i)PnP NIC PcCard USB driver with an IO manager interface created with
> NdisMRegisterDevice().
>
> ii)Application opens device with CreateFile() and gets a valid handle.
>
> iii) Stop NIC driver with Safely Remove Hardware. (Driver Halt
> function gets called and devext is freed)
>
> iv) Application calls DeviceIoControl() on the STILL VALID HANDLE.
>
> v) NIC driver image stil in memory, so IOCTL handler called which
> refgerences the now invalid devext.
>
> vi) CRASH.
>
> Now, to quote the DDK: "Note that, if a handle to the device object
> created with NdisMRegisterDevice is open, the driver that created the
> device object cannot be unloaded."
>
> Oh yeah, even NdisMDeregisterDevice() returns 0 if an application
> still has the handle open.
>
> And further: "Before opening a handle to the device object, a user-mode
> application should therefore register for device event notification,
> specifying GUID_NDIS_LAN_CLASS as the interface class GUID. On
> receiving a DBT_DEVICEQUERYREMOVE device event for the device object,
> the application should close the handle"
>
>
> So it is up to the good behaviour of an application to controlll wether
> the kernel crashes or not. Hmmm not a very good idea.
>
> I suggest the IO manager returns INVALID_HANDLE_VALUE if the device got
> unloaded and an app calls an IO manager function on it.
>

fat_boy
Fri May 27 09:01:54 CDT 2005

So what do you suggets I call from MiniportHalt?
NdisMDeregisterDevice()?

I am doing that already (it returns success) and it doesnt tell the IO
manager that the device is destroyed as the code in memory still gets
IO calls from the app.

Even if the IO call handler checked the for a null 'pAdapter' there is
no guarantee that the memory that happens to still have the sys file in
it isnt going to get overwritten or reused at some stage. Then, the IO
manager wil call some completely arbitrary code with an IO request.

As the documentation says, it is up to the app to register for device
removal notification, and if it doesnt, it will crash the kernel if it
does an IO on the gone device. Like I said, not a good idea.

Unless you have knowledge of any other undocumented function which
tells the IO manager that the device has really gone for good and not
to forward IO calls to the dispatch routine I will continue to call
this a bug in the IO manager as it clearly does not respond correctly
to NdisMDeregisterDevice. Or, if this is intentional, then the fact
that a poorly written app can crash the kernel is also a bug. So a bug
it is.

Don
Fri May 27 09:17:52 CDT 2005

You have it wrong, the application has an open handle to the device, the
driver will not get unloaded, this is in the documentation for
NdisMRegisterDevice. So what you need to do is return an error on all calls
to second device object once the halt function has been invoked. Also you
need to make your application smart enough to close the handle some day.

This will not crash the kernel, unless your driver is stupid enough to rely
on something from the NIC path to be there without testing for its
existance.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply





"fat_boy" <m.sykes@option.com> wrote in message
news:1117201497.898664.11310@g14g2000cwa.googlegroups.com...
> So what do you suggets I call from MiniportHalt?
> NdisMDeregisterDevice()?
>
> I am doing that already (it returns success) and it doesnt tell the IO
> manager that the device is destroyed as the code in memory still gets
> IO calls from the app.
>
> Even if the IO call handler checked the for a null 'pAdapter' there is
> no guarantee that the memory that happens to still have the sys file in
> it isnt going to get overwritten or reused at some stage. Then, the IO
> manager wil call some completely arbitrary code with an IO request.
>
> As the documentation says, it is up to the app to register for device
> removal notification, and if it doesnt, it will crash the kernel if it
> does an IO on the gone device. Like I said, not a good idea.
>
> Unless you have knowledge of any other undocumented function which
> tells the IO manager that the device has really gone for good and not
> to forward IO calls to the dispatch routine I will continue to call
> this a bug in the IO manager as it clearly does not respond correctly
> to NdisMDeregisterDevice. Or, if this is intentional, then the fact
> that a poorly written app can crash the kernel is also a bug. So a bug
> it is.
>

fat_boy
Fri May 27 09:43:16 CDT 2005

NB: The initialize func calls NdisMRegisterDevice with a device name
like GGGGGn, where n is 0 to 9. So the first time it is loaded it
creates "DosDevices\GGGG0".

DDK: "Note that, if a handle to the device object created with
NdisMRegisterDevice is open, the driver that created the device object
cannot be unloaded"

But its MiniportHalt function gets called and NdisMDeregisterDevice
returns success while an app still has the device open?

And if the card is reinserted the device name created is
"DosDevices\GGGG0" again. Implying the old device name was at least de
registered even if its dispatcher wasnt.

So your solution is for the dispatcher function to maintain a global
variable to indicate wether it should error any IO requests because
"The device extension for an object created with NdisMRegisterDevice is
reserved for use by NDIS and cannot be used by the driver"

And the next time the NIC driver is loaded, and NdisMDeregisterDevice
succeeds with the SAME device name, does the dispatcher addess get re
registered with the IO manager at the SAME address, and does the driver
get loaded to the SAME address, and does the gloabal flag get loaded at
the SAME address, and will the IO calls from the ap on the OLD device
go to the NEW device dispatcher?

NdisMDeregister device shoud either does what it says it does or it
should return error and keep the whole driver in memory. (And stop the
user removing the card). Uh, OK, perhaps NdisMDeregisterDevice should
just de register the device and the IO manager should error all Irps on
that device back to the app.

Don
Fri May 27 10:07:36 CDT 2005

Comments inline:

"fat_boy" <m.sykes@option.com> wrote in message
news:1117204996.430635.77090@f14g2000cwb.googlegroups.com...
> NB: The initialize func calls NdisMRegisterDevice with a device name
> like GGGGGn, where n is 0 to 9. So the first time it is loaded it
> creates "DosDevices\GGGG0".
>
> DDK: "Note that, if a handle to the device object created with
> NdisMRegisterDevice is open, the driver that created the device object
> cannot be unloaded"
>
> But its MiniportHalt function gets called and NdisMDeregisterDevice
> returns success while an app still has the device open?

MiniportHaltr is called because the last NIC went away, and there are no
applications having the NIC open. This has nothing to do with device
objects NdisMRegisterDevice created.


> And if the card is reinserted the device name created is
> "DosDevices\GGGG0" again. Implying the old device name was at least de
> registered even if its dispatcher wasnt.

If you have a well designed USB device it has a unique ID, and yes the
system will create the same NIC instance. If you use something based on the
NIC id to generate the ID for NdisMRegisterDevice then it will try to create
the same name.

> So your solution is for the dispatcher function to maintain a global
> variable to indicate wether it should error any IO requests because
> "The device extension for an object created with NdisMRegisterDevice is
> reserved for use by NDIS and cannot be used by the driver"

Yes I find it a pain, that NdisMRegisterDevice doesn't provide at least some
area for a device extension the driver writer could use. But this is a
design issue, not a bug.

> And the next time the NIC driver is loaded, and NdisMDeregisterDevice
> succeeds with the SAME device name, does the dispatcher addess get re
> registered with the IO manager at the SAME address, and does the driver
> get loaded to the SAME address, and does the gloabal flag get loaded at
> the SAME address, and will the IO calls from the ap on the OLD device
> go to the NEW device dispatcher?

I doubt it is succeeding, since the device still will exist unless your
application closed its handles. If the application closed its handles then
the driver will be unloaded, and the reloaded when a NIC reappears.

> NdisMDeregister device shoud either does what it says it does or it
> should return error and keep the whole driver in memory. (And stop the
> user removing the card). Uh, OK, perhaps NdisMDeregisterDevice should
> just de register the device and the IO manager should error all Irps on
> that device back to the app.

The whole driver is kept in memory until the NdisMDeregister device
succeeds, i.e as you said if there are outstanding handles it returns an
error and the driver is still in memory.



--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply

Maxim
Sat May 28 15:31:15 CDT 2005

> Yes I find it a pain, that NdisMRegisterDevice doesn't provide at least some
> area for a device extension the driver writer could use. But this is a
> design issue, not a bug.

The whole NdisMRegisterDevice is a design issue IMHO. Why not extend the app's
facilities of accessing the custom OIDs in the driver? Or invent
IOCTL_NDIS_MINIPORT same way as IOCTL_SCSI_MINIPORT, to be sent to the NIC's
devnode itself and not to the global device object?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

fat_boy
Mon Jun 06 04:16:06 CDT 2005

>I doubt it is succeeding, since the device still will exist unless your
>application closed its handles. If the application closed its handles then
>the driver will be unloaded, and the reloaded when a NIC reappears.

Wrong. NdisMRegisterDevice IS suceeding with the SAME device name
despit the application not closing the old device handle.

>The whole driver is kept in memory until the NdisMDeregister device
>succeeds, i.e as you said if there are outstanding handles it returns an
>error and the driver is still in memory.

Wrong. NdisMDeregister returns success while the app still has the
handle open. I said it SHOULD return an error and keep the whole
driver in memory. It doesnt.


Like I said, NdisMDeregister does NOT de register the device with the
IO manager. If it did, the IO manager would not forward Irps to its
dispatcher.

And on next driver load, NdisMRegisterDevice suceeds with the SAME
device name. And puts a new dispatcher in memory, despite the old one
still being there.

You have to agree, these functions all sound buggy and leave the kernel
open to BSODing because an app doesnt close a handle.

Eliyas
Tue Jun 14 10:27:35 CDT 2005

Think of NdisMRegisterDevice as IoCreateDevice and NdisMDeregisterDevice as
IoDeleteDevice.

> Wrong. NdisMRegisterDevice IS suceeding with the SAME device name
> despit the application not closing the old device handle.

Impossible.


> Wrong. NdisMDeregister returns success while the app still has the
> handle open. I said it SHOULD return an error and keep the whole
> driver in memory. It doesnt.
>
> Like I said, NdisMDeregister does NOT de register the device with the
> IO manager. If it did, the IO manager would not forward Irps to its
> dispatcher.
>

NdisMDeregisterDevice does delete the device but if there are outstanding
references (handles), it wouldn't get deleted.
In the debugger, check the state of deviceobject using !object command and
you will see it's in delete-pending state.

> And on next driver load, NdisMRegisterDevice suceeds with the SAME
> device name. And puts a new dispatcher in memory, despite the old one
> still being there.

The fact the driver is getting uloaded means the deviceobject doesn't exists
anymore. So your theory about old one being there is completely bogus.
>
> You have to agree, these functions all sound buggy and leave the kernel
> open to BSODing because an app doesnt close a handle.
>

There is nothing wrong with these functions. As I said, these functions
directly map to Io functions and they have been there ever since NT OS.

Alexander
Tue Jun 14 23:25:23 CDT 2005

I think that NDisMDeregisterDevice doesn't actually care whether there are
open handles to the control DEVICE_OBJECT. It's object manager keeps the
device object half-alive after IoDeleteDevice. That object is NOT in PNP
stack, this is why there is no delayed REMOVE_DEVICE protection against
deleting a device with open handles. The device name seems already
invalidated in the delete-pending state, this is why it may be possible to
create another devobj with the same name.

"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
news:elbkXXPcFHA.720@TK2MSFTNGP15.phx.gbl...
>>
>
> NdisMDeregisterDevice does delete the device but if there are outstanding
> references (handles), it wouldn't get deleted.
> In the debugger, check the state of deviceobject using !object command and
> you will see it's in delete-pending state.
>

fat_boy
Thu Jun 16 03:16:29 CDT 2005

>> Wrong. NdisMRegisterDevice IS suceeding with the SAME device name
>> despit the application not closing the old device handle.

> Impossible.

I am not lying, nor am I mistaken.

Scenario:
Test app has done a CreateFile on the NdisRegistered device.
Does IO.
Safe Remove USB. MiniportHalt gets called which calls NdisDeRegister
device which returns success.
Remove device from laptop.

Test app can still do IO and the dispatcher code still gets hit
producng trace output.

Insert card.
Ndis driver does a NdisRegisterDevice with the same (old) name. func
suceeds.
Test app can still do IO on the device, the dispatcher is there and
complete functional;ity is restored.




>The fact the driver is getting uloaded means the deviceobject doesn't exists
>anymore. So your theory about old one being there is completely bogus

So how come the dispatcher function still gets IRPs after MiniportHalt
got called?

Eliyas
Thu Jun 16 12:05:30 CDT 2005

So the driver isn't actually unloaded. It's stuck in memory because the app
has a open handle to the previous instance. When you plugged the device
again, a new instance got enumerated. What's surprising to me is that the
system is able to create another deviceobject with the same name when the
previous one exists. I guess as Alexander pointed out, when it's in
delete-pending state, the object is removed from the object manager
directory so there is no name collision. I will verify this to make sure
that's indeed the case.

To resolve your problem, what you need to do is register for PNP
notification on the NDIS interfaces and close the handle to control-device
created by NdisMRegisterDevice when you get removal notification. I have
discussed this technique several times in the group. The testapp as part of
NETVMINI sample in Server 2003 SP1 DDK clearly demonstrates how to do this.


--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

fat_boy
Fri Jun 17 06:17:35 CDT 2005

Hi

Thanks for the input on this.

The surprising thing is that although the app has the handle open,
NdisDeRegisterDevice returns success (called in miniporthalt). And the
driver goes on to unload. However, like you say, at least the
disapatcher is left in memory.

What scares me is that when the device is reinserted, and a new device
created with the same name, is that new devices dispatch put in memory
at the same address as the old devices dispatcher. If not, then what
happens to IO from the app that still has access to the old dispatcher.

Yes, as the DDK says, the app needs to register for device removal so
it can close the handle. But, like I said in the first posting on this
thread, the onus is on the app to be well written, or, it can bring
down the kernel.

So, the driver has to maintain a global flag indicating wether the
device got unloaded. Then in the still present dispatcher, if this flag
is set, just complete tthe IO with invalid device state or some such.

Also there needs to be a way to reference the ndis adapter device
extension from the device created by NdisRegisterDevice(). But I know
that this is an issue which is under consideration by MS.

fat_boy

Pavel
Fri Jun 17 08:46:06 CDT 2005

"fat_boy" <m.sykes@option.com> wrote in message news:1119007055.148761.112170@z14g2000cwz.googlegroups.com...
> .......
> What scares me is that when the device is reinserted, and a new device
> created with the same name, is that new devices dispatch put in memory
> at the same address as the old devices dispatcher.
>If not, then what
> happens to IO from the app that still has access to the old dispatcher.

If, as Eliyas wrote, the driver was NOT unloaded, and a new instance has been
added (btw, it must fail if the device has a "serial number'!) -
the driver entry point stays in place, it was not deleted neither moved.

Device objects created by NdisRegisterDevice are *not* associated with
instances of NDIS miniports, they belong to the *whole* driver.
So, it is quite possible that MiniportHalt will not interfere with these
device objects.

> Yes, as the DDK says, the app needs to register for device removal so
> it can close the handle. But, like I said in the first posting on this
> thread, the onus is on the app to be well written, or, it can bring
> down the kernel.

No, a good driver will never allow any app to bring the kernel down.

Perhaps the point here is that NdisRegisterDevice is kind of old hack.
NDIS drivers are not supposed to talk directly to usermode apps or
expose any entry points to usermode.
The proper communication channels between an app and NDIS driver
are either NDIS OIDs or WMI.
I don't quite comprehend the logic of NDIS team - they are going
to close the old good IOCTL path (QUERY_GLOBAL_STATS) but leave
NdisRegisterDevice path intact ?

Anyway, when NDIS driver exposes a device interface to usermode,
it takes additional responsibility of a high level driver.
It therefore must have extra functionality that is not defined by NDIS,
but is common in "generic" WDM world.

In the worst case - the driver can fail adding the second instance, and/or
block it's unload until all handles are closed (so the device may not work
aftter re-insertion) but the system will not crash.

> Also there needs to be a way to reference the ndis adapter device
> extension from the device created by NdisRegisterDevice(). But I know
> that this is an issue which is under consideration by MS.

Again, the NdisRegisterDevice device does not belong to a specific miniport instance,
this is why it has no direct association with the device extensions of the miniport devices.
At least this is situation in ndis 5.x. Haven't yet tried this in ndis 6.

Hope Alireza and Eliyas can clarify this issue, it is very interesting, as far as NdisRegisterDevice
will exist in LH.

Regards,
--PA

Alexander
Fri Jun 17 09:34:23 CDT 2005

New instance will be created no matter whether the device has serial number
or not. When a device is unplugged, the PDO is already reported as gone.

"Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
news:%23IDl8N0cFHA.3012@tk2msftngp13.phx.gbl...
> "fat_boy" <m.sykes@option.com> wrote in message
> news:1119007055.148761.112170@z14g2000cwz.googlegroups.com...
>
> If, as Eliyas wrote, the driver was NOT unloaded, and a new instance has
> been
> added (btw, it must fail if the device has a "serial number'!) -
> the driver entry point stays in place, it was not deleted neither moved.
>

Pavel
Fri Jun 17 10:05:21 CDT 2005

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message news:epEEum0cFHA.2384@TK2MSFTNGP10.phx.gbl...
> New instance will be created no matter whether the device has serial number
> or not. When a device is unplugged, the PDO is already reported as gone.

You're right... if the old dev object is in zomby state,
there is no obstacle to make up a new one.
And since the NdisRegisterDevice object is not associated with any
PDO instance, pinning it down won't prevent coming and going of PDOs.
The situation is even more weird... a mix of PnP and legacy devices in one glass,
like a bloody mary... you can pour and sip the vodka layer several times, while
the tomato juice stays in the bottom :)

> "Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
> news:%23IDl8N0cFHA.3012@tk2msftngp13.phx.gbl...
> > "fat_boy" <m.sykes@option.com> wrote in message
> > news:1119007055.148761.112170@z14g2000cwz.googlegroups.com...
> >
> > If, as Eliyas wrote, the driver was NOT unloaded, and a new instance has
> > been
> > added (btw, it must fail if the device has a "serial number'!) -
> > the driver entry point stays in place, it was not deleted neither moved.
> >
>
>

Eliyas
Fri Jun 17 14:19:45 CDT 2005

Yes, a new instance can be enumerated if the previous instance is still in a
surprise-remove pending state.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

"Alexander Grigoriev" <alegr@earthlink.net> wrote in message
news:epEEum0cFHA.2384@TK2MSFTNGP10.phx.gbl...
> New instance will be created no matter whether the device has serial
> number or not. When a device is unplugged, the PDO is already reported as
> gone.
>
> "Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
> news:%23IDl8N0cFHA.3012@tk2msftngp13.phx.gbl...
>> "fat_boy" <m.sykes@option.com> wrote in message
>> news:1119007055.148761.112170@z14g2000cwz.googlegroups.com...
>>
>> If, as Eliyas wrote, the driver was NOT unloaded, and a new instance has
>> been
>> added (btw, it must fail if the device has a "serial number'!) -
>> the driver entry point stays in place, it was not deleted neither moved.
>>
>
>

Alexander
Fri Jun 17 23:23:25 CDT 2005

Assuming that the driver's writer was careful and released the symbolic
links (including interfaces) at surprise removal time. Otherwise the new
instance may not be able to create the links or enable interfaces.

"Eliyas Yakub [MSFT]" <eliyasy@online.microsoft.com> wrote in message
news:e6XfGG3cFHA.3504@TK2MSFTNGP12.phx.gbl...
> Yes, a new instance can be enumerated if the previous instance is still in
> a surprise-remove pending state.
>
> --
> -Eliyas
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx
>
> "Alexander Grigoriev" <alegr@earthlink.net> wrote in message
> news:epEEum0cFHA.2384@TK2MSFTNGP10.phx.gbl...
>> New instance will be created no matter whether the device has serial
>> number or not. When a device is unplugged, the PDO is already reported as
>> gone.
>>
>> "Pavel A." <pavel_a@NOwritemeNO.com> wrote in message
>> news:%23IDl8N0cFHA.3012@tk2msftngp13.phx.gbl...
>>> "fat_boy" <m.sykes@option.com> wrote in message
>>> news:1119007055.148761.112170@z14g2000cwz.googlegroups.com...
>>>
>>> If, as Eliyas wrote, the driver was NOT unloaded, and a new instance has
>>> been
>>> added (btw, it must fail if the device has a "serial number'!) -
>>> the driver entry point stays in place, it was not deleted neither moved.
>>>
>>
>>
>
>

Eliyas
Mon Jun 20 11:24:34 CDT 2005

That's why we have this tip:
http://www.microsoft.com/whdc/driver/tips/km-basics.mspx#EHAA

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

fat_boy
Tue Jun 21 04:10:22 CDT 2005

How does that work with an interface created by NdisRegisterDevice()

Eliyas
Fri Jun 24 01:31:22 CDT 2005

As I said earlier, NdisMRegisterDevice is functionally equivalent to
IoCreateDevice & IoCreateSymbolicLink. So all the WDM rules for these
functions apply to NdisMRegisterDevice.

If you look at the netvmini sample driver and it's pnp friendly test app
that talks to the control-device, it will become all clear to you.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

fat_boy
Fri Jun 24 03:13:30 CDT 2005

Yes, I use this technique in a service that controls the connection of
the UMTS card to a particular network.

But, like I said, the onus is on the application to be well written,
and close the handle. If it doesnt, it can still send IO to the
driver, and this compromises the kernel.

If the driver writer knows that NdisDeregister device will leave the
dispatcher in memory, then code can be put in the dispatcher to handle
this scenario.

Since the driver canot control wether the hardware is there or not,
there is little point failing the driver unload or de registering of
the device in some way. The driver just has to accept that it can
continue to get IRPs long after its device got deleted because the
driver has no idea what application has opened a handle on it and how
well it is written.

Perhaps create file should register a call back function to
automatically get device notification. At least it would bring this
problem to application writers atentions.


What I cant understand is why the IO manager does not reject IO from
an application after its device got deleted. Even if the app has a
handle open on that now gone device.

IE, how come that handle is still valid for IO when the device is
deleted.