FltCreateFileEx() not in WXP FltMgr.lib ?

NTFSD
1

I was using FltCreateFileEx() to gain fourth parameter PFILE_OBJECT to be
used in FltQueryInformationFile(), this works fine on Vista above except XP.

ntStatus = FltCreateFileEx(FltObjects->Filter,
Data->Iopb->TargetInstance,
&h,
&pfo,
FILE_READ_ATTRIBUTES,
&oa,
&iob,
0,
FILE_ATTRIBUTE_NORMAL,
0,
FILE_OPEN,
FILE_DIRECTORY_FILE|FILE_COMPLETE_IF_OPLOCKED,
0,
0,
IO_IGNORE_SHARE_ACCESS_CHECK);

The purpose is to check if it is a directory:

ntStatus2 = FltQueryInformationFile(Data->Iopb->TargetInstance,
pfo,
(void*)&fsi,
sizeof(FILE_STANDARD_INFORMATION),
FileStandardInformation,
&ul);

—> fsi.Directory

However, at C:\WinDDK\7600.16385.1\lib\wxp\i386, FltMgr.lib seems don’t have FltCreateFileEx() when tested via DUMPBIN.

Please advise.

2

Try dynamically loading it. The function is not available on all versions of XP - the docs clearly say XP SP3.

Tony
OSR

3

Tony,

“The function is not available on all versions of XP…”

4

btw, is there any reference of how to dynamically loading a function, is it the same method
used via MmGetSystemRoutineAddress() something like below ?

typedef NTSTATUS (*QUERY_INFO_PROCESS) (
__in HANDLE ProcessHandle,
__in PROCESSINFOCLASS ProcessInformationClass,
__out_bcount(ProcessInformationLength) PVOID ProcessInformation,
__in ULONG ProcessInformationLength,
__out_opt PULONG ReturnLength
);

QUERY_INFO_PROCESS ZwQueryInformationProcess;

.
.
.
NTSTATUS GetProcessImageName ()
{
UNICODE_STRING routineName;

RtlInitUnicodeString(&routineName, L"ZwQueryInformationProcess");

ZwQueryInformationProcess =
(QUERY_INFO_PROCESS)MmGetSystemRoutineAddress(&routineName );
}

Please advise.

5

MmGetSystemRoutineAddress works only for ntos+hal library.
See FltGetRoutineAddress in MSDN (see WDK samples).
If you need find an exported function from other libraries (ndis.sys,
netio.sys, fwpkclnt.sys, …) you need to write your own implementation.

6

>If you need find an exported function from other libraries (ndis.sys,
netio.sys, fwpkclnt.sys, …) you need to write your own implementation.

Take a look the AuxKlib stuff for that.

mm

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Petr Kurtin
Sent: Monday, June 17, 2013 2:05 AM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] FltCreateFileEx() not in WXP FltMgr.lib ?

MmGetSystemRoutineAddress works only for ntos+hal library.
See FltGetRoutineAddress in MSDN (see WDK samples).
If you need find an exported function from other libraries (ndis.sys,
netio.sys, fwpkclnt.sys, …) you need to write your own implementation.

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

7

I have tried to compile at NTDDI_VERSION=0x05010300 and 0x05010400 under XP x86 compiler options and found out the FltGetRoutineAddress( “FltCreateFileEx” ) returned SUCCESS at DriverEntry:
.
.
.
#if( NTDDI_VERSION <= NTDDI_WINXPSP4 )
g_ScannerData.FltCreateFileEx = (PFltCreateFileEx)FltGetRoutineAddress( “FltCreateFileEx” );
#endif // ( NTDDI_VERSION <= NTDDI_WINXPSP4 )
.
.
.
Its returned pointer is saved under g_ScannerData.FltCreateFileEx for later use in PreCreate() later such as:
.
.
.
if( g_ScannerData.FltCreateFileEx )
{
ntStatus = (*g_ScannerData.FltCreateFileEx)(FltObjects->Filter,
Data->Iopb->TargetInstance,
&h,
&pfo,
FILE_READ_ATTRIBUTES,
&oa,
&iob,
0,
FILE_ATTRIBUTE_NORMAL,
0,
FILE_OPEN,
FILE_DIRECTORY_FILE|FILE_COMPLETE_IF_OPLOCKED,
0,
0,
IO_IGNORE_SHARE_ACCESS_CHECK);
if( !NT_SUCCESS( ntStatus ) )
{
DbgPrint( “K> [PreCreate]…%ls”, L"ERROR" );
}
else
DbgPrint( “K> [PreCreate]…%ls”, L"OK" );
}
.
.
.
However, ntStatus above always returned ERROR.

Btw, I have referred to the WDK minispy source, above is the same method used according to
the WDK minispy.

Is there any reference URLs or references,

Please advise.

8

…after some testing, I noticed is my fault that g_ScannerData.FltCreateFileEx() returned success only if the g_ScannerData.FltCreateFileEx() opening a directory, ERROR if it is a file.

I am not sure if this assumption is correct, but from the traced debug information, seems correct.

Please advise, if there is other reasons or suggestions.