Hey,
in my application I have a filter device over \Device\Tcp which MUST be
unloaded (if possible)after a special user input. I thought before unloading
I could do a simple check on the Reference, Handle and Pointer count of the
device. If these are equal to the inital Reference, Handle and Pointer
counts and if there is no other filter device above my filter device (simply
checking MyFilterDevice->AttachedDevice!=NULL) it’s safe to unload the
filter driver.
Is that OK?
Thx 
You’ve asked this before: http://www.osronline.com/showThread.cfm?link=91956
The answer hasn’t changed in the last two months. Your proposed solution
only works if your users are OK with their systems crashing every once in a
while (and if your users are OK with that get me a list, I’d like to do all
future projects exclusively for them)
The only solution to your problem is to break your driver into two drivers.
One driver filters the TCP stack and can never unload, with a second
“functionality” driver that communicates with the filter and processes the
data.
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“ChuckN” wrote in message news:xxxxx@ntdev…
> Hey,
> in my application I have a filter device over \Device\Tcp which MUST be
> unloaded (if possible)after a special user input. I thought before
> unloading I could do a simple check on the Reference, Handle and Pointer
> count of the device. If these are equal to the inital Reference, Handle
> and Pointer counts and if there is no other filter device above my filter
> device (simply checking MyFilterDevice->AttachedDevice!=NULL) it’s safe to
> unload the filter driver.
> Is that OK?
> Thx
>
>
OK, thx.
Btw. sorry for the double post, I had that thread in my mind, but I were not
able to find it, and so I decided to repost my question…
“Scott Noone” schrieb im Newsbeitrag news:xxxxx@ntdev…
> You’ve asked this before:
> http://www.osronline.com/showThread.cfm?link=91956
>
> The answer hasn’t changed in the last two months. Your proposed solution
> only works if your users are OK with their systems crashing every once in
> a while (and if your users are OK with that get me a list, I’d like to do
> all future projects exclusively for them)
>
> The only solution to your problem is to break your driver into two
> drivers. One driver filters the TCP stack and can never unload, with a
> second “functionality” driver that communicates with the filter and
> processes the data.
>
> -scott
>
> –
> Scott Noone
> Software Engineer
> OSR Open Systems Resources, Inc.
> http://www.osronline.com
>
> “ChuckN” wrote in message news:xxxxx@ntdev…
>> Hey,
>> in my application I have a filter device over \Device\Tcp which MUST be
>> unloaded (if possible)after a special user input. I thought before
>> unloading I could do a simple check on the Reference, Handle and Pointer
>> count of the device. If these are equal to the inital Reference, Handle
>> and Pointer counts and if there is no other filter device above my filter
>> device (simply checking MyFilterDevice->AttachedDevice!=NULL) it’s safe
>> to unload the filter driver.
>> Is that OK?
>> Thx
>>
>>
>
>
>
You can search the lists here: http://www.osronline.com/page.cfm?name=search
(“unload tcp filter” brings up the previous post as the first hit)
-scott
–
Scott Noone
Software Engineer
OSR Open Systems Resources, Inc.
http://www.osronline.com
“ChuckN” wrote in message news:xxxxx@ntdev…
> OK, thx.
>
> Btw. sorry for the double post, I had that thread in my mind, but I were
> not able to find it, and so I decided to repost my question…
>
> “Scott Noone” schrieb im Newsbeitrag news:xxxxx@ntdev…
>> You’ve asked this before:
>> http://www.osronline.com/showThread.cfm?link=91956
>>
>> The answer hasn’t changed in the last two months. Your proposed solution
>> only works if your users are OK with their systems crashing every once in
>> a while (and if your users are OK with that get me a list, I’d like to do
>> all future projects exclusively for them)
>>
>> The only solution to your problem is to break your driver into two
>> drivers. One driver filters the TCP stack and can never unload, with a
>> second “functionality” driver that communicates with the filter and
>> processes the data.
>>
>> -scott
>>
>> –
>> Scott Noone
>> Software Engineer
>> OSR Open Systems Resources, Inc.
>> http://www.osronline.com
>>
>> “ChuckN” wrote in message news:xxxxx@ntdev…
>>> Hey,
>>> in my application I have a filter device over \Device\Tcp which MUST
>>> be unloaded (if possible)after a special user input. I thought before
>>> unloading I could do a simple check on the Reference, Handle and Pointer
>>> count of the device. If these are equal to the inital Reference, Handle
>>> and Pointer counts and if there is no other filter device above my
>>> filter device (simply checking MyFilterDevice->AttachedDevice!=NULL)
>>> it’s safe to unload the filter driver.
>>> Is that OK?
>>> Thx
>>>
>>>
>>
>>
>>
>
>
>
No.
What makes you certain that the references at the time of unload are the
same references at the time of load? In other words, just because the counts
match, how can you be certain that some TDI client did not become dependent
on your filter along the way…
The answer is No and this has likely been beaten to death on this list many
times before. Unloading a ‘filter’ device from a device stack is really
only possible if there is some outer management and coordination of that
entire device stack (think PnP). Filters that sneak in (like TDI filters)
can rarely sneak out.
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of ChuckN
Sent: Monday, July 17, 2006 9:09 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Unloading filter driver
Hey,
in my application I have a filter device over \Device\Tcp which MUST be
unloaded (if possible)after a special user input. I thought before unloading
I could do a simple check on the Reference, Handle and Pointer count of the
device. If these are equal to the inital Reference, Handle and Pointer
counts and if there is no other filter device above my filter device (simply
checking MyFilterDevice->AttachedDevice!=NULL) it’s safe to unload the
filter driver.
Is that OK?
Thx
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
ChuckN,
Can you just put your filter into passive mode? Just forward all IRPs as if
your filter weren’t there at all.
-sd
On 7/17/06 9:10 AM, “David R. Cattley” wrote:
> No.
>
> What makes you certain that the references at the time of unload are the
> same references at the time of load? In other words, just because the counts
> match, how can you be certain that some TDI client did not become dependent
> on your filter along the way…
>
> The answer is No and this has likely been beaten to death on this list many
> times before. Unloading a ‘filter’ device from a device stack is really
> only possible if there is some outer management and coordination of that
> entire device stack (think PnP). Filters that sneak in (like TDI filters)
> can rarely sneak out.
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of ChuckN
> Sent: Monday, July 17, 2006 9:09 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Unloading filter driver
>
> Hey,
> in my application I have a filter device over \Device\Tcp which MUST be
> unloaded (if possible)after a special user input. I thought before unloading
> I could do a simple check on the Reference, Handle and Pointer count of the
> device. If these are equal to the inital Reference, Handle and Pointer
> counts and if there is no other filter device above my filter device (simply
> checking MyFilterDevice->AttachedDevice!=NULL) it’s safe to unload the
> filter driver.
> Is that OK?
> Thx
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
You cannot unload. You can only switch it to do-nothing mode.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: “ChuckN”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Monday, July 17, 2006 5:09 PM
Subject: [ntdev] Unloading filter driver
> Hey,
> in my application I have a filter device over \Device\Tcp which MUST be
> unloaded (if possible)after a special user input. I thought before unloading
> I could do a simple check on the Reference, Handle and Pointer count of the
> device. If these are equal to the inital Reference, Handle and Pointer
> counts and if there is no other filter device above my filter device (simply
> checking MyFilterDevice->AttachedDevice!=NULL) it’s safe to unload the
> filter driver.
> Is that OK?
> Thx
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer