problem in FltParseFileNameInformation...............!!!!!!!!

i m a new bee to filter driver development…!!!

i m just trying simple things in my filter…!!!1

i was try to get the filename in a read pre-operation callback

it works fine but after couple of seconds since initiaiton filtering with my
mini-driver I receive the following error in the debugger:

Access violation - code c0000005 (!!! second chance !!!)

after anayzing the bugcheck and and traversing through stack each and every time i found the main curlpret is FltParseFileNameInformation() function…!!!

just have a look at the code and i do’t know why it did’t work…!!!

callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags)
{
PFLT_FILE_NAME_INFORMATION nameInfo;
NTSTATUS status;

status = FltGetFileNameInformation(
Data,
FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
&nameInfo );
----->>>status = FltParseFileNameInformation(nameInfo);

}

this perticular line shows error always…!!!

evenif i call FltReleaseFileNameInformation(nameInfo) then the problem exist…!!!

after a couple of filtering it gives error…!!!

i did’t find any special information while using those couple of functionss…!!! except freeing the PFLT_FILE_NAME_INFORMATION by calling function which reduce its refrence count…!!!

help me i m stuckin …!!!

thanku in advance…!!!1

What was the return status from FltGetFileNameInformation()? Was the
call successful?

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Tuesday, October 24, 2006 8:55 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem in
FltParseFileNameInformation…!!!

i m a new bee to filter driver development…!!!

i m just trying simple things in my filter…!!!1

i was try to get the filename in a read pre-operation callback

it works fine but after couple of seconds since initiaiton
filtering with my
mini-driver I receive the following error in the debugger:

Access violation - code c0000005 (!!! second chance !!!)

after anayzing the bugcheck and and traversing through stack
each and every time i found the main curlpret is
FltParseFileNameInformation() function…!!!

just have a look at the code and i do’t know why it did’t work…!!!

callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags)
{
PFLT_FILE_NAME_INFORMATION nameInfo;
NTSTATUS status;

status = FltGetFileNameInformation(
Data,
FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
&nameInfo );
----->>>status = FltParseFileNameInformation(nameInfo);

}

this perticular line shows error always…!!!

evenif i call FltReleaseFileNameInformation(nameInfo) then
the problem exist…!!!

after a couple of filtering it gives error…!!!

i did’t find any special information while using those couple
of functionss…!!! except freeing the
PFLT_FILE_NAME_INFORMATION by calling function which reduce
its refrence count…!!!

help me i m stuckin …!!!

thanku in advance…!!!1

You cannot reliably call FltGetFileNameInformation or
FltParseFileNameInformation except in pre-Create or pre-SetInfo callbacks.

You must call them there, save the information in a stream context, use it
when you need it (like in your pre-Read operation), and then release it when
you are done with it (typically context cleanup).

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Tuesday, October 24, 2006 8:55 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem in
FltParseFileNameInformation…!!!

i m a new bee to filter driver development…!!!

i m just trying simple things in my filter…!!!1

i was try to get the filename in a read pre-operation callback

it works fine but after couple of seconds since initiaiton filtering with my

mini-driver I receive the following error in the debugger:

Access violation - code c0000005 (!!! second chance !!!)

after anayzing the bugcheck and and traversing through stack each and every
time i found the main curlpret is FltParseFileNameInformation()
function…!!!

just have a look at the code and i do’t know why it did’t work…!!!

callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags)
{
PFLT_FILE_NAME_INFORMATION nameInfo;
NTSTATUS status;

status = FltGetFileNameInformation(
Data,
FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
&nameInfo );
----->>>status = FltParseFileNameInformation(nameInfo);

}

this perticular line shows error always…!!!

evenif i call FltReleaseFileNameInformation(nameInfo) then the problem
exist…!!!

after a couple of filtering it gives error…!!!

i did’t find any special information while using those couple of
functionss…!!! except freeing the PFLT_FILE_NAME_INFORMATION by calling
function which reduce its refrence count…!!!

help me i m stuckin …!!!

thanku in advance…!!!1


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

Is that really true? The docs for FltGetFileNameInformation() state (in
part):

“…If a minifilter driver retrieves normalized file name
information
in a preoperation callback (PFLT_PRE_OPERATION_CALLBACK) routine
by calling…”

