Another serious problem about TDI Filter driver

Another serious problem about TDI-filter driver.
When users ask to stop the filter drirver, I have to unload my TDI-Filter driver.
In my unload code, I first to check if there are still outstanding requests
.If no, I detach my filter driver from \Device\Tcp. I think this
flow is correct. But after I unload my driver and there are still
applications such ftp.exe not quit, if I do some actions such as the ftp
command ‘ls’ the system crased. Why and how to avoid this.

best regards
yours brucie

Perhaps your TDI Filter does not attach early enough. With SoftICE loaded at
boot time you can see a trace of network components being loaded. Make sure
that other TDI users are loaded after your filter.

The load order apparently differs between NT/W2K/XP.

In any case, unloading a filter driver (of any kind) is not recommended. For
sure, even components loaded after your filter may hold a reference to an
object or pointer that is somehow related to your filter.

Good luck,

Thomas F. Divine

PCAUSA - Tools & Resources For Network Software Developers
NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
http: - http:

“brucie” wrote in message news:xxxxx@ntdev…
> Another serious problem about TDI-filter driver.
> When users ask to stop the filter drirver, I have to unload my TDI-Filter
driver.
> In my unload code, I first to check if there are still outstanding
requests
> .If no, I detach my filter driver from \Device\Tcp. I think this
> flow is correct. But after I unload my driver and there are still
> applications such ftp.exe not quit, if I do some actions such as the ftp
> command ‘ls’ the system crased. Why and how to avoid this.
>
> best regards
> yours brucie
></http:></http:>

> Another serious problem about TDI-filter driver.

OKay. When you call IoDeleteDevice() in your Unload routine DDK
documentation says that

“When IoDeleteDevice is called, there cannot be any outstanding references
to the device being deleted nor any attached devices. If there are, a system
erorr occurs.”

TDIMON of SysInternals doesn’t unload its filter driver even GUI is closed.
If Mark Russinovich doesn’t know solution maybe there’s no way?

But only for debug purposes I’ll risk to give solution only for extremally
guys.

When AFD wants to send bytes he calls IoCallDriver() which calls routine
DeviceObject->DriverObject->MajorFunction[n].
Where DeviceObject is yours and nonexistant!

The solution is to replace MajorFunctions in your DriverObject with
MajorFunctions from filtered device.

/* deinitialization */
VOID
OnUnload(IN PDRIVER_OBJECT DriverObject)
{
if (g_tcpoldobj && g_tcpfltobj) {
int i;
for (i = 0; i < IRP_MJ_MAXIMUM_FUNCTION; i++)
DriverObject->MajorFunction[i] =
g_tcpoldobj->DriverObject->MajorFunction[i];
}

if (g_tcpoldobj) IoDetachDevice(g_tcpoldobj);
if (g_tcpfltobj) IoDeleteDevice(g_tcpfltobj);

}

But you shouldn’t use this way in release version. Am I right?

vlad-ntdev

When users ask to stop the filter drirver, I have to unload my TDI-Filter
driver.
In my unload code, I first to check if there are still outstanding
requests
.If no, I detach my filter driver from \Device\Tcp. I think this
flow is correct. But after I unload my driver and there are still
applications such ftp.exe not quit, if I do some actions such as the ftp
command ‘ls’ the system crased. Why and how to avoid this.