Problem with FltGetFileNameInformation

NTFSD
1

Hello gentlemen,

I have been experimenting with writing a simple minifilter for the past
few days, but I have come across a nasty problem.

This is my current PreOperationCallback:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

As you can see, it’s some pretty useless and (as far as I can tell)
bug-free code. Nonetheless, it will sometimes cause hard lock-ups and
force me to reboot my machine. However, that only happens when I open a
Microsoft Visio document I have on my desktop. At first, I thought the
document was the problem, so I rebooted and tried to open it without
loading the minifilter. Unfortunately, it all worked like a charm (like
it always did); so I loaded the minifilter and opened the Visio document
again… and that triggered the freeze.

After that, I tried to comment the call to FltGetFileNameInformation and
re-test opening the Visio document -> no freeze.
Un-commented it back -> freeze again.

Any idea what the problem is?

  • is there a bug in the code above?
  • is there a known bug in the FltGetFileNameInformation function (and
    maybe the FltMgr.sys I have is old)?
  • could my Visio document be the only culprit?

The minifilter seems to work fine and act stable besides when opening
that Visio document, but I’m not 100% sure since I had no time to test
many other programs. I do not have any other Visio document to test, in
order to check out if the problem is Visio itself. However, I noticed
that if I reboot my machine, open the Visio document, close it, load the
minifilter and re-open the Visio document -> the freeze does NOT occur
anymore. It only happens first time I load Visio after a reboot.

Ah, the same thing happens when using the stock “MiniSpy” sample code.
Same lock-up caused by FltGetFileNameInformation when opening the Visio
document.

Thanks for your attention,

  • AS

OS version: Windows XP SP2
WDK version: 6001

2

Alessandro Sardo wrote:

Any idea what the problem is?

  • is there a bug in the code above?
  • is there a known bug in the FltGetFileNameInformation function (and
    maybe the FltMgr.sys I have is old)?
  • could my Visio document be the only culprit?

The code is fine, the only thing I notice as a problem is that it’s
a generic PreOp, not pre-create only pre-op, right? You shouldn’t get the
name except the pre-op, thought he API will (it’s designed to) not try to
retrieve the file name if it’s not safe (the docs remark cases like when
TopLevelIrp != NULL).
That said, I did notice the same thing with Altiris Virtualization
software - only the above code was enough to hang the machine. No update
helped, Visio isn’t the only culprit and the code is fine. So it’s an FltMgr
internal issue (maybe a case where it shouldn’t query but it does, I don’t
know - someone from MS looked into it, but said it’s not FltMgr issue; they
said the same thing for 5+ other things I reported though)

OT: did anyone notice the wording in the default NTFSD list sig?
(missing “on” before debugging?)

For our schedule debugging and file system seminars (including our new fs
mini-filter seminar) visit:
http://www.osr.com/seminars

–
Kind regards, Dejan (MSN support: xxxxx@alfasp.com)
http://www.alfasp.com
File system audit, security and encryption kits.

3

Another possible explanation is that you’re not checking for success on the call to FltGetFileNameInformation.

If the call is not successful, it’s possible that nameInfo is not null. In that case, the call to FltReleaseFileNameInformation
could have unknown behavior. I don’t know if this is happening, but it’s theoretically possible.

So does changing it to this make any difference?