Which implies, to me anyway, that it can be invoked by any preoperation
callback, keeping in mind the noted issue with the above WRT tunneled
names. Other than the usual IRQL restrictions (and the issue with
tunneled names) I didn’t notice this restriction.

I didn’t notice any issues with FltParseFileNameInformation() either…

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, October 24, 2006 9:32 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] problem in
FltParseFileNameInformation…!!!

You cannot reliably call FltGetFileNameInformation or
FltParseFileNameInformation except in pre-Create or
pre-SetInfo callbacks.

You must call them there, save the information in a stream
context, use it when you need it (like in your pre-Read
operation), and then release it when you are done with it
(typically context cleanup).

[snip]

Ken Cross wrote:

You cannot reliably call FltGetFileNameInformation or
FltParseFileNameInformation except in pre-Create or pre-SetInfo callbacks.

What about the Post ops of those two callbacks Ken? Scanner and CTX both
use them there. I did notice
some file names not displaying in my test app the other morning - not
sure if it is because of a limitation of calling
fltgetfilenameinfo in post create or if my pascal port of the fltmgr
headers is still screwed up.

m.

You must call them there, save the information in a stream context, use it
when you need it (like in your pre-Read operation), and then release it when
you are done with it (typically context cleanup).

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: Tuesday, October 24, 2006 8:55 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] problem in
FltParseFileNameInformation…!!!

i m a new bee to filter driver development…!!!

i m just trying simple things in my filter…!!!1

i was try to get the filename in a read pre-operation callback

it works fine but after couple of seconds since initiaiton filtering with my

mini-driver I receive the following error in the debugger:

Access violation - code c0000005 (!!! second chance !!!)

after anayzing the bugcheck and and traversing through stack each and every
time i found the main curlpret is FltParseFileNameInformation()
function…!!!

just have a look at the code and i do’t know why it did’t work…!!!

callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
IN PVOID CompletionContext,
IN FLT_POST_OPERATION_FLAGS Flags)
{
PFLT_FILE_NAME_INFORMATION nameInfo;
NTSTATUS status;

status = FltGetFileNameInformation(
Data,
FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
&nameInfo );
----->>>status = FltParseFileNameInformation(nameInfo);

}

this perticular line shows error always…!!!

evenif i call FltReleaseFileNameInformation(nameInfo) then the problem
exist…!!!

after a couple of filtering it gives error…!!!

i did’t find any special information while using those couple of
functionss…!!! except freeing the PFLT_FILE_NAME_INFORMATION by calling
function which reduce its refrence count…!!!

help me i m stuckin …!!!

thanku in advance…!!!1


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

You can call FltGetFileNameInformation from anywhere you like, as long as
you are at IRQL<dispatch_level. however you must be prepared to accept>failure of the call under the conditions listed in the return value section
of the documentation. This is what Ken means by “reliably”…not that you
can’t call it, but that it might not work. I do disagree with Ken’s list
however. I believe the most reliable place to call it is in Post Create,
because it can query the file system, and not rely on the user’s requested
file name.

The OP apparently did not check the return status of
FltGetFileNameInformation, and then blindly used the (allegedly) returned
pointer. Naturally, this caused an accvio.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Tuesday, October 24, 2006 7:56 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] problem in
FltParseFileNameInformation…!!!

Ken Cross wrote:

>You cannot reliably call FltGetFileNameInformation or
>FltParseFileNameInformation except in pre-Create or pre-SetInfo callbacks.
>
>
What about the Post ops of those two callbacks Ken? Scanner and CTX both
use them there. I did notice
some file names not displaying in my test app the other morning - not
sure if it is because of a limitation of calling fltgetfilenameinfo in post
create or if my pascal port of the fltmgr
headers is still screwed up.

m.

