A number of drivers can register registry callbacks. Considering minifilter and a normal driver There can be 3 cases
1 All are minifilters
Registry callbacks are registered using CmRegisterCallbackEx. So, callbacks will be invoked in order from high to low altitude minifilter.
2 Some are minifilters and rest normal drivers(not minifilters)
Minifilters will register using CmRegisterCallbackEx and normal driver will register using CmRegisterCallback. What will be the order of callback invocation ?
3 All are normal
Normal driver will register using CmRegisterCallback. Depending on the order of registration, the callbacks will be invoked.
Please correct me regarding order of invocation.
You can call any of the registry callback functions either from both legacy
drivers and minifilters. Because registry callbacks are typically the work
of software only drivers, the documentation speaks about minifilters but
this is not enforced in any type of way (CmRegisterCallbackEx
is declared in wdm.h).
Despite what the documentation says I do not believe that the altitude
parameter has or should have any type of relation to a minifilter altitude,
I think they were just copying text around. I don’t think there is any
documentation which mentions in what order Ex registered callbacks (with an
altitude) will be called in relation to regular registry callbacks. Anybody
correct me if I am wrong.
I interpret all this as a right to use the minfilter model for whatever
software only purpose I find suitable even if I am not involved in the file
system stack at all. I personally find the minifilter model much less
awkward than the legacy model as it automaticall interfaces with the I/O
manager and makes it a lot easier to implement communication schemes like
for instance the inverted call model.
//Daniel
wrote in message news:xxxxx@ntfsd…
>A number of drivers can register registry callbacks. Considering minifilter
>and a normal driver There can be 3 cases
>
> 1 All are minifilters
> Registry callbacks are registered using CmRegisterCallbackEx. So,
> callbacks will be invoked in order from high to low altitude minifilter.
>
> 2 Some are minifilters and rest normal drivers(not minifilters)
> Minifilters will register using CmRegisterCallbackEx and normal driver
> will register using CmRegisterCallback. What will be the order of callback
> invocation ?
>
> 3 All are normal
> Normal driver will register using CmRegisterCallback. Depending on the
> order of registration, the callbacks will be invoked.
>
> Please correct me regarding order of invocation.
>
>
>
Hi Daniel!
Despite what the documentation says I do not believe that
the altitude parameter has or should have any type of
relation to a minifilter altitude, I think they were just
copying text around. I don’t think there is any
documentation which mentions in what order Ex registered
callbacks (with an altitude) will be called in relation to
regular registry callbacks. Anybody correct me if I am
wrong.
The documentation states “Registry filtering drivers that were written before Windows Vista and therefore do not have an altitude assignment are inserted near the top of the Windows Vista filter stack, in the order that they call CmRegisterCallback.”
So I guess the ones that dont have the altitude will be called before the ones that have altitude.
Regards,
Ayush Gupta
http://windows-internals.blogspot.com/
Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
Also the altitude scheme is common to registry filter and file system
minifilters. This ensures that the layering on the file system stack and
the registry stack will be identical - thus presenting a consistent view
of the file system and registry at any given altitude.
Regards,
Sarosh.
File System Filter Lead
Microsoft Corp
This posting is provided “AS IS” with no warranties, and confers no Rights
Ayush Gupta wrote:
Hi Daniel!
> Despite what the documentation says I do not believe that
> the altitude parameter has or should have any type of
> relation to a minifilter altitude, I think they were just
> copying text around. I don’t think there is any
> documentation which mentions in what order Ex registered
> callbacks (with an altitude) will be called in relation to
> regular registry callbacks. Anybody correct me if I am
> wrong.
The documentation states “Registry filtering drivers that were written before Windows Vista and therefore do not have an altitude assignment are inserted near the top of the Windows Vista filter stack, in the order that they call CmRegisterCallback.”
So I guess the ones that dont have the altitude will be called before the ones that have altitude.
Regards,
Ayush Gupta
http://windows-internals.blogspot.com/
Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
Thanks Sarosh. While this reply raises a bunch of new questions I appreciate
you pointing out the official position on this.
//Daniel
“Sarosh Havewala” wrote in message
news:xxxxx@ntfsd…
> Also the altitude scheme is common to registry filter and file system
> minifilters. This ensures that the layering on the file system stack and
> the registry stack will be identical - thus presenting a consistent view
> of the file system and registry at any given altitude.
>
>
> Regards,
> Sarosh.
> File System Filter Lead
> Microsoft Corp
>
> This posting is provided “AS IS” with no warranties, and confers no Rights
>
>
> Ayush Gupta wrote:
>> Hi Daniel!
>>
>>> Despite what the documentation says I do not believe that
>>> the altitude parameter has or should have any type of
>>> relation to a minifilter altitude, I think they were just
>>> copying text around. I don’t think there is any
>>> documentation which mentions in what order Ex registered
>>> callbacks (with an altitude) will be called in relation to
>>> regular registry callbacks. Anybody correct me if I am
>>> wrong.
>>
>> The documentation states “Registry filtering drivers that were written
>> before Windows Vista and therefore do not have an altitude assignment are
>> inserted near the top of the Windows Vista filter stack, in the order
>> that they call CmRegisterCallback.”
>>
>> So I guess the ones that dont have the altitude will be called before the
>> ones that have altitude.
>>
>> Regards,
>> Ayush Gupta
>> http://windows-internals.blogspot.com/
>>
>>
>> Add more friends to your messenger and enjoy! Go to
>> http://messenger.yahoo.com/invite/
>>
>
Ayush Gupta wrote:
…
The documentation states “Registry filtering drivers that were written before Windows Vista and therefore do not have an altitude assignment are inserted near the top of the Windows Vista filter stack, in the order that they call CmRegisterCallback.”
So I guess the ones that dont have the altitude will be called before the ones that have altitude.
Indeed, altitude for registry callbacks can not be defined exactly in
same way as for filesystem: there are no “call down” APIs like
FltReadFile , FltWriteFile for registry.
So, modifying registry filters either use the common Zw functions
that start from the very top of filters stack - or use undocumented
Cm internals.
/* Was this why the NT Insider hasn’t published the 2nd part
of the registry filtering article ? */
– pa
Hi Sarosh
>Also the altitude scheme is common to registry filter and file system
>minifilters. This ensures that the layering on the file system stack and
>the registry stack will be identical - thus presenting a consistent view
>of the file system and registry at any given altitude.
i have some questions:
1- how can i granting that i am talking a unique altitude for my driver (have it a separate process with Microsoft).
2- when i define my filter as FS Filter Bottom… is that means that both file and registry operations will be as most as the same occured on File system.
3- about how i can learn more about vista new registry filtering model and if there any Microsoft offical sample?
thanks for help…
Hi!
Indeed, altitude for registry callbacks can not be defined
exactly in same way as for filesystem: there are no “call
down” APIs like FltReadFile , FltWriteFile for registry.
So, modifying registry filters either use the common Zw
functions
that start from the very top of filters stack - or use
undocumented
Cm internals.
IIRC, I had once noticed long time back that the registry calls issued using ZwXXXKey from within a registry callback are not seen by any registry callbacks.
Regards,
Ayush Gupta
http://nothing-yet-everything.blogspot.com/
Connect with friends all over the world. Get Yahoo! India Messenger at http://in.messenger.yahoo.com/?wm=n/
Hi!
Sorry to jump in since the question was asked to Sarosh. 
i have some questions:
1- how can i granting that i am talking a unique altitude
for my driver (have it a separate process with Microsoft).
2- when i define my filter as FS Filter Bottom… is that
means that both file and registry operations will be as most
as the same occured on File system.
3- about how i can learn more about vista new registry
filtering model and if there any Microsoft offical sample?
There is a procedure to apply for a minifilter altitude. The link is:
http://connect.microsoft.com/content/content.aspx?ContentID=2512&SiteID=221
The filters in “FS Filter bottom” group are placed below all others except for 2 reserved groups. The altitude request form asks you to give a brief description of the work that your filter is trying to do.
There is sufficient documentation available in WDK to know about the registry filtering model. IIRC, there is a separate section on it. However, there is no sample as such.
Regards,
Ayush Gupta
http://windows-internals.blogspot.com/
Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/
thanks and appreciated,
and soory for interrupt
There is none. If you apply for a minifilter altitude for several years you
will receive a message periodically that they regret that they are behind
and hope to supply with an altitude in the future. Your best bet is just to
choose an odd number, not divisible by 3 or 5 but within the range of its
functionality class and then hope that noone else is going around with the
same altitude because if a minifilter is already loaded with the same
altitude then yours will be denied by the OS (rather than getting loaded
either below or above of the filter with the same existing altitude).
//Daniel
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
Hi!
Sorry to jump in since the question was asked to Sarosh.
> i have some questions:
> 1- how can i granting that i am talking a unique altitude
> for my driver (have it a separate process with Microsoft).
> 2- when i define my filter as FS Filter Bottom… is that
> means that both file and registry operations will be as most
> as the same occured on File system.
> 3- about how i can learn more about vista new registry
> filtering model and if there any Microsoft offical sample?
There is a procedure to apply for a minifilter altitude. The link is:
http://connect.microsoft.com/content/content.aspx?ContentID=2512&SiteID=221
Regards,
Ayush Gupta
http://windows-internals.blogspot.com/
Add more friends to your messenger and enjoy! Go to
http://messenger.yahoo.com/invite/
Daniel, you sound bitter.
Realize that altitudes are strings. So, you can always just add more values to the string.
If your altitude is 123456, you could make it 123456.654321, for example. It’s not perfect, but it does further minimize the likelihood of conflict.
This is the technique someone with multiple filters uses to distinguish the ordering between them.
Tony
OSR
Sorry to hear that Tony, I always thought of myself as a sweet guy and
that’s how I would like to appear.
Unlike the registry filter callback functions in which you specify an
altitude as a parameter, a minifilter requires the altitude to be specified
in the INF file. Although there’s little documentation, it’s true that
somewhere it says: “altitude is an infinite-precision string interpreted as
a decimal number”.
Because I have never seen any minifilter sample with a floating point value
as an altitude, my question is if we can count on the period as the decimal
symbol or if this is subject to localization options of the user who
installs the driver.
//Daniel
wrote in message news:xxxxx@ntfsd…
> Daniel, you sound bitter.
>
> Realize that altitudes are strings. So, you can always just add more
> values to the string.
>
> If your altitude is 123456, you could make it 123456.654321, for example.
> It’s not perfect, but it does further minimize the likelihood of conflict.
>
> This is the technique someone with multiple filters uses to distinguish
> the ordering between them.
>
> Tony
> OSR
>
>
> So, modifying registry filters either use the common Zw functions
that start from the very top of filters stack
If a callback in the middle of the stack issues a Zw registry call from
its notification, only lower-level callbacks will receive notifications
for the nested call. There is no restarting from the top of the stack.
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
“Pavel Lebedinsky” wrote in message
news:xxxxx@ntfsd…
>> So, modifying registry filters either use the common Zw functions
>> that start from the very top of filters stack
>
> If a callback in the middle of the stack issues a Zw registry call from
> its notification, only lower-level callbacks will receive notifications
> for the nested call. There is no restarting from the top of the stack.
It works this way on NT6, or before too?
At least for XP, this looks like er… undocumented implementation detail
regards,
– pa
>> If a callback in the middle of the stack issues a Zw registry call from
> its notification, only lower-level callbacks will receive notifications
> for the nested call. There is no restarting from the top of the stack.
It works this way on NT6, or before too?
At least for XP, this looks like er… undocumented implementation detail
NT6.0 and later. On earlier versions I agree it looks like undocumented
implementation detail whether any callbacks will be invoked in this case
and if yes, in what order.
In any case, XP doesn’t provide any supported way to return the results
of a nested Zw call back to the user, so even if exact behavior in this case
was documented it wouldn’t be particularly useful.
–
Pavel Lebedinsky/Windows Kernel Test
This posting is provided “AS IS” with no warranties, and confers no rights.
I do not believe that picking your own altitude at random is the
solution here.
Yes, I will admit that there have been times in the past where one may
have seen more delay in allocation of altitudes then I would have liked.
In the recent past, requestors should be seeing a turn-around time of no
more than 2-3 weeks. If there is anything to the contrary, please feel
free to ping me about it.
Regards,
Sarosh.
File System Filter Lead
Microsoft Corp
This posting is provided “AS IS” with no warranties, and confers no Rights
xxxxx@resplendence.com wrote:
There is none. If you apply for a minifilter altitude for several years
you will receive a message periodically that they regret that they are
behind and hope to supply with an altitude in the future. Your best bet
is just to choose an odd number, not divisible by 3 or 5 but within the
range of its functionality class and then hope that noone else is going
around with the same altitude because if a minifilter is already loaded
with the same altitude then yours will be denied by the OS (rather than
getting loaded either below or above of the filter with the same
existing altitude).
//Daniel
“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
>
> Hi!
>
> Sorry to jump in since the question was asked to Sarosh.
>> i have some questions:
>> 1- how can i granting that i am talking a unique altitude
>> for my driver (have it a separate process with Microsoft).
>> 2- when i define my filter as FS Filter Bottom… is that
>> means that both file and registry operations will be as most
>> as the same occured on File system.
>> 3- about how i can learn more about vista new registry
>> filtering model and if there any Microsoft offical sample?
>
> There is a procedure to apply for a minifilter altitude. The link is:
> http://connect.microsoft.com/content/content.aspx?ContentID=2512&SiteID=221
>
>
> Regards,
> Ayush Gupta
> http://windows-internals.blogspot.com/
>
>
> Add more friends to your messenger and enjoy! Go to
> http://messenger.yahoo.com/invite/
>
>