if ( NT_SUCCESS( status ) && nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Saturday, December 08, 2007 3:43 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem with FltGetFileNameInformation

Hello gentlemen,

I have been experimenting with writing a simple minifilter for the past
few days, but I have come across a nasty problem.

This is my current PreOperationCallback:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

As you can see, it’s some pretty useless and (as far as I can tell)
bug-free code. Nonetheless, it will sometimes cause hard lock-ups and
force me to reboot my machine. However, that only happens when I open a
Microsoft Visio document I have on my desktop. At first, I thought the
document was the problem, so I rebooted and tried to open it without
loading the minifilter. Unfortunately, it all worked like a charm (like
it always did); so I loaded the minifilter and opened the Visio document
again… and that triggered the freeze.

After that, I tried to comment the call to FltGetFileNameInformation and
re-test opening the Visio document -> no freeze.
Un-commented it back -> freeze again.

Any idea what the problem is?

  • is there a bug in the code above?
  • is there a known bug in the FltGetFileNameInformation function (and
    maybe the FltMgr.sys I have is old)?
  • could my Visio document be the only culprit?

The minifilter seems to work fine and act stable besides when opening
that Visio document, but I’m not 100% sure since I had no time to test
many other programs. I do not have any other Visio document to test, in
order to check out if the problem is Visio itself. However, I noticed
that if I reboot my machine, open the Visio document, close it, load the
minifilter and re-open the Visio document -> the freeze does NOT occur
anymore. It only happens first time I load Visio after a reboot.

Ah, the same thing happens when using the stock “MiniSpy” sample code.
Same lock-up caused by FltGetFileNameInformation when opening the Visio
document.

Thanks for your attention,

  • AS

OS version: Windows XP SP2
WDK version: 6001

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

4

Hello,

I have already tried that and it didn’t change anything. The culprit
really seems to be FltReleaseFileNameInformation.

For your information, these are the registered IRPs through the same
pre-callback:

CONST FLT_OPERATION_REGISTRATION Callbacks =
{
{ IRP_MJ_CREATE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_READ,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_WRITE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_SET_INFORMATION,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_FILE_SYSTEM_CONTROL,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_OPERATION_END }
};

Thank you all for your help!

  • AS

Ken Cross ha scritto:

Another possible explanation is that you’re not checking for success on the call to FltGetFileNameInformation.

If the call is not successful, it’s possible that nameInfo is not null. In that case, the call to FltReleaseFileNameInformation
could have unknown behavior. I don’t know if this is happening, but it’s theoretically possible.

So does changing it to this make any difference?

if ( NT_SUCCESS( status ) && nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Saturday, December 08, 2007 3:43 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem with FltGetFileNameInformation

Hello gentlemen,

I have been experimenting with writing a simple minifilter for the past
few days, but I have come across a nasty problem.

This is my current PreOperationCallback:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

As you can see, it’s some pretty useless and (as far as I can tell)
bug-free code. Nonetheless, it will sometimes cause hard lock-ups and
force me to reboot my machine. However, that only happens when I open a
Microsoft Visio document I have on my desktop. At first, I thought the
document was the problem, so I rebooted and tried to open it without
loading the minifilter. Unfortunately, it all worked like a charm (like
it always did); so I loaded the minifilter and opened the Visio document
again… and that triggered the freeze.

After that, I tried to comment the call to FltGetFileNameInformation and
re-test opening the Visio document -> no freeze.
Un-commented it back -> freeze again.

Any idea what the problem is?

  • is there a bug in the code above?
  • is there a known bug in the FltGetFileNameInformation function (and
    maybe the FltMgr.sys I have is old)?
  • could my Visio document be the only culprit?

The minifilter seems to work fine and act stable besides when opening
that Visio document, but I’m not 100% sure since I had no time to test
many other programs. I do not have any other Visio document to test, in
order to check out if the problem is Visio itself. However, I noticed
that if I reboot my machine, open the Visio document, close it, load the
minifilter and re-open the Visio document -> the freeze does NOT occur
anymore. It only happens first time I load Visio after a reboot.

Ah, the same thing happens when using the stock “MiniSpy” sample code.
Same lock-up caused by FltGetFileNameInformation when opening the Visio
document.

Thanks for your attention,

  • AS

OS version: Windows XP SP2
WDK version: 6001

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

5

So, if you leave the call to FltGetFileNameInformation but comment out the call to FltReleaseFileNameInformation, it doesn’t freeze?

(Of course, this keeps the reference to nameInfo forever, but…)

Also, could the IRQL be > APC_LEVEL? Try:

if ( KeGetCurrentIrql() <= APC_LEVEL )
{
…
}

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Sunday, December 09, 2007 12:19 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with FltGetFileNameInformation

Hello,

I have already tried that and it didn’t change anything. The culprit
really seems to be FltReleaseFileNameInformation.

For your information, these are the registered IRPs through the same
pre-callback:

CONST FLT_OPERATION_REGISTRATION Callbacks =
{
{ IRP_MJ_CREATE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_READ,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_WRITE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_SET_INFORMATION,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_FILE_SYSTEM_CONTROL,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_OPERATION_END }
};

Thank you all for your help!

  • AS

Ken Cross ha scritto:

Another possible explanation is that you’re not checking for success on the call to FltGetFileNameInformation.

If the call is not successful, it’s possible that nameInfo is not null. In that case, the call to FltReleaseFileNameInformation
could have unknown behavior. I don’t know if this is happening, but it’s theoretically possible.

So does changing it to this make any difference?

if ( NT_SUCCESS( status ) && nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Saturday, December 08, 2007 3:43 PM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Problem with FltGetFileNameInformation

Hello gentlemen,

I have been experimenting with writing a simple minifilter for the past
few days, but I have come across a nasty problem.

This is my current PreOperationCallback:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

As you can see, it’s some pretty useless and (as far as I can tell)
bug-free code. Nonetheless, it will sometimes cause hard lock-ups and
force me to reboot my machine. However, that only happens when I open a
Microsoft Visio document I have on my desktop. At first, I thought the
document was the problem, so I rebooted and tried to open it without
loading the minifilter. Unfortunately, it all worked like a charm (like
it always did); so I loaded the minifilter and opened the Visio document
again… and that triggered the freeze.

After that, I tried to comment the call to FltGetFileNameInformation and
re-test opening the Visio document -> no freeze.
Un-commented it back -> freeze again.

Any idea what the problem is?

  • is there a bug in the code above?
  • is there a known bug in the FltGetFileNameInformation function (and
    maybe the FltMgr.sys I have is old)?
  • could my Visio document be the only culprit?

The minifilter seems to work fine and act stable besides when opening
that Visio document, but I’m not 100% sure since I had no time to test
many other programs. I do not have any other Visio document to test, in
order to check out if the problem is Visio itself. However, I noticed
that if I reboot my machine, open the Visio document, close it, load the
minifilter and re-open the Visio document -> the freeze does NOT occur
anymore. It only happens first time I load Visio after a reboot.

Ah, the same thing happens when using the stock “MiniSpy” sample code.
Same lock-up caused by FltGetFileNameInformation when opening the Visio
document.

Thanks for your attention,

  • AS

OS version: Windows XP SP2
WDK version: 6001

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

6

Sorry, I copied and pasted the wrong name. I meant the problem is
actually FltGetFileNameInformation.

In fact, the following code triggers the hard lock-up:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( KeGetCurrentIrql() <= APC_LEVEL )
{
if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
// if ( nameInfo != NULL )
// FltReleaseFileNameInformation( nameInfo );
}

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

By the way, I found out that the problem is not with the Visio document.
It’s just with Microsoft Visio itself… as soon as I load it up,
everything will freeze. Obviously, that doesn’t happen when the
minifilter is not active.

  • AS

Ken Cross ha scritto:

So, if you leave the call to FltGetFileNameInformation but comment out the call to FltReleaseFileNameInformation, it doesn’t freeze?

(Of course, this keeps the reference to nameInfo forever, but…)

Also, could the IRQL be > APC_LEVEL? Try:

if ( KeGetCurrentIrql() <= APC_LEVEL )
{
…
}

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Sunday, December 09, 2007 12:19 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with FltGetFileNameInformation

Hello,

I have already tried that and it didn’t change anything. The culprit
really seems to be FltReleaseFileNameInformation.

For your information, these are the registered IRPs through the same
pre-callback:

CONST FLT_OPERATION_REGISTRATION Callbacks =
{
{ IRP_MJ_CREATE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_READ,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_WRITE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_SET_INFORMATION,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_FILE_SYSTEM_CONTROL,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_OPERATION_END }
};

Thank you all for your help!

  • AS

Ken Cross ha scritto:

> Another possible explanation is that you’re not checking for success on the call to FltGetFileNameInformation.
>
> If the call is not successful, it’s possible that nameInfo is not null. In that case, the call to FltReleaseFileNameInformation
> could have unknown behavior. I don’t know if this is happening, but it’s theoretically possible.
>
> So does changing it to this make any difference?
>
> if ( NT_SUCCESS( status ) && nameInfo != NULL )
> FltReleaseFileNameInformation( nameInfo );
>
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
> Sent: Saturday, December 08, 2007 3:43 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Problem with FltGetFileNameInformation
>
> Hello gentlemen,
>
> I have been experimenting with writing a simple minifilter for the past
> few days, but I have come across a nasty problem.
>
> This is my current PreOperationCallback:
>
> FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
> PFLT_CALLBACK_DATA Data,
> __in
> PCFLT_RELATED_OBJECTS FltObjects,
> __deref_out_opt
> PVOID *CompletionContext )
> {
> PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
> NTSTATUS status;
>
> *CompletionContext = NULL;
>
> if ( FltObjects->FileObject != NULL )
> status = FltGetFileNameInformation( Data,
> FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
> if ( nameInfo != NULL )
> FltReleaseFileNameInformation( nameInfo );
>
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
> }
>
> As you can see, it’s some pretty useless and (as far as I can tell)
> bug-free code. Nonetheless, it will sometimes cause hard lock-ups and
> force me to reboot my machine. However, that only happens when I open a
> Microsoft Visio document I have on my desktop. At first, I thought the
> document was the problem, so I rebooted and tried to open it without
> loading the minifilter. Unfortunately, it all worked like a charm (like
> it always did); so I loaded the minifilter and opened the Visio document
> again… and that triggered the freeze.
>
> After that, I tried to comment the call to FltGetFileNameInformation and
> re-test opening the Visio document -> no freeze.
> Un-commented it back -> freeze again.
>
> Any idea what the problem is?
>
> - is there a bug in the code above?
> - is there a known bug in the FltGetFileNameInformation function (and
> maybe the FltMgr.sys I have is old)?
> - could my Visio document be the only culprit?
>
> The minifilter seems to work fine and act stable besides when opening
> that Visio document, but I’m not 100% sure since I had no time to test
> many other programs. I do not have any other Visio document to test, in
> order to check out if the problem is Visio itself. However, I noticed
> that if I reboot my machine, open the Visio document, close it, load the
> minifilter and re-open the Visio document -> the freeze does NOT occur
> anymore. It only happens first time I load Visio after a reboot.
>
> Ah, the same thing happens when using the stock “MiniSpy” sample code.
> Same lock-up caused by FltGetFileNameInformation when opening the Visio
> document.
>
> Thanks for your attention,
>
> - AS
>
> -----------------
>
> OS version: Windows XP SP2
> WDK version: 6001
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@polito.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

7

Hi Alessandro,

Is it happening for a particular operation ( Major Function ) or any random
one?
And before you are calling the FltGetFileNameInformation, could you just
check the following:

  1. IRQL
  2. Major Function
  3. TopLevelIrp
  4. Whether it’s a Paging I/O operation

Also, as a separate test, try to set
FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO in the
FLT_OPERATION_REGISTRATION structure.

Although these checks should be performed EXPLICITLY by Filter manager,
nevertheless try finding out the exact scenario.
And then let’s see, what the problem is.

Regards,
Ayush Gupta

8

The one remaining thing I can think of is to remove the callbacks one by one. For example, start with just pre-create. If that
works, add one at a time until it locks up. After that, I think it’s MS’s problem.

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Sunday, December 09, 2007 1:12 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with FltGetFileNameInformation

Sorry, I copied and pasted the wrong name. I meant the problem is
actually FltGetFileNameInformation.

In fact, the following code triggers the hard lock-up:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( KeGetCurrentIrql() <= APC_LEVEL )
{
if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
// if ( nameInfo != NULL )
// FltReleaseFileNameInformation( nameInfo );
}

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

By the way, I found out that the problem is not with the Visio document.
It’s just with Microsoft Visio itself… as soon as I load it up,
everything will freeze. Obviously, that doesn’t happen when the
minifilter is not active.

  • AS

Ken Cross ha scritto:

So, if you leave the call to FltGetFileNameInformation but comment out the call to FltReleaseFileNameInformation, it doesn’t
freeze?

(Of course, this keeps the reference to nameInfo forever, but…)

Also, could the IRQL be > APC_LEVEL? Try:

if ( KeGetCurrentIrql() <= APC_LEVEL )
{
…
}

Ken

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Sunday, December 09, 2007 12:19 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with FltGetFileNameInformation

Hello,

I have already tried that and it didn’t change anything. The culprit
really seems to be FltReleaseFileNameInformation.

For your information, these are the registered IRPs through the same
pre-callback:

CONST FLT_OPERATION_REGISTRATION Callbacks =
{
{ IRP_MJ_CREATE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_READ,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_WRITE,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_SET_INFORMATION,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_FILE_SYSTEM_CONTROL,
0,
PreFileOperationCallback,
NULL,
NULL },

{ IRP_MJ_OPERATION_END }
};

Thank you all for your help!

  • AS

Ken Cross ha scritto:

> Another possible explanation is that you’re not checking for success on the call to FltGetFileNameInformation.
>
> If the call is not successful, it’s possible that nameInfo is not null. In that case, the call to FltReleaseFileNameInformation
> could have unknown behavior. I don’t know if this is happening, but it’s theoretically possible.
>
> So does changing it to this make any difference?
>
> if ( NT_SUCCESS( status ) && nameInfo != NULL )
> FltReleaseFileNameInformation( nameInfo );
>
>
> Ken
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
> Sent: Saturday, December 08, 2007 3:43 PM
> To: Windows File Systems Devs Interest List
> Subject: [ntfsd] Problem with FltGetFileNameInformation
>
> Hello gentlemen,
>
> I have been experimenting with writing a simple minifilter for the past
> few days, but I have come across a nasty problem.
>
> This is my current PreOperationCallback:
>
> FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
> PFLT_CALLBACK_DATA Data,
> __in
> PCFLT_RELATED_OBJECTS FltObjects,
> __deref_out_opt
> PVOID *CompletionContext )
> {
> PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
> NTSTATUS status;
>
> *CompletionContext = NULL;
>
> if ( FltObjects->FileObject != NULL )
> status = FltGetFileNameInformation( Data,
> FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
> if ( nameInfo != NULL )
> FltReleaseFileNameInformation( nameInfo );
>
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
> }
>
> As you can see, it’s some pretty useless and (as far as I can tell)
> bug-free code. Nonetheless, it will sometimes cause hard lock-ups and
> force me to reboot my machine. However, that only happens when I open a
> Microsoft Visio document I have on my desktop. At first, I thought the
> document was the problem, so I rebooted and tried to open it without
> loading the minifilter. Unfortunately, it all worked like a charm (like
> it always did); so I loaded the minifilter and opened the Visio document
> again… and that triggered the freeze.
>
> After that, I tried to comment the call to FltGetFileNameInformation and
> re-test opening the Visio document -> no freeze.
> Un-commented it back -> freeze again.
>
> Any idea what the problem is?
>
> - is there a bug in the code above?
> - is there a known bug in the FltGetFileNameInformation function (and
> maybe the FltMgr.sys I have is old)?
> - could my Visio document be the only culprit?
>
> The minifilter seems to work fine and act stable besides when opening
> that Visio document, but I’m not 100% sure since I had no time to test
> many other programs. I do not have any other Visio document to test, in
> order to check out if the problem is Visio itself. However, I noticed
> that if I reboot my machine, open the Visio document, close it, load the
> minifilter and re-open the Visio document -> the freeze does NOT occur
> anymore. It only happens first time I load Visio after a reboot.
>
> Ah, the same thing happens when using the stock “MiniSpy” sample code.
> Same lock-up caused by FltGetFileNameInformation when opening the Visio
> document.
>
> Thanks for your attention,
>
> - AS
>
> -----------------
>
> OS version: Windows XP SP2
> WDK version: 6001
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@comcast.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> NTFSD is sponsored by OSR
>
> For our schedule debugging and file system seminars
> (including our new fs mini-filter seminar) visit:
> http://www.osr.com/seminars
>
> You are currently subscribed to ntfsd as: xxxxx@polito.it
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

9

Hello,

I have tried to set FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO in the
FLT_OPERATION_REGISTRATION structure as you suggested, but that didn’t
change anything. Loading MS Visio still triggered the freeze.

Then, I removed FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO and
re-tested with the following code:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( KeGetCurrentIrql() <= APC_LEVEL &&
IoGetTopLevelIrp() == NULL &&
Data->Iopb->IrpFlags != IRP_PAGING_IO )
{
if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data, FLT_FILE_NAME_NORMALIZED |
DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );
}

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

The result was still unsuccessful… always the same lock-up problem as
before.

Finally, I tested each IRPs one by one and managed to find out which IRP
operation causes the problem: it’s IRP_MJ_SET_INFORMATION. After
disabling the callback for that operation, everything worked fine.

So, is it safe to assume that there seems to be a bug in
FltGetFileNameInformation when processing a IRP_MJ_SET_INFORMATION
operation, or is there still something I could check out first?

Thank you all for your help,

  • AS

Ayush Gupta ha scritto:

Hi Alessandro,

Is it happening for a particular operation ( Major Function ) or any
random one?

And before you are calling the FltGetFileNameInformation, could you
just check the following:

  1. IRQL

  2. Major Function

  3. TopLevelIrp

  4. Whether it’s a Paging I/O operation

Also, as a separate test, try to set
FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO in the
FLT_OPERATION_REGISTRATION structure.

Although these checks should be performed EXPLICITLY by Filter
manager, nevertheless try finding out the exact scenario.

And then let’s see, what the problem is.

Regards,

Ayush Gupta

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

You are currently subscribed to ntfsd as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

I was suspecting the same Major Function… Though you forgot to add
IRP_SYNCHRONOUS_PAGING_IO flag in your check

Long time back we also had a problem with IRP_MJ_SET_INFORMATION in our
driver. The case was somewhat different though.
We had also set the FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO flag.
http://www.osronline.com/showThread.cfm?link=103831

Has it got to do something with the *less known* paging
IRP_MJ_SET_INFORMATION (just a wild guess…) ?

Regards,
Ayush Gupta

11

Hello,

upon further investigation I found out that the freeze happens only with
IRP_MJ_SET_INFORMATION -> FilePositionInformation operations. In fact,
with the following code everything worked fine:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( KeGetCurrentIrql() <= APC_LEVEL &&
IoGetTopLevelIrp() == NULL &&
Data->Iopb->IrpFlags != IRP_PAGING_IO &&
Data->Iopb->IrpFlags != IRP_SYNCHRONOUS_PAGING_IO )
{
if ( Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION &&

Data->Iopb->Parameters.SetFileInformation.FileInformationClass ==
FilePositionInformation )
{
return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );
}

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

So, I finally have some work-around to avoid the hard lock-up.

Thank you all for your help,

  • AS

Ayush Gupta ha scritto:

I was suspecting the same Major Function… Though you forgot to add
IRP_SYNCHRONOUS_PAGING_IO flag in your check

Long time back we also had a problem with IRP_MJ_SET_INFORMATION in our
driver. The case was somewhat different though.
We had also set the FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO flag.
http://www.osronline.com/showThread.cfm?link=103831

Has it got to do something with the *less known* paging
IRP_MJ_SET_INFORMATION (just a wild guess…) ?

Regards,
Ayush Gupta

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

12

Hi Alessandro,
Actually you could test one more thing.

Set the FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO flag in the
FLT_OPERATION_REGISTRATION structure.

And then check in your precallback by putting a simple statement,

If(Data->Iopb->IrpFlags == IRP_PAGING_IO &&
Data->Iopb->IrpFlags == IRP_SYNCHRONOUS_PAGING_)
{
ASSERT(FALSE); // compile as checked/ debug build
DbgPrint(“Funny”);
}

Then we can know by surety that even after requesting the Filter Manager NOT
to send Paging I/O requests, we are getting them in the pre-callback of
SetInfo.
And maybe the reason for the deadlock is same. Filter Manager does not treat
Paging IRP_MJ_SET_INFORMATION as Paging I/O and attempts to query the name.
But in reality it is a paging I/O and hence the deadlock.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Alessandro Sardo
Sent: Monday, December 10, 2007 5:16 PM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] Problem with FltGetFileNameInformation

Hello,

upon further investigation I found out that the freeze happens only with
IRP_MJ_SET_INFORMATION -> FilePositionInformation operations. In fact,
with the following code everything worked fine:

FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( __inout
PFLT_CALLBACK_DATA Data,
__in
PCFLT_RELATED_OBJECTS FltObjects,
__deref_out_opt
PVOID *CompletionContext )
{
PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
NTSTATUS status;

*CompletionContext = NULL;

if ( KeGetCurrentIrql() <= APC_LEVEL &&
IoGetTopLevelIrp() == NULL &&
Data->Iopb->IrpFlags != IRP_PAGING_IO &&
Data->Iopb->IrpFlags != IRP_SYNCHRONOUS_PAGING_IO )
{
if ( Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION &&

Data->Iopb->Parameters.SetFileInformation.FileInformationClass ==
FilePositionInformation )
{
return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

if ( FltObjects->FileObject != NULL )
status = FltGetFileNameInformation( Data,
FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
if ( nameInfo != NULL )
FltReleaseFileNameInformation( nameInfo );
}

return FLT_PREOP_SUCCESS_NO_CALLBACK;
}

So, I finally have some work-around to avoid the hard lock-up.

Thank you all for your help,

  • AS

Ayush Gupta ha scritto:

I was suspecting the same Major Function… Though you forgot to add
IRP_SYNCHRONOUS_PAGING_IO flag in your check

Long time back we also had a problem with IRP_MJ_SET_INFORMATION in our
driver. The case was somewhat different though.
We had also set the FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO flag.
http://www.osronline.com/showThread.cfm?link=103831

Has it got to do something with the *less known* paging
IRP_MJ_SET_INFORMATION (just a wild guess…) ?

Regards,
Ayush Gupta

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

NTFSD is sponsored by OSR

For our schedule debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars

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

13

Hello,

I have tried what you suggested and the debug statement was never
printed. It really looks like the Filter Manager behaves correctly, as
paging I/O requests won’t get sent to my PreOperationCallback.

So, the problem with IRP_MJ_SET_INFORMATION -> FilePositionInformation
must be caused by something else.

  • AS

Ayush Gupta ha scritto:

Hi Alessandro,

Actually you could test one more thing.

Set the FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO flag in the
FLT_OPERATION_REGISTRATION structure.

And then check in your precallback by putting a simple statement,

If(Data->Iopb->IrpFlags == IRP_PAGING_IO &&

Data->Iopb->IrpFlags == IRP_SYNCHRONOUS_PAGING_)

{

ASSERT(FALSE); // compile as checked/ debug build

DbgPrint(“Funny”);

}

Then we can know by surety that even after requesting the Filter
Manager NOT to send Paging I/O requests, we are getting them in the
pre-callback of SetInfo.

And maybe the reason for the deadlock is same. Filter Manager does not
treat Paging IRP_MJ_SET_INFORMATION as Paging I/O and attempts to
query the name.

But in reality it is a paging I/O and hence the deadlock.

14

Very strange. From what I remember,
NtSetInformationFile/FilePositionInformation is not delivered to drivers at
all, it just updates FileObject->CurrentByteOffset after the alignment check.

–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

“Alessandro Sardo” wrote in message
news:xxxxx@ntfsd…
> Hello,
>
> upon further investigation I found out that the freeze happens only with
> IRP_MJ_SET_INFORMATION -> FilePositionInformation operations. In fact,
> with the following code everything worked fine:
>
> FLT_PREOP_CALLBACK_STATUS PreFileOperationCallback( inout
> PFLT_CALLBACK_DATA Data,
> in
> PCFLT_RELATED_OBJECTS FltObjects,
> __deref_out_opt
> PVOID *CompletionContext )
> {
> PFLT_FILE_NAME_INFORMATION nameInfo = NULL;
> NTSTATUS status;
>
> *CompletionContext = NULL;
>
> if ( KeGetCurrentIrql() <= APC_LEVEL &&
> IoGetTopLevelIrp() == NULL &&
> Data->Iopb->IrpFlags != IRP_PAGING_IO &&
> Data->Iopb->IrpFlags != IRP_SYNCHRONOUS_PAGING_IO )
> {
> if ( Data->Iopb->MajorFunction == IRP_MJ_SET_INFORMATION &&
>
> Data->Iopb->Parameters.SetFileInformation.FileInformationClass ==
> FilePositionInformation )
> {
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
> }
>
> if ( FltObjects->FileObject != NULL )
> status = FltGetFileNameInformation( Data,
> FLT_FILE_NAME_NORMALIZED | DEFAULT_NAME_QUERY_METHOD, &nameInfo );
> if ( nameInfo != NULL )
> FltReleaseFileNameInformation( nameInfo );
> }
>
> return FLT_PREOP_SUCCESS_NO_CALLBACK;
> }
>
> So, I finally have some work-around to avoid the hard lock-up.
>
> Thank you all for your help,
>
> - AS
>
>
> Ayush Gupta ha scritto:
> > I was suspecting the same Major Function… Though you forgot to add
> > IRP_SYNCHRONOUS_PAGING_IO flag in your check
> >
> > Long time back we also had a problem with IRP_MJ_SET_INFORMATION in our
> > driver. The case was somewhat different though.
> > We had also set the FLTFL_OPERATION_REGISTRATION_SKIP_PAGING_IO flag.
> > http://www.osronline.com/showThread.cfm?link=103831
> >
> > Has it got to do something with the less known paging
> > IRP_MJ_SET_INFORMATION (just a wild guess…) ?
> >
> > Regards,
> > Ayush Gupta
> >
> >
> >
> > —
> > NTFSD is sponsored by OSR
> >
> > For our schedule debugging and file system seminars
> > (including our new fs mini-filter seminar) visit:
> > http://www.osr.com/seminars
> >
> > You are currently subscribed to ntfsd as: xxxxx@polito.it
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
>