>You must call them there, save the information in a stream context, use
>it when you need it (like in your pre-Read operation), and then release
>it when you are done with it (typically context cleanup).
>
>Ken
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@yahoo.com
>Sent: Tuesday, October 24, 2006 8:55 AM
>To: Windows File Systems Devs Interest List
>Subject: [ntfsd] problem in
>FltParseFileNameInformation…!!!
>
>i m a new bee to filter driver development…!!!
>
>i m just trying simple things in my filter…!!!1
>
>i was try to get the filename in a read pre-operation callback
>
>it works fine but after couple of seconds since initiaiton filtering
>with my
>
>mini-driver I receive the following error in the debugger:
>
>Access violation - code c0000005 (!!! second chance !!!)
>
>
>after anayzing the bugcheck and and traversing through stack each and
>every time i found the main curlpret is FltParseFileNameInformation()
>function…!!!
>
>just have a look at the code and i do’t know why it did’t work…!!!
>
>
>callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
> IN PCFLT_RELATED_OBJECTS FltObjects,
> IN PVOID CompletionContext,
> IN FLT_POST_OPERATION_FLAGS Flags)
>{
>PFLT_FILE_NAME_INFORMATION nameInfo;
>NTSTATUS status;
>
>
>status = FltGetFileNameInformation(
> Data,
> FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
> &nameInfo );
>----->>>status = FltParseFileNameInformation(nameInfo);
>
>}
>
>
>this perticular line shows error always…!!!
>
>evenif i call FltReleaseFileNameInformation(nameInfo) then the problem
>exist…!!!
>
>
>after a couple of filtering it gives error…!!!
>
>i did’t find any special information while using those couple of
>functionss…!!! except freeing the PFLT_FILE_NAME_INFORMATION by
>calling function which reduce its refrence count…!!!
>
>
>
>help me i m stuckin …!!!
>
>
>thanku in advance…!!!1
>
>
>
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


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

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</dispatch_level.>

Dan:

You are correct – there are other places you can call
FltGetFileNameInformation, but you must be careful. For example:

“If a minifilter driver retrieves normalized file name information in the
preoperation callback routine (PFLT_PRE_OPERATION_CALLBACK) for a create,
hard-link, or rename operation, it must call FltGetTunneledName from its
postoperation callback routine (PFLT_POST_OPERATION_CALLBACK) to retrieve
the correct file name information for the file.”

Furthermore, there’s a fair amount of overhead in calling
FltGetFileNameInformation/FltParseFileNameInformation, so IMHO it’s a Bad
Idea to invoke them on every read operation. It really should be saved in
the context.

Also, I’m not sure it will work correctly on paging I/O read operations. I
can’t say that with certainty, though, but it should be checked out.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, October 24, 2006 10:24 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] problem in
FltParseFileNameInformation…!!!

You can call FltGetFileNameInformation from anywhere you like, as long as
you are at IRQL<dispatch_level. however you must be prepared to accept>failure of the call under the conditions listed in the return value section
of the documentation. This is what Ken means by “reliably”…not that you
can’t call it, but that it might not work. I do disagree with Ken’s list
however. I believe the most reliable place to call it is in Post Create,
because it can query the file system, and not rely on the user’s requested
file name.

The OP apparently did not check the return status of
FltGetFileNameInformation, and then blindly used the (allegedly) returned
pointer. Naturally, this caused an accvio.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Tuesday, October 24, 2006 7:56 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] problem in
FltParseFileNameInformation…!!!

Ken Cross wrote:

>You cannot reliably call FltGetFileNameInformation or
>FltParseFileNameInformation except in pre-Create or pre-SetInfo callbacks.
>
>
What about the Post ops of those two callbacks Ken? Scanner and CTX both
use them there. I did notice
some file names not displaying in my test app the other morning - not
sure if it is because of a limitation of calling fltgetfilenameinfo in post
create or if my pascal port of the fltmgr
headers is still screwed up.

m.

