FltQueryInformationFile call in PreSetInformation callback

Hello,

I got BSOD on Win10 32bit on UDF FS with my driver in the call stack:

udfs!UdfFillStandardInfo
udfs!UdfCommonQueryInfo
udfs!UdfFsdDispatch
nt!IofCallDriver
FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted
FLTMGR!FltPerformSynchronousIo
FLTMGR!FltQueryInformationFile
MyDriver!PreSetInformation
FLTMGR!FltpPerformPreCallbacks
FLTMGR!FltpPassThroughInternal
FLTMGR!FltpPassThrough
FLTMGR!FltpDispatch
nt!IofCallDriver
nt!CcSetValidData
nt!CcWriteBehindInternal
nt!ExpWorkerThread
nt!PspSystemThreadStartup
nt!KiThreadStartup

I provided correct instance and FileObject to FltQueryInformationFile. UdfCommonQueryInfo calls UdfDecodeFileObject which returns CCB from FileObject’s FsContext2. It seems correct. At offset 0xC there should be LCB pointer. And it points to invalid (free) memory. Therefore the crash in UdfFillStandardInfo. There is no such BSOD with my driver on other OSes like Win7, Win8, Win8.1. What’s more, it is quite random, it doesn’t happen always, but very often.

So my question is, is it allowed to call FltQueryInformationFile in PreSetInformation callback?

Hi,
I got the same issue from the IFS Plugfest.
Apparently you cannot do that if t that file is deleted or at least for me it was the issue where I queried data in Cleanup routine and crashed in the same way. Aparently UDF frees that memory in this scenario and I don’t think Microsoft will fix it. I heard that what I should do is not call QueryInformation :slight_smile:

Try to see if the file has the disposition set to TRUE and avoid doing this for UDF.
BTW: This works for all other file systems, but UDF :slight_smile: ( at least for what we do )

Gabriel

But in my case it is call stack for FileInformationClass == FileEndOfFileInformation (I forgot to mention in original post) and not for FileDispositionInformation (it is deferred write of some system cache). If I want to get disposition information, I need again to call FltQueryInformationFile and I can’t.

True but you can track down deletes ( look up the delete sample ) and keep
track of it in you stream context for example.
Then you can know that that file is deleted and avoid the BOOM :slight_smile:

On Wed, Apr 15, 2015 at 12:32 PM, wrote:

> But in my case it is call stack for FileInformationClass ==
> FileEndOfFileInformation (I forgot to mention in original post) and not for
> FileDispositionInformation (it is deferred write of some system cache). If
> I want to get disposition information, I need again to call
> FltQueryInformationFile and I can’t.
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Bercea. G.

I am tracking FileDispositionInformation/DeleteFile in stream Ctx and there is no delete pending. Also FileObject structure says:
+0x025 DeletePending : 0 ‘’

By the way in my case stream is alternate data stream: “\estream\wrnotiff.dat:stream1”

Was the file opened FILE_DELETE_ON_CLOSE? If so, you won’t see the disposition in the file until the IRP_MJ_CLEANUP promotes the pending delete into the FCB/SCB.

Doesn’t matter, the behavior is the same.

Tony
OSR

Yeah, check the Delete sample from MS.
There are quite a lot of ways you can do a delete in windows, and the ways of the delete are not as straight forward and easy as first thought, pbably a reason MS decided to create this sample ( that is transaction aware BTW ).
It only attaches to NTFS and ReFs and that is why is doest not BSOD on Cleanup ( where it calls QueryInformationFile), but if you attach the same sample to UDF it will most certainly BSOD.

My approach to avoid this is to keep yourself a track of the file opens for a certain stream and for the FSs that are not NTFS and ReFs when the PostCleanup arrives and you have your last handle closed for that stream ( if this makes sense), then mark the file as deleted in your StreamContext without having to call QueryInformation or for that matter, not only in Cleanup, since apparently for you it might occur in other callbacks as well.

Gabriel

My scenario is:

  1. process ifstest.exe creates file K:\estream\wrnotiff.dat
  2. process ifstest.exe creates stream K:\estream\wrnotiff.dat:stream1, writes 100 B and closes handle.
  3. process ifstest.exe deletes (Type: SetDispositionInformationFile, Delete: True) file K:\estream\wrnotiff.dat
  4. Several seconds later OS flushes some caches (it is consequence of write in point 2) and performs SetEndOfFileInformationFile to set EOF 100 B for stream K:\estream\wrnotiff.dat:stream1 in the system process context.

Point 4) is the place where my driver does FltQueryInformationFile what causes BSOD on UDFS. If I do track file delete in stream Ctx (in point 3), it is not usefull, since in point 4 there is different stream Ctx, so no info about delete. Maybe file Ctx would be helpfull, but I don’t want to use it only due to this udfs bug (I think it is a bug). Much simplier solution for me is not to call FltQueryInformationFile inside PreSetInformation callback if process context is system one.

Hmmm, well then it does not sound good if you ask me.
I am sure the BSOD will occur even if called from PostSetInfo.

This, as I said when I was at Plugfest, looks like a bug somewhere in UDF.
It should not be “illegal” to call QueryInfo from PreSetInfo, but I would
like to hear the opinion of someone from Microsoft about this.

Gabriel.

On Fri, Apr 17, 2015 at 9:58 AM, wrote:

> My scenario is:
> 1) process ifstest.exe creates file K:\estream\wrnotiff.dat
> 2) process ifstest.exe creates stream K:\estream\wrnotiff.dat:stream1,
> writes 100 B and closes handle.
> 3) process ifstest.exe deletes (Type: SetDispositionInformationFile,
> Delete: True) file K:\estream\wrnotiff.dat
> 4) Several seconds later OS flushes some caches (it is consequence of
> write in point 2) and performs SetEndOfFileInformationFile to set EOF 100 B
> for stream K:\estream\wrnotiff.dat:stream1 in the system process context.
>
> Point 4) is the place where my driver does FltQueryInformationFile what
> causes BSOD on UDFS. If I do track file delete in stream Ctx (in point 3),
> it is not usefull, since in point 4 there is different stream Ctx, so no
> info about delete. Maybe file Ctx would be helpfull, but I don’t want to
> use it only due to this udfs bug (I think it is a bug). Much simplier
> solution for me is not to call FltQueryInformationFile inside
> PreSetInformation callback if process context is system one.
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>


Bercea. G.

I ran the Win 10 IFS tests on Win8.1 x86 more times and I didn’t observe any crash in UDFS. So it seems to be really issue only of Win10 UDFS.