Re: NDIS IM & NdisMDeregisterDevice


<soviet_bloke@xxxxxxxxxxx> wrote in message news:1166048095.933955.266440@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas,

To be honest, I just don't really understand what the OP's problem is
all about - it seems to be just non-existent one, at least to me.

Once open handle does not prevent Unload() routine to be called, the
driver just should not be bothered about the handle. If handle is still
open after Unload() routine gets called, it will become simply unusable
- any call, apart from CloseHandle(), that takes this handle as an
argument, will fail in "civilized and orderly manner", i.e. with an
error code, and, at this point, the application will know that driver
is already gone

What is the problem here????

I am not sure either.

Probably a coding bug that is simply "invisible" until that magic moment when it slaps you in the face to remind you that your're not perfect.

Thomas



Anton Bassov



Thomas F. Divine wrote:
"TarasCo" <taralex@xxxxxxxxx> wrote in message
news:1166022733.452367.16130@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> As I know, i should call NdisMDeregisterDevice in MiniportHalt routine
> when last miniport is halted (
> http://groups.google.ru/group/comp.os.ms-windows.programmer.nt.kernel-mode/browse_thread/thread/1d8ee27725dd24c2/b8e565e360364c61?lnk=st&q=NdisMDeregisterDevice+Unload&rnum=1&hl=ru#b8e565e360364c61)
> Then my driver will be unloaded. But if client app has opened handle on
> my device, driver is still in memory. I can understand why. When app
> close the last handle i suggest calling driver Unload routine, but
> driver is still referenced. I can notify app about stop, but I think
> when app handle such notify it will be late. What sould I do?
>
You must find a way to inform the app that the binding has gone away.

You can create an asynchronous "notification" IOCTL that the application
calls. The driver would pend the IRP for this IOCTL indefinitely. Basically
until some event occurs that requires the driver to notify the app. When
such an event occurs the driver would complete the IRP providing the detains
of the "event" in some output buffer structure of your invention.

The application would periodically test the pended IOCTL to become aware of
the notification from the driver. I believe the NDISPROT sample may include
an illustration of some sort of notification callback scheme.

In user mode you could also use asynchronous procedure callback method to
have a routine in your application be called when the driver completes the
IRP. Using APC's does require the systematic use of user-mode wait
operations in the "alertable" state; overlooking this need will make APCs
fail to work.

Alternatively, and possibly simpler, you could just have your application
poll the handle on each adapter periodically. Just have some sort of IOCTL
(e.g., fetch some status or statistics of your invention). When the app
makes such a call on an adapter that has become unbound, fail the call with
invalid handle status. When app sees invalid handle returned form such a
keep-alive, require it to close all handles.

Thomas F. Divine


.

Relevant Pages

  • Re: Kernel mode to user mode
    ... where they make sense in the context of using IoCtls for data passing also. ... An app passes an IoCtl to a driver initiating a series of tests that will ...
    (microsoft.public.development.device.drivers)
  • Help in NDIS Driver
    ... I am writing virtual network i/f driver for a PCI card. ... This driver also requires a IOCTL dispatch routine for few device ... The IOCTL routines used to read / write data from / to the PCI card ... and set a completion routine for the IRP. ...
    (microsoft.public.development.device.drivers)
  • Re: SD card and File System in WinCE 5....?
    ... Because when unload/reload SD client driver, ... So if App is running,suspend and then resume the system, if we unload and ... App will pop a message to notify user that the SD card is removed. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: NDIS IM & NdisMDeregisterDevice
    ... Once open handle does not prevent Unloadroutine to be called, ... driver just should not be bothered about the handle. ... But if client app has opened handle on ... The driver would pend the IRP for this IOCTL indefinitely. ...
    (microsoft.public.development.device.drivers)
  • [RFC] dev_acpi: device driver for userspace access to ACPI
    ... The basic concept of operation is that the ioctl operates on the ACPI ... The sample, proof-of-concept app, is called acpitree. ... You can find the driver and sample app here: ...
    (Linux-Kernel)
Loading