>You must call them there, save the information in a stream context, use
>it when you need it (like in your pre-Read operation), and then release
>it when you are done with it (typically context cleanup).
>
>Ken
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@yahoo.com
>Sent: Tuesday, October 24, 2006 8:55 AM
>To: Windows File Systems Devs Interest List
>Subject: [ntfsd] problem in
>FltParseFileNameInformation…!!!
>
>i m a new bee to filter driver development…!!!
>
>i m just trying simple things in my filter…!!!1
>
>i was try to get the filename in a read pre-operation callback
>
>it works fine but after couple of seconds since initiaiton filtering
>with my
>
>mini-driver I receive the following error in the debugger:
>
>Access violation - code c0000005 (!!! second chance !!!)
>
>
>after anayzing the bugcheck and and traversing through stack each and
>every time i found the main curlpret is FltParseFileNameInformation()
>function…!!!
>
>just have a look at the code and i do’t know why it did’t work…!!!
>
>
>callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
> IN PCFLT_RELATED_OBJECTS FltObjects,
> IN PVOID CompletionContext,
> IN FLT_POST_OPERATION_FLAGS Flags)
>{
>PFLT_FILE_NAME_INFORMATION nameInfo;
>NTSTATUS status;
>
>
>status = FltGetFileNameInformation(
> Data,
> FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
> &nameInfo );
>----->>>status = FltParseFileNameInformation(nameInfo);
>
>}
>
>
>this perticular line shows error always…!!!
>
>evenif i call FltReleaseFileNameInformation(nameInfo) then the problem
>exist…!!!
>
>
>after a couple of filtering it gives error…!!!
>
>i did’t find any special information while using those couple of
>functionss…!!! except freeing the PFLT_FILE_NAME_INFORMATION by
>calling function which reduce its refrence count…!!!
>
>
>
>help me i m stuckin …!!!
>
>
>thanku in advance…!!!1
>
>
>
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


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

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com</dispatch_level.>

Dan Kyler wrote:

however. I believe the most reliable place to call it is in Post Create,
because it can query the file system, and not rely on the user’s requested
file name.

Even that isn’t that reliable - not all files have a filename to query
even in postcreate (not sure of the exact sequence that causes this but
I’ve seen it, debugged the resulting bluescreen, etc…)

Tony

I agree. Unless for some reason I really need the name in pre-create, I
query it in post-create and save it in the context.

Paging I/O (read or write) is one of the paths where querying the file
system would cause a deadlock. Calling it in FltGetFileNameInformation here
would return an error.

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ken Cross
Sent: Tuesday, October 24, 2006 9:33 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] problem in
FltParseFileNameInformation…!!!

Dan:

You are correct – there are other places you can call
FltGetFileNameInformation, but you must be careful. For example:

“If a minifilter driver retrieves normalized file name information in the
preoperation callback routine (PFLT_PRE_OPERATION_CALLBACK) for a create,
hard-link, or rename operation, it must call FltGetTunneledName from its
postoperation callback routine (PFLT_POST_OPERATION_CALLBACK) to retrieve
the correct file name information for the file.”

Furthermore, there’s a fair amount of overhead in calling
FltGetFileNameInformation/FltParseFileNameInformation, so IMHO it’s a Bad
Idea to invoke them on every read operation. It really should be saved in
the context.

Also, I’m not sure it will work correctly on paging I/O read operations. I
can’t say that with certainty, though, but it should be checked out.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Tuesday, October 24, 2006 10:24 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] problem in
FltParseFileNameInformation…!!!

You can call FltGetFileNameInformation from anywhere you like, as long as
you are at IRQL<dispatch_level. however you must be prepared to accept>failure of the call under the conditions listed in the return value section
of the documentation. This is what Ken means by “reliably”…not that you
can’t call it, but that it might not work. I do disagree with Ken’s list
however. I believe the most reliable place to call it is in Post Create,
because it can query the file system, and not rely on the user’s requested
file name.

The OP apparently did not check the return status of
FltGetFileNameInformation, and then blindly used the (allegedly) returned
pointer. Naturally, this caused an accvio.

- Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of MM
Sent: Tuesday, October 24, 2006 7:56 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] problem in
FltParseFileNameInformation…!!!

Ken Cross wrote:

>You cannot reliably call FltGetFileNameInformation or
>FltParseFileNameInformation except in pre-Create or pre-SetInfo callbacks.
>
>
What about the Post ops of those two callbacks Ken? Scanner and CTX both
use them there. I did notice
some file names not displaying in my test app the other morning - not
sure if it is because of a limitation of calling fltgetfilenameinfo in post
create or if my pascal port of the fltmgr
headers is still screwed up.

m.

>You must call them there, save the information in a stream context, use
>it when you need it (like in your pre-Read operation), and then release
>it when you are done with it (typically context cleanup).
>
>Ken
>
>
>-----Original Message-----
>From: xxxxx@lists.osr.com
>[mailto:xxxxx@lists.osr.com] On Behalf Of
>xxxxx@yahoo.com
>Sent: Tuesday, October 24, 2006 8:55 AM
>To: Windows File Systems Devs Interest List
>Subject: [ntfsd] problem in
>FltParseFileNameInformation…!!!
>
>i m a new bee to filter driver development…!!!
>
>i m just trying simple things in my filter…!!!1
>
>i was try to get the filename in a read pre-operation callback
>
>it works fine but after couple of seconds since initiaiton filtering
>with my
>
>mini-driver I receive the following error in the debugger:
>
>Access violation - code c0000005 (!!! second chance !!!)
>
>
>after anayzing the bugcheck and and traversing through stack each and
>every time i found the main curlpret is FltParseFileNameInformation()
>function…!!!
>
>just have a look at the code and i do’t know why it did’t work…!!!
>
>
>callback_function…(IN OUT PFLT_CALLBACK_DATA Data,
> IN PCFLT_RELATED_OBJECTS FltObjects,
> IN PVOID CompletionContext,
> IN FLT_POST_OPERATION_FLAGS Flags)
>{
>PFLT_FILE_NAME_INFORMATION nameInfo;
>NTSTATUS status;
>
>
>status = FltGetFileNameInformation(
> Data,
> FLT_FILE_NAME_NORMALIZED|FLT_FILE_NAME_QUERY_DEFAULT,
> &nameInfo );
>----->>>status = FltParseFileNameInformation(nameInfo);
>
>}
>
>
>this perticular line shows error always…!!!
>
>evenif i call FltReleaseFileNameInformation(nameInfo) then the problem
>exist…!!!
>
>
>after a couple of filtering it gives error…!!!
>
>i did’t find any special information while using those couple of
>functionss…!!! except freeing the PFLT_FILE_NAME_INFORMATION by
>calling function which reduce its refrence count…!!!
>
>
>
>help me i m stuckin …!!!
>
>
>thanku in advance…!!!1
>
>
>
>
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>—
>Questions? First check the IFS FAQ at
>https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net To
>unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>


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

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net To unsubscribe
send a blank email to xxxxx@lists.osr.com


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

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</dispatch_level.>

Why would you get a blue screen querying the file name in post-create (i.e.
actually querying it–not trying to access the FileObject->FileName, which
is illegal)?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Hoyle
Sent: Tuesday, October 24, 2006 9:46 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] problem in
FltParseFileNameInformation…!!!

Dan Kyler wrote:

however. I believe the most reliable place to call it is in Post
Create, because it can query the file system, and not rely on the
user’s requested file name.

Even that isn’t that reliable - not all files have a filename to query
even in postcreate (not sure of the exact sequence that causes this but
I’ve seen it, debugged the resulting bluescreen, etc…)

Tony


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

You are currently subscribed to ntfsd as: xxxxx@privtek.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

Dan Kyler wrote:

Why would you get a blue screen querying the file name in post-create (i.e.
actually querying it–not trying to access the FileObject->FileName, which
is illegal)?

If you forget to check the return from FltGetFileNameInformation then
call FltParseFileNameInformation it falls over.

That one was hard to track down since FltGetFileNameInformation only
fails in a tiny minority of cases - the driver could be running for
hours then fall over, or it could die immediately, apparently randomly
(driver verifier doesn’t catch this either).

Tony

ya i did’t check the status of FltGetFileNameInformation() and directly call the FltParseFileNameInformation()…

thanks it works…!!!

even in every pre-op-callback…!!! as some experts says that is not the right place to call these functions…!!!

but when should i release PFLT_FILE_NAME_INFORMATION structure…???
in my calback…???

should i release it every time when i use it…!!!
i used this structure(PFLT_FILE_NAME_INFORMATION ) as a local variable in my function …should i release it bfore fuction return…???

xxxxx@yahoo.com wrote:

should i release it every time when i use it…!!!
i used this structure(PFLT_FILE_NAME_INFORMATION ) as a local variable in my function …should i release it bfore fuction return…???

yes, release it before return.


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

i release it as i said before …!!! but again i got acces voilation error as same…!!!

i have an idea…that

if the variable is local then there is no need to free explicitly…???
and freeing the structure(PFLT_FILE_NAME_INFORMATION ) using function FltReleaseFilenameInformation( ).

but this function decrease the refrence count of that structure…!!! not freeing it actually…!!!
this will be a nice idea in case the variable is global…!!!

welll all those are quesstions aand IDEAS tooo…!!! (plz took consideration that i m a new bee…)…!!!.

agin thank u for ur reply…!!!
:slight_smile:

If you have a local variable that contains a full pathname, you have already
made a mistake. The stack is too limited for that. Allocate memory and
store the pointer to the string in the context for this file. When you are
notified that this file is no longer being referenced, free the memory.
Remember, I think, that FsContext refers to one file and the stream (maybe
the default) that was opened/created. The cache manager can use a different
file object for its work.

wrote in message news:xxxxx@ntfsd…
>i release it as i said before …!!! but again i got acces voilation error
>as same…!!!
>
> i have an idea…that
>
> if the variable is local then there is no need to free
> explicitly…???
> and freeing the structure(PFLT_FILE_NAME_INFORMATION ) using function
> FltReleaseFilenameInformation( ).
>
> but this function decrease the refrence count of that structure…!!!
> not freeing it actually…!!!
> this will be a nice idea in case the variable is global…!!!
>
> welll all those are quesstions aand IDEAS tooo…!!! (plz took
> consideration that i m a new bee…)…!!!.
>
> agin thank u for ur reply…!!!
> :slight_smile:
>
>
>
>

What does your code sequence look like? How are you testing for Success?
Right after your call to FltGetFileNameinfo are you testing with if
(!NT_SUCCESS( status )) ? If so,
at what point do you call the release? Sounds like your testing and
releasing with incorrect logic.

m.

xxxxx@yahoo.com wrote:

i release it as i said before …!!! but again i got acces voilation error as same…!!!

i have an idea…that

if the variable is local then there is no need to free explicitly…???
and freeing the structure(PFLT_FILE_NAME_INFORMATION ) using function FltReleaseFilenameInformation( ).

but this function decrease the refrence count of that structure…!!! not freeing it actually…!!!
this will be a nice idea in case the variable is global…!!!

welll all those are quesstions aand IDEAS tooo…!!! (plz took consideration that i m a new bee…)…!!!.

agin thank u for ur reply…!!!
:slight_smile:


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

the code snippts are look like…!!!

FLT_PREOP_CALLBACK_STATUS
PtPreOperationPassThrough (
IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
OUT PVOID *CompletionContext
)

{
NTSTATUS status;

KIRQL flt_irql;

UNREFERENCED_PARAMETER( FltObjects );
UNREFERENCED_PARAMETER( CompletionContext );

PT_DBG_PRINT( PTDBG_TRACE_ROUTINES,
(“PassThrough!PtPreOperationPassThrough: Entered\n”) );

if (NT_SUCCESS(Data->IoStatus.Status) )
{

flt_irql = KeGetCurrentIrql();
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED |FLT_FILE_NAME_QUERY_DEFAULT,
&FileI);

if (NT_SUCCESS(status))
{

status = FltParseFileNameInformation( FileI );

if (!NT_SUCCESS(status))
{
DbgPrint(“KMSEC!KMSECPostCreate: FltParseFileNameInformation returned an error.\n”);

**=====>>> // FltReleaseFileNameInformation( FileI );

}
}

else
{
FileI = NULL;
}

}

if (PtDoRequestOperationStatus( Data )) {

status = FltRequestOperationStatusCallback( Data,
PtOperationStatusCallback,
(PVOID)(++OperationStatusCtx) );
if (!NT_SUCCESS(status)) {

PT_DBG_PRINT( PTDBG_TRACE_OPERATION_STATUS,
(“PassThrough!PtPreOperationPassThrough: FltRequestOperationStatusCallback Failed, status=%08x\n”,
status) );
}
}

**=====>>> //FltReleaseFileNameInformation( FileI );

return FLT_PREOP_SUCCESS_WITH_CALLBACK;
}

if either of those **=====>>> //FltReleaseFileNameInformation( FileI ); are un-comment the error occurs…!!!

Access violation - code c0000005 (!!! second chance !!!)

i m in confusion…!!!

help…!!!
:frowning:

ic you changed some things since the other morning. you do have FileI
declared right, or is this
just a bad cut and paste job?

I don’t see anything jumping out at me, I’ll build a test filter real
quick - curious

m.
xxxxx@yahoo.com wrote:

the code snippts are look like…!!!

FLT_PREOP_CALLBACK_STATUS
PtPreOperationPassThrough (
IN OUT PFLT_CALLBACK_DATA Data,
IN PCFLT_RELATED_OBJECTS FltObjects,
OUT PVOID *CompletionContext
)

