Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTFSD

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


Mini-filters and legacy filters

OSR_Community_UserOSR_Community_User Member Posts: 110,217
NTFSD Folk:

The relationship of mini-filter drivers (i.e., which driver is above/below
another driver) is determined by the Altitude setting of that driver.

But where is it defined where they are with respect to legacy drivers? For
instance, how do I determine if a legacy anti-virus filter is above or below
my mini-filter, which is at altitude 288500?

Ken

Comments

  • Lyndon_J._Clarke-2Lyndon_J._Clarke-2 Member Posts: 1,013
    Ken

    "Where is it defined ?" Defined? Come on now, you seem to have been around
    this space long enough, you should know better :-)

    Filter manager is itself a "so called legacy" filter driver. Use devicetree
    to find out where filter manager and other filter driver are with respect to
    one another. You're minifilter (with whatever altitude it might have since
    it is irrelvant to the question) is in the same place as filter manager
    since it is in practical terms a collection of functions called from filter
    manager.

    Cheers
    Lyndon

    "Ken Cross" wrote in message news:[email protected]
    > NTFSD Folk:
    >
    > The relationship of mini-filter drivers (i.e., which driver is above/below
    > another driver) is determined by the Altitude setting of that driver.
    >
    > But where is it defined where they are with respect to legacy drivers?
    > For
    > instance, how do I determine if a legacy anti-virus filter is above or
    > below
    > my mini-filter, which is at altitude 288500?
    >
    > Ken
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Lyndon,

    Wouldn't the FltMgr always be below other legacy filters? I assume
    Microsoft would of designed the FltMgr to load before any other legacy
    filter (so it would *always* be at the bottom), or else it would defeat
    the purpose of altitudes. Since FltMgr is a part of the OS, M$ could
    definitely engineer it so it would load before other legacy filters,
    even though it is of a legacy design itself.

    If not, what would the purpose be in assigning altitudes to specific
    vendors if some other legacy crap (like what I would write :-) ) could
    be installed below Ken's mini driver?

    It seems logical that other legacy drivers could only load above the
    FltMgr - regardless of fltmgr's design (legacy design).

    M.

    Lyndon J Clarke wrote:

    >Ken
    >
    >"Where is it defined ?" Defined? Come on now, you seem to have been around
    >this space long enough, you should know better :-)
    >
    >Filter manager is itself a "so called legacy" filter driver. Use devicetree
    >to find out where filter manager and other filter driver are with respect to
    >one another. You're minifilter (with whatever altitude it might have since
    >it is irrelvant to the question) is in the same place as filter manager
    >since it is in practical terms a collection of functions called from filter
    >manager.
    >
    >Cheers
    >Lyndon
    >
    >"Ken Cross" <[email protected]> wrote in message news:[email protected]
    >
    >
    >>NTFSD Folk:
    >>
    >>The relationship of mini-filter drivers (i.e., which driver is above/below
    >>another driver) is determined by the Altitude setting of that driver.
    >>
    >>But where is it defined where they are with respect to legacy drivers?
    >>For
    >>instance, how do I determine if a legacy anti-virus filter is above or
    >>below
    >>my mini-filter, which is at altitude 288500?
    >>
    >>Ken
    >>
    >>
    >>
    >>
    >
    >
    >
    >---
    >Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
    >
    >You are currently subscribed to ntfsd as: [email protected]
    >To unsubscribe send a blank email to [email protected]
    >
    >
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    fltmgr is in FSFilter Infrastructure group (boot time)
    i'd say, two drivers e.g. in FSFilter Encryption group (legacy + minifilter) will be loaded at the moment when this group is processed; and according to fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted function, it indicates, minifilter's callbacks should be called firstly


    "MM" wrote in message news:[email protected]
    > Lyndon,
    >
    > Wouldn't the FltMgr always be below other legacy filters? I assume
    > Microsoft would of designed the FltMgr to load before any other legacy
    > filter (so it would *always* be at the bottom), or else it would defeat
    > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could
    > definitely engineer it so it would load before other legacy filters,
    > even though it is of a legacy design itself.
    >
    > If not, what would the purpose be in assigning altitudes to specific
    > vendors if some other legacy crap (like what I would write :-) ) could
    > be installed below Ken's mini driver?
    >
    > It seems logical that other legacy drivers could only load above the
    > FltMgr - regardless of fltmgr's design (legacy design).
    >
    > M.
    >
    > Lyndon J Clarke wrote:
    >
    >>Ken
    >>
    >>"Where is it defined ?" Defined? Come on now, you seem to have been around
    >>this space long enough, you should know better :-)
    >>
    >>Filter manager is itself a "so called legacy" filter driver. Use devicetree
    >>to find out where filter manager and other filter driver are with respect to
    >>one another. You're minifilter (with whatever altitude it might have since
    >>it is irrelvant to the question) is in the same place as filter manager
    >>since it is in practical terms a collection of functions called from filter
    >>manager.
    >>
    >>Cheers
    >>Lyndon
    >>
    >>"Ken Cross" wrote in message news:[email protected]
    >>
    >>
    >>>NTFSD Folk:
    >>>
    >>>The relationship of mini-filter drivers (i.e., which driver is above/below
    >>>another driver) is determined by the Altitude setting of that driver.
    >>>
    >>>But where is it defined where they are with respect to legacy drivers?
    >>>For
    >>>instance, how do I determine if a legacy anti-virus filter is above or
    >>>below
    >>>my mini-filter, which is at altitude 288500?
    >>>
    >>>Ken
    >>>
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >>---
    >>Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
    >>
    >>You are currently subscribed to ntfsd as: [email protected]
    >>To unsubscribe send a blank email to [email protected]
    >>
    >>
    >>
    >
  • Lyndon_J._Clarke-2Lyndon_J._Clarke-2 Member Posts: 1,013
    Hi Matt

    Filter Manager is in the "Filter Infrastructure" load order group which the
    ifs kit documents as follows ... "Reserved for use by Microsoft. This group
    loads first and thus attaches closest to the file system." ... so what you
    expect/assume turns out to be how it works on this occasion.

    I dont think this is pertient to the concept of altitudes since these are no
    more than a complete order of mini filters but that is just the perspective
    of one individual. From a different perspective, perhaps a more minifilter
    centric perspective, I suppose one can say that "so called legacy" filter
    drivers have "infinite" altitude :)

    Cheers
    Lyndon

    "MM" wrote in message news:[email protected]
    > Lyndon,
    >
    > Wouldn't the FltMgr always be below other legacy filters? I assume
    > Microsoft would of designed the FltMgr to load before any other legacy
    > filter (so it would *always* be at the bottom), or else it would defeat
    > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could
    > definitely engineer it so it would load before other legacy filters, even
    > though it is of a legacy design itself.
    >
    > If not, what would the purpose be in assigning altitudes to specific
    > vendors if some other legacy crap (like what I would write :-) ) could be
    > installed below Ken's mini driver?
    >
    > It seems logical that other legacy drivers could only load above the
    > FltMgr - regardless of fltmgr's design (legacy design).
    >
    > M.
    >
    > Lyndon J Clarke wrote:
    >
    >>Ken
    >>
    >>"Where is it defined ?" Defined? Come on now, you seem to have been
    >>around this space long enough, you should know better :-)
    >>
    >>Filter manager is itself a "so called legacy" filter driver. Use
    >>devicetree to find out where filter manager and other filter driver are
    >>with respect to one another. You're minifilter (with whatever altitude it
    >>might have since it is irrelvant to the question) is in the same place as
    >>filter manager since it is in practical terms a collection of functions
    >>called from filter manager.
    >>
    >>Cheers
    >>Lyndon
    >>
    >>"Ken Cross" wrote in message news:[email protected]
    >>
    >>>NTFSD Folk:
    >>>
    >>>The relationship of mini-filter drivers (i.e., which driver is
    >>>above/below
    >>>another driver) is determined by the Altitude setting of that driver.
    >>>
    >>>But where is it defined where they are with respect to legacy drivers?
    >>>For
    >>>instance, how do I determine if a legacy anti-virus filter is above or
    >>>below
    >>>my mini-filter, which is at altitude 288500?
    >>>
    >>>Ken
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >>---
    >>Questions? First check the IFS FAQ at
    >>https://www.osronline.com/article.cfm?id=17
    >>
    >>You are currently subscribed to ntfsd as: [email protected]
    >>To unsubscribe send a blank email to [email protected]
    >>
    >>
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Hi,

    Filter Manager "load order" group is not important to determine its attach position. Traditional legacy FS filters attaches to a volume in the order in which they load, but Filter Manager legacy filter is not traditional :).

    Filter Manager allows coexistence between legacy filters and minifilters in a mixed environment. A legacy filter has a load order group, and a minifilter has an altitude that defines its load order group. I mean, altitude is mapped to a load order group, so the minifilter position in a stack is defined with regard to the position of one or more legacy filters.

    The OS permits this coexistence by allowing the Filter Manager to attach to a volume more than once. Each Filter Manager VDO instance filtering the same volume is called a "frame". And I suppose that in the worst scenario, it is possible to have the same number of Filter Manager attachments by volume (frames) as load order groups, because it could be necessary to interleave a frame between each legacy filter with different load order group.

    Regards,
    Ramon

    -----Mensaje original-----
    De: [email protected] [mailto:[email protected]] En nombre de Lyndon J Clarke
    Enviado el: s?bado, 29 de octubre de 2005 18:19
    Para: Windows File Systems Devs Interest List
    Asunto: Re:[ntfsd] Mini-filters and legacy filters

    Hi Matt

    Filter Manager is in the "Filter Infrastructure" load order group which the
    ifs kit documents as follows ... "Reserved for use by Microsoft. This group
    loads first and thus attaches closest to the file system." ... so what you
    expect/assume turns out to be how it works on this occasion.

    I dont think this is pertient to the concept of altitudes since these are no
    more than a complete order of mini filters but that is just the perspective
    of one individual. From a different perspective, perhaps a more minifilter
    centric perspective, I suppose one can say that "so called legacy" filter
    drivers have "infinite" altitude :)

    Cheers
    Lyndon

    "MM" <[email protected]> wrote in message news:[email protected]
    > Lyndon,
    >
    > Wouldn't the FltMgr always be below other legacy filters? I assume
    > Microsoft would of designed the FltMgr to load before any other legacy
    > filter (so it would *always* be at the bottom), or else it would defeat
    > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could
    > definitely engineer it so it would load before other legacy filters, even
    > though it is of a legacy design itself.
    >
    > If not, what would the purpose be in assigning altitudes to specific
    > vendors if some other legacy crap (like what I would write :-) ) could be
    > installed below Ken's mini driver?
    >
    > It seems logical that other legacy drivers could only load above the
    > FltMgr - regardless of fltmgr's design (legacy design).
    >
    > M.
    >
    > Lyndon J Clarke wrote:
    >
    >>Ken
    >>
    >>"Where is it defined ?" Defined? Come on now, you seem to have been
    >>around this space long enough, you should know better :-)
    >>
    >>Filter manager is itself a "so called legacy" filter driver. Use
    >>devicetree to find out where filter manager and other filter driver are
    >>with respect to one another. You're minifilter (with whatever altitude it
    >>might have since it is irrelvant to the question) is in the same place as
    >>filter manager since it is in practical terms a collection of functions
    >>called from filter manager.
    >>
    >>Cheers
    >>Lyndon
    >>
    >>"Ken Cross" <[email protected]> wrote in message news:[email protected]
    >>
    >>>NTFSD Folk:
    >>>
    >>>The relationship of mini-filter drivers (i.e., which driver is
    >>>above/below
    >>>another driver) is determined by the Altitude setting of that driver.
    >>>
    >>>But where is it defined where they are with respect to legacy drivers?
    >>>For
    >>>instance, how do I determine if a legacy anti-virus filter is above or
    >>>below
    >>>my mini-filter, which is at altitude 288500?
    >>>
    >>>Ken
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >>---
    >>Questions? First check the IFS FAQ at
    >>https://www.osronline.com/article.cfm?id=17
    >>
    >>You are currently subscribed to ntfsd as: [email protected]
    >>To unsubscribe send a blank email to [email protected]
    >>
    >>
    >



    ---
    Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to [email protected]
  • Lyndon_J._Clarke-2Lyndon_J._Clarke-2 Member Posts: 1,013
    Hmm ... very interesting ... I read after post more about minifilters,
    noticed that these also have load order groups, and wondered whether filter
    manager was doing something like this - it is just as well really else quite
    a few very dissapionted miinifilter driver developers out there when someone
    loads an encryption filter :-)

    "Ramon Royo" wrote in message news:[email protected]
    Hi,

    Filter Manager "load order" group is not important to determine its attach
    position. Traditional legacy FS filters attaches to a volume in the order in
    which they load, but Filter Manager legacy filter is not traditional :).

    Filter Manager allows coexistence between legacy filters and minifilters in
    a mixed environment. A legacy filter has a load order group, and a
    minifilter has an altitude that defines its load order group. I mean,
    altitude is mapped to a load order group, so the minifilter position in a
    stack is defined with regard to the position of one or more legacy filters.

    The OS permits this coexistence by allowing the Filter Manager to attach to
    a volume more than once. Each Filter Manager VDO instance filtering the same
    volume is called a "frame". And I suppose that in the worst scenario, it is
    possible to have the same number of Filter Manager attachments by volume
    (frames) as load order groups, because it could be necessary to interleave a
    frame between each legacy filter with different load order group.

    Regards,
    Ramon

    -----Mensaje original-----
    De: [email protected]
    [mailto:[email protected]] En nombre de Lyndon J Clarke
    Enviado el: sábado, 29 de octubre de 2005 18:19
    Para: Windows File Systems Devs Interest List
    Asunto: Re:[ntfsd] Mini-filters and legacy filters

    Hi Matt

    Filter Manager is in the "Filter Infrastructure" load order group which the
    ifs kit documents as follows ... "Reserved for use by Microsoft. This group
    loads first and thus attaches closest to the file system." ... so what you
    expect/assume turns out to be how it works on this occasion.

    I dont think this is pertient to the concept of altitudes since these are no
    more than a complete order of mini filters but that is just the perspective
    of one individual. From a different perspective, perhaps a more minifilter
    centric perspective, I suppose one can say that "so called legacy" filter
    drivers have "infinite" altitude :)

    Cheers
    Lyndon

    "MM" wrote in message news:[email protected]
    > Lyndon,
    >
    > Wouldn't the FltMgr always be below other legacy filters? I assume
    > Microsoft would of designed the FltMgr to load before any other legacy
    > filter (so it would *always* be at the bottom), or else it would defeat
    > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could
    > definitely engineer it so it would load before other legacy filters, even
    > though it is of a legacy design itself.
    >
    > If not, what would the purpose be in assigning altitudes to specific
    > vendors if some other legacy crap (like what I would write :-) ) could be
    > installed below Ken's mini driver?
    >
    > It seems logical that other legacy drivers could only load above the
    > FltMgr - regardless of fltmgr's design (legacy design).
    >
    > M.
    >
    > Lyndon J Clarke wrote:
    >
    >>Ken
    >>
    >>"Where is it defined ?" Defined? Come on now, you seem to have been
    >>around this space long enough, you should know better :-)
    >>
    >>Filter manager is itself a "so called legacy" filter driver. Use
    >>devicetree to find out where filter manager and other filter driver are
    >>with respect to one another. You're minifilter (with whatever altitude it
    >>might have since it is irrelvant to the question) is in the same place as
    >>filter manager since it is in practical terms a collection of functions
    >>called from filter manager.
    >>
    >>Cheers
    >>Lyndon
    >>
    >>"Ken Cross" wrote in message news:[email protected]
    >>
    >>>NTFSD Folk:
    >>>
    >>>The relationship of mini-filter drivers (i.e., which driver is
    >>>above/below
    >>>another driver) is determined by the Altitude setting of that driver.
    >>>
    >>>But where is it defined where they are with respect to legacy drivers?
    >>>For
    >>>instance, how do I determine if a legacy anti-virus filter is above or
    >>>below
    >>>my mini-filter, which is at altitude 288500?
    >>>
    >>>Ken
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >>---
    >>Questions? First check the IFS FAQ at
    >>https://www.osronline.com/article.cfm?id=17
    >>
    >>You are currently subscribed to ntfsd as: [email protected]
    >>To unsubscribe send a blank email to [email protected]
    >>
    >>
    >



    ---
    Questions? First check the IFS FAQ at
    https://www.osronline.com/article.cfm?id=17

    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to [email protected]
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    Roman & Lyndon are correct. Filter manager has a well defined algorithm
    (though not completely documented) for how it interoperates with legacy
    filters. Let me explain.

    In the legacy filter world load order is what controls attachment order.
    In the ideal minifilter world attachment order is controlled by
    altitudes and load order doesn't matter because filter manager can load
    a minifilter at its correct altitude regardless of when it loaded.

    The problem is that we needed to make these two worlds co-exist. We had
    thought about making all mini-filters exist below all legacy filters but
    that model does not work well. A simple example is if there was a
    antivirus minifilter and a legacy encryption filter. Obviously having
    the AV product scan encrypted data is not going to be useful. We had to
    figure out a model to make these two worlds co-exist in a reasonable
    way.

    As was pointed out by Roman, filter manager has a concept known as
    Frames. A frame is a unique attachment by filter manager to the IO
    Stack. By default filter manager loads before any other filters and
    creates frame 0 automatically. One of the reasons that filter manager
    has to load first is to guarantee consistency of the name cache. If
    there was a legacy filter below filter manager's frame 0 that renamed
    files, the name cache would become corrupt. Note that we actually
    detect this situation and disable the name cache (naming APIs still
    work, names are simply not cached) if there is a legacy filter below
    frame 0.

    Let me layout what filter manager does at load time:

    - Initially frame 0 has an altitude range of 0-0.
    - Lets say a minifilter loads with an altitude of 100
    - Filter manager first checks to see if this is within the range of an
    existing frame. The answer is no in this case.
    - Filter manager checks to see if a legacy filter has attached above
    frame 0. The answer is no.
    - Filter manager adjusts the altitude range of frame 0 to be 0-100 and
    loads the minifilter in frame 0

    - Lets say another minifilter loads next with an altitude of 75
    - Filter manager checks to see if this is within the range of an
    existing frame. The answer is yes so the minifilter is loaded in frame
    0. We do this check first to support a minifilter unloading and
    reloading (an upgrade for example) and we guarantee they will go back to
    the same frame.

    - Lets say another minifilter now loads with an altitude of 200
    - Filter manager checks to see if this is within the range of an
    existing filter. No
    - Filter manager checks to see if a legacy filter has loaded above
    frame 0. No
    - Filter manager adjust the altitude range of frame 0 to be 0-200 now
    and loads the minifilter in frame 0

    - Lets say a legacy filter now loads. It is obviously going to attach
    above filter manager frame 0.

    - We now have another minifilter load with an altitude of 300.
    - We see if this fits in an existing frame. In this case the altitude
    range of frame zero is still 0-200 so the answer is no.
    - We check if a legacy filter has loaded above filter manager's highest
    frame.
    - This time the answer is yes. When this happens the altitude range of
    the frame immediately underneath is now capped and we create a frame 1
    with an altitude range of 200-300. Note that altitude ranges are not
    inclusive of the lower value.
    - We load the minifilter in frame 1

    We keep doing this for each additional minifilter/legacy filter that is
    loaded and dynamically create frames as needed.

    This is why minifilters still have load-order-groups and there are
    altitude ranges for each load-order-group. This is also why it is still
    important to load your minifilter at the correct boot phase (boot,
    system, automatic) as if it were a legacy filter to get proper ordering
    if legacy filters are still present. This means if you have a "low"
    load order group you need to load in an earlier boot phase then if you
    have a "high" load order group.

    Once Windows no longer supports legacy filters (this will happen post
    vista/longhorn) things will be much simpler because your minifilter can
    have any altitude and load at any time and be order properly.

    As you might have noticed the frame concept is not really exposed to
    minifilters. If you run "fltmc" without any parameters it lists the
    existing filters in the system. Notice that it also identifies the
    frame the minifilter is loaded in. This is the only indication in the
    system of frames. If you use the "fltkd" debugger extension it will
    also provide frame information.

    I hope this description helps,

    Neal Christiansen
    Microsoft File System Filter Group Lead
    This posting is provided "AS IS" with no warranties, and confers no
    Rights

    -----Original Message-----
    From: [email protected]
    [mailto:[email protected]] On Behalf Of Lyndon J Clarke
    Sent: Saturday, October 29, 2005 9:19 AM
    To: Windows File Systems Devs Interest List
    Subject: Re:[ntfsd] Mini-filters and legacy filters

    Hi Matt

    Filter Manager is in the "Filter Infrastructure" load order group which
    the
    ifs kit documents as follows ... "Reserved for use by Microsoft. This
    group
    loads first and thus attaches closest to the file system." ... so what
    you
    expect/assume turns out to be how it works on this occasion.

    I dont think this is pertient to the concept of altitudes since these
    are no
    more than a complete order of mini filters but that is just the
    perspective
    of one individual. From a different perspective, perhaps a more
    minifilter
    centric perspective, I suppose one can say that "so called legacy"
    filter
    drivers have "infinite" altitude :)

    Cheers
    Lyndon

    "MM" <[email protected]> wrote in message news:[email protected]
    > Lyndon,
    >
    > Wouldn't the FltMgr always be below other legacy filters? I assume
    > Microsoft would of designed the FltMgr to load before any other legacy

    > filter (so it would *always* be at the bottom), or else it would
    defeat
    > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could
    > definitely engineer it so it would load before other legacy filters,
    even
    > though it is of a legacy design itself.
    >
    > If not, what would the purpose be in assigning altitudes to specific
    > vendors if some other legacy crap (like what I would write :-) ) could
    be
    > installed below Ken's mini driver?
    >
    > It seems logical that other legacy drivers could only load above the
    > FltMgr - regardless of fltmgr's design (legacy design).
    >
    > M.
    >
    > Lyndon J Clarke wrote:
    >
    >>Ken
    >>
    >>"Where is it defined ?" Defined? Come on now, you seem to have been
    >>around this space long enough, you should know better :-)
    >>
    >>Filter manager is itself a "so called legacy" filter driver. Use
    >>devicetree to find out where filter manager and other filter driver
    are
    >>with respect to one another. You're minifilter (with whatever altitude
    it
    >>might have since it is irrelvant to the question) is in the same place
    as
    >>filter manager since it is in practical terms a collection of
    functions
    >>called from filter manager.
    >>
    >>Cheers
    >>Lyndon
    >>
    >>"Ken Cross" <[email protected]> wrote in message news:[email protected]
    >>
    >>>NTFSD Folk:
    >>>
    >>>The relationship of mini-filter drivers (i.e., which driver is
    >>>above/below
    >>>another driver) is determined by the Altitude setting of that driver.
    >>>
    >>>But where is it defined where they are with respect to legacy
    drivers?
    >>>For
    >>>instance, how do I determine if a legacy anti-virus filter is above
    or
    >>>below
    >>>my mini-filter, which is at altitude 288500?
    >>>
    >>>Ken
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >>---
    >>Questions? First check the IFS FAQ at
    >>https://www.osronline.com/article.cfm?id=17
    >>
    >>You are currently subscribed to ntfsd as: [email protected]
    >>To unsubscribe send a blank email to [email protected]
    >>
    >>
    >



    ---
    Questions? First check the IFS FAQ at
    https://www.osronline.com/article.cfm?id=17

    You are currently subscribed to ntfsd as: [email protected]
    To unsubscribe send a blank email to [email protected]
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 12 September 2022 Live, Online
Internals & Software Drivers 23 October 2022 Live, Online
Kernel Debugging 14 November 2022 Live, Online
Developing Minifilters 5 December 2022 Live, Online