Filter driver seems to miss IRPs for extant file objects

NTDEV
1

I have a TDI filter driver, which intercepts IRPs sent to \Device\Tcp. In this particular case restarting the system after installing the driver is generally undesirable, so the driver may run for an unknown period before the first reboot.

I observe that, my filter driver does not receive IRPs for extant TDI connection and address objects (objects that existed at the time the driver was installed). In particular, I do not see TDI_SEND calls for extant TDI connections. However, I seem to receive IRP_MJ_CLOSE and IRP_MJ_CLEANUP for such objects.

My question is: is this expected behavior, or I have a problem with my filter driver? Is there another way (other than using a hooking driver approach) to make sure I receive all IRPs for extant TDI connection and address objects.

Thanks,
–aydan

2


My question is: is this expected behavior

Yes.


Is there another way (other than using a hooking driver approach) to make
sure I receive all IRPs for extant TDI connection and address objects.

No.

TDI clients (including AFD) get a device object pointer to use to dispatch
IRPs to \Device\Tcp at open time. In the layered I/O model it is generally
a really bad idea to try to filter I/O for a file-object based activity like
TDI if you have not observed the entire life-cycle of the file object
starting with IRP_MJ_CREATE (but some do it).

Even if you could get TDI_SEND IRPs, you are very unlikely to see the
receive side as most clients use the event callbacks for receive (at least
partially). In other words, even a dispatch table hook on TCPIP.SYS is not
going to get you the receive path since you will not likely see the IRPs
which set the event handlers.

Most systems that rely on TDI filtering (either by device attachment or
dispatch hooking) live with the reality that there will be endpoints that
are ‘unknown’ because the filter did not observe the IRP_MJ_CREATE.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Tuesday, September 16, 2008 6:01 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Filter driver seems to miss IRPs for extant file objects

I have a TDI filter driver, which intercepts IRPs sent to \Device\Tcp. In
this particular case restarting the system after installing the driver is
generally undesirable, so the driver may run for an unknown period before
the first reboot.

I observe that, my filter driver does not receive IRPs for extant TDI
connection and address objects (objects that existed at the time the driver
was installed). In particular, I do not see TDI_SEND calls for extant TDI
connections. However, I seem to receive IRP_MJ_CLOSE and IRP_MJ_CLEANUP for
such objects.

My question is: is this expected behavior, or I have a problem with my
filter driver? Is there another way (other than using a hooking driver
approach) to make sure I receive all IRPs for extant TDI connection and
address objects.

Thanks,
–aydan

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

3

David,

Thank you for the response. I needed someone to confirm my understanding/observations.

We have had some luck in intercepting event handlers even if we missed their initial setting. We do this by some dynamic reverse-engineering to find the locations where handlers and contexts are stored, and then we use some assembly to ensure that we set our own handlers atomically. This works fine for the connect/disconnect handlers, but for the receive handlers we get calls only for non-extant TDI connections. It seems that tcpip.sys caches separately the callbacks for each connection object, instead of always reading them from the address object. As soon as we create a new connection object associated with an extant address object, we start seeing the receive callbacks.

Thanks again,

–aydan