{
NTSTATUS status;

KIRQL flt_irql;

UNREFERENCED_PARAMETER( FltObjects );
UNREFERENCED_PARAMETER( CompletionContext );

PT_DBG_PRINT( PTDBG_TRACE_ROUTINES,
(“PassThrough!PtPreOperationPassThrough: Entered\n”) );

if (NT_SUCCESS(Data->IoStatus.Status) )
{

flt_irql = KeGetCurrentIrql();
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED |FLT_FILE_NAME_QUERY_DEFAULT,
&FileI);

if (NT_SUCCESS(status))
{

status = FltParseFileNameInformation( FileI );

if (!NT_SUCCESS(status))
{
DbgPrint(“KMSEC!KMSECPostCreate: FltParseFileNameInformation returned an error.\n”);

**=====>>> // FltReleaseFileNameInformation( FileI );

}
}

else
{
FileI = NULL;
}

}

if (PtDoRequestOperationStatus( Data )) {

status = FltRequestOperationStatusCallback( Data,
PtOperationStatusCallback,
(PVOID)(++OperationStatusCtx) );
if (!NT_SUCCESS(status)) {

PT_DBG_PRINT( PTDBG_TRACE_OPERATION_STATUS,
(“PassThrough!PtPreOperationPassThrough: FltRequestOperationStatusCallback Failed, status=%08x\n”,
status) );
}
}

**=====>>> //FltReleaseFileNameInformation( FileI );

return FLT_PREOP_SUCCESS_WITH_CALLBACK;
}

if either of those **=====>>> //FltReleaseFileNameInformation( FileI ); are un-comment the error occurs…!!!

Access violation - code c0000005 (!!! second chance !!!)

i m in confusion…!!!

help…!!!
:frowning:


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

You are currently subscribed to ntfsd as: xxxxx@comcast.net
To unsubscribe send a blank email to xxxxx@lists.osr.com

ya i have declared ***** FLT_FILE_NAME_INFORMATION FileI***** as a global variable…!!!

actually i am testing around PASSTHROUGH sample in the IFS kit…!!!

i have’t done changes in that sample except the global variable and

then added some lines(not removed even a single line from that sample)

as in the CODE-SNIPPT u r have already saw…!!!

i m clearing my fundas of filtering file-system operation…!!!

help me…!!! i m a kid in front of u experts…!!!

thanku…
:slight_smile:

Did you declare this global, which tbh it shouldn’t be (remember that
you are in a multithreaded environment), as:-

FLT_FILE_NAME_INFORMATION FileI;

If you did then you need to re-read the docs for
FltGetFileNameInformation. The definition reads:-

NTSTATUS
FltGetFileNameInformation(
IN PFLT_CALLBACK_DATA CallbackData,
IN FLT_FILE_NAME_OPTIONS NameOptions,
OUT PFLT_FILE_NAME_INFORMATION *FileNameInformation
);

The FileNameInformation parameter is a pointer to pointer. So your
definition should be

PFLT_FILE_NAME_INFORMATION FileI;

There are also several things wrong with the snippet of code you posted,
for example it is possible you calling release on something you never
acquired (the release at the bottom of the code). If the call to
FltGetFileNameInformation fails you are setting FileI to NULL, then
still calling release!

As this code is based on the passthrough sample that preop callback is
being called for every IRP!

My suggestion is to stop now. Read the documentation until you know it
backwards, read some of the other minifilter samples that actually do
something as this will give you a better idea on how to use the
minifilter functions.

Ben Curley
Data Encryption Systems Ltd.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@yahoo.com
Sent: 25 October 2006 13:10
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] problem in
FltParseFileNameInformation…!!!

ya i have declared ***** FLT_FILE_NAME_INFORMATION FileI***** as a
global variable…!!!

actually i am testing around PASSTHROUGH sample in the IFS
kit…!!!

i have’t done changes in that sample except the global variable and

then added some lines(not removed even a single line from that sample)

as in the CODE-SNIPPT u r have already saw…!!!

i m clearing my fundas of filtering file-system operation…!!!

help me…!!! i m a kid in front of u experts…!!!

thanku…
:slight_smile:


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

You are currently subscribed to ntfsd as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com