NDIS 6.20 filter driver with device object and unload handling.

Good day,

I have an issue with my NDIS 6.20 filter driver which register new device object using NdisRegisterDeviceEx function.
All flows goes fine, load/unload of device works fine, but when there is pending requests to my ioctl interface present, the filter failed to unload.
This is correct, but the question is: How to get notification in my filter that NDIS trying to remove filter from NDIS stack? In such case I will internally cancel all pending request and will get driver unloaded.
Event more, not clear to me, if user mode app open pending requests to my filter device object and wait for some event, and I try to uninstall filter, the user space app failed to open handle to registered device object with file not found error, after uninstall operation, however in my filter I have not called NdisDeregisterDeviceEx, and driver still wait for pending requests to be completed.

Hi,

You can use DetachHandler from NDIS_FILTER_DRIVER_CHARACTERISTICS structure to get notified when NDIS removes a filter instance from the filter stack.

You can look at the ndis\filter sample from DDK for more details.

Does I understand correctly, if my filter driver reference count (Attach/Detach) in Detach function reach zero than this indicate that I can safely perform all cleanups, deregister user IO device object and driver always be unloaded by system using subsequent call to DriverUnload. And no future call to Attach will be performed in this situation. I am right?

In addition, regarding ndis\filter sample. This sample also hangs with the same effect if there pending IO occurred to user IO device object. Because it deregister device object in FilterUnload, which was never be called until pending IO present.

Filter Detach is called for every stack in which the driver was. If you have 3 adapters on which your filter was bound you will be called 3 times in Filter Detach routine. You can safely perform the cleanup after last detach.

I don’t clearly understand your scenario, but you can maintain a state and you can deny any further user IO (IRP_MJ_CREATE, IRP_MJ_DEVICE_CONTROL, IRP_MJ_INTERNAL_DEVICE_CONTROL) after the last Filter Detach is called.