Two filter drivers with the same FilterClass

Hi All,

I read that no two intermediate with the same FilterClass can coexist
in the same box.

My NDIS intermediate has a FilterClass of scheduler, same as Microsft's
popular QoS schedular driver. Most of the time I don't see any
coexistence problems (my driver really doesn't care about its stack
level, I just try not to get in the way of other drivers that do).

However recently there are a number of cases which I suspect are
related to this issue.
On multi-card systems, with specific hardware, the driver doesn't come
back from a call to NdisIMInitializeDeviceInstance (MPInitialize
returns, and OID are served, but my debug output stops after the
miniport receives OID_GEN_VENDOR_ID and NdisIMInitializeDeviceInstance
never returns). Is it likely the issue is related? Any other thoughts?

Does anyone know why is it that coexistence of two filters of the same
level is not supported (as I said, most of the time it works)?

Thanks,
Hillel.

Alireza
Mon May 22 14:12:15 CDT 2006

What operating system is this?
If you are getting as far as getting these OIDs, I don't think the problem
has to do with your filter class.

Look for an OID request that you have not completed (or not completed
properly or you have forwarded to the underlying adapter and has not
returned). That is the most likely cause of what you are seeing (if the
problem is a hung system).

-ali


--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Hillel" <hillel.t@gmail.com> wrote in message
news:1148217320.834415.309840@j55g2000cwa.googlegroups.com...
> Hi All,
>
> I read that no two intermediate with the same FilterClass can coexist
> in the same box.
>
> My NDIS intermediate has a FilterClass of scheduler, same as Microsft's
> popular QoS schedular driver. Most of the time I don't see any
> coexistence problems (my driver really doesn't care about its stack
> level, I just try not to get in the way of other drivers that do).
>
> However recently there are a number of cases which I suspect are
> related to this issue.
> On multi-card systems, with specific hardware, the driver doesn't come
> back from a call to NdisIMInitializeDeviceInstance (MPInitialize
> returns, and OID are served, but my debug output stops after the
> miniport receives OID_GEN_VENDOR_ID and NdisIMInitializeDeviceInstance
> never returns). Is it likely the issue is related? Any other thoughts?
>
> Does anyone know why is it that coexistence of two filters of the same
> level is not supported (as I said, most of the time it works)?
>
> Thanks,
> Hillel.
>

pavel_a
Mon May 22 14:26:02 CDT 2006

Can you repro it after unchecking the QoS scheduler in connection properties?

--PA

"Hillel" wrote:
> Hi All,
>
> I read that no two intermediate with the same FilterClass can coexist
> in the same box.
>
> My NDIS intermediate has a FilterClass of scheduler, same as Microsft's
> popular QoS schedular driver. Most of the time I don't see any
> coexistence problems (my driver really doesn't care about its stack
> level, I just try not to get in the way of other drivers that do).
>
> However recently there are a number of cases which I suspect are
> related to this issue.
> On multi-card systems, with specific hardware, the driver doesn't come
> back from a call to NdisIMInitializeDeviceInstance (MPInitialize
> returns, and OID are served, but my debug output stops after the
> miniport receives OID_GEN_VENDOR_ID and NdisIMInitializeDeviceInstance
> never returns). Is it likely the issue is related? Any other thoughts?
>
> Does anyone know why is it that coexistence of two filters of the same
> level is not supported (as I said, most of the time it works)?
>
> Thanks,
> Hillel.
>
>

Hillel
Tue May 23 01:41:18 CDT 2006

Thanks for the help all.
This is definitely a problem with having the same FilterClass. I have
done some more experiments, and the problem goes away if I either
uninstall QoS before installing my driver, or if change my driver
FilterClass.

Since my driver doesn't care about its stack level, I just want to
choose a FilterClass that will conflict with as few drivers as
possible. I decided to try and define my own stack level according to
this article:
http://support.microsoft.com/default.aspx?scid=kb;en-us;250615

I only fear its last paragraph:

"There are a few problems associated with defining your own class. Once
the filter drivers are installed, you cannot change the order by
uninstalling and reinstalling because the values appended during the
first install are never changed. The only way to undo the values is to
uninstall the filters and reset the FilterClasses values by some other
means."

I don't get this paragraph. What does it mean by you cannot change the
order by uninstalling and reinstalling? Is it different from when
installing with one of the predefined FilterClasses?