Hello.
I met the problem of linking error with functions FltOplockFsctrlEx and FltOplockKeysEqual with WINDDK 7600.16385.1 “unresolved external symbol”. FltOplockKeysEqual can be substituted with FsRtlOplockKeysEqual, because this function uses file objects only and no any of filter manager dependent argument.
FltOplockFsctrlEx uses PFLT_CALLBACK_DATA CallbackData, so such trick is impossible. I searched for FltOplockFsctrlEx in my *.lib files inside of WINDDK\7600.16385.1\lib\win7 ? but did not found.
Moreover FltGetRoutineAddress returns NULL both for FltOplockFsctrlEx and FltOplockKeysEqual on Windows 7.
From the other side, debugging with symbols on Win7 shows that FltOplockFsctrl does just call of FltOplockFsctrlEx with 0 as last ULONG Flags parameter, so this function present there:
fltmgr!FltOplockFsctrl:
86e7bec4 8bff mov edi,edi
86e7bec6 55 push ebp
86e7bec7 8bec mov ebp,esp
86e7bec9 6a00 push 0
86e7becb ff7510 push dword ptr [ebp+10h]
86e7bece ff750c push dword ptr [ebp+0Ch]
86e7bed1 ff7508 push dword ptr [ebp+8]
86e7bed4 e83dffffff call fltmgr!FltOplockFsctrlEx (86e7be16)
86e7bed9 5d pop ebp
86e7beda c20c00 ret 0Ch
On Windows 8 all is good: this functions are present in WDK libs and FltGetRoutineAddress returns them.
Is there way to get FltOplockFsctrlEx function pointer on Windows 7.
Best regards,
Alexey Barabash
The only idea now is to search memory starting from FltOplockFsctrl for the codes of asm commands push and then do jmp to call fltmgr!FltOplockFsctrlEx - but this seems too dirty.
Best regards,
Alexey Barabash
Here is result of my investigation for x86.
Instruction format: http://download.intel.com/design/intarch/manuals/24319101.pdf
E8 cd CALL rel32 Call near, relative, displacement relative to next instruction
Address of the next instruction pop ebp is 0x86e7bed9, offset is 0xffffff3d.
0x86e7bed9+0xffffff3d=0x86E7BE16 == FltOplockFsctrlEx.
Need to find similar way for amd64, as there are no better suggestions.
Best regards,
Alexey Barabash
This sounds like a defect in the Windows 7 kit. Trying to find the entry point via searching for code patterns is not a reliable method of accomplishing this. Better to implement your own versions of these functions on top of the FsRtl routines, since I cannot imagine they are going to fix this issue in the Windows 7 WDK.
If you build the driver for Windows 7 in the Windows 8 WDK do you still get unresolved symbol problems with these routines?
Tony
OSR
Well, the problem with implementing your own routines is that in order to call the FsRtl function you need to find the IRP associated with the FLT_CALLBACK_DATA structure, which is not documented anywhere.
Unfortunately, I can’t think of any nice solution for Alexey’s problem. Anything I can come up with requires something undocumented :(.
Thanks,
Alex.
Does he really need the original IRP or can one be simulated that is sufficient for his purposes? If he has to have the original IRP then it becomes a question of least obnoxious work-around.
I’m still curious if these exports are missing from the LIBRARY or from the BINARY. If it’s the former, then it may be possible to cobble together a library with the necessary linkage information. If the latter, it’s a lot more work to fix.
Tony
OSR
Hello.
First, thanks for the replies.
-
I cannot build the minifilter driver which uses FltOplockFsctrlEx with WDK 8 for Win 7 configuration because of the same ?unresolved external symbol _FltOplockFsctrlEx@16?.
-
If I am trying to launch driver built for Win8 on Win7 with FltOplockFsctrlEx, I have
C:\Test\FTS\Package>sc start passThrough
[SC] StartService FAILED 127:
The specified procedure could not be found.
Thus, depends tool reports that all Flt*** routines are missing:
FltGetIrpName
FltInitializeOplock
FltOplockFsctrlEx
FltRegisterFilter
FltRequestOperationStatusCallback
FltStartFiltering
FltUninitializeOplock
FltUnregisterFilter
- Yes, search by code pattern is very unreliable and danger.
On amd64 searching of FltOplockFsctrlEx is hard because of another calling convention, sequence push command is not used.
How it looks like on Win7 x64 Free:
fltmgr!FltOplockFsctrl:
fffff88000b006c0 4533c9 xor r9d,r9d fffff88000b006c3 e9f0feffff jmp fltmgr!FltOplockFsctrlEx (fffff880`00b005b8)
Win7 x64 Checked:
FltOplockFsctrl
mov [rsp+arg_10], r8d
mov [rsp+arg_8], rdx
mov [rsp+arg_0], rcx
sub rsp, 28h
mov rax, cr8
cmp al, 1
jbe short loc_5F9D4
mov rax, cr8
lea rcx, Format ; “EX: Pageable code called at IRQL %d\n”
movzx edx, al
call DbgPrint_0
int 2Ch ; Windows NT - assertion failure
loc_5F9D4:
mov r8d, [rsp+28h+arg_10]
mov rdx, [rsp+28h+arg_8]
mov rcx, [rsp+28h+arg_0]
xor r9d, r9d
add rsp, 28h
jmp FltOplockFsctrlEx
Code inside of FltOplockFsctrl can be changed during windows update and pattern search can give wrong result.
If I?ll make mistake even for 1 byte in address, certainly I will have BSOD.
Today the only purpose of FltOplockFsctrlEx in Win7 is a flag OPLOCK_FSCTRL_FLAG_ALL_KEYS_MATCH which allows ?to grant level RW or RWH when more than one open handle to the file exists? with the same oplock key. FltOplockKeysEqual should be used to compare oplock keys of all opened handles, because oplock subsystem doesn?t know what files are opened. That’s the relationship between these functions. By the way, fastfat both in Win7 and Win8 does not use FsRtlOplockFsctrlEx (…OPLOCK_FSCTRL_FLAG_ALL_KEYS_MATCH) ? it cannot grant RW/RWH in specified case.
Best regards,
Alexey Barabash
So the one remaining question then is whether or not these routines are exported by filter manager and the definitions are just missing from the LIB file.
I’m curious about why usual MS filter folks on the list have been so very quiet. We know they aren’t allowed to go on vacation…
Tony
OSR
100% these routines are not exported by filter manager, because:
- I can’t find it in export with depends tool on Win7.
- FltGetRoutineAddress, which searches the filter manager’s export table for the requested routine name returns NULL.
Best regards,
Alexey Barabash
I actually blogged about this function only being exported in Win8 here: http://fsfilters.blogspot.com/2011/09/whats-new-in-win8-for-file-system.html.
Well, I suspect that vacation for MS filter folks is to work on other components for a while :).
Thanks,
Alex.
I couldn’t find these exports in D:\WinDDK\7600.16385.1\lib\win7\amd64\fltMgr.lib or D:\WinDDK\7600.16385.1\lib\win7\i386\fltMgr.lib, even though the Win 7 WDK docs say they should be there, and the declarations are present in D:\WinDDK\7600.16385.1\inc\ddk\fltKernel.h under #if FLT_MGR_WIN7. Seems a failure to complete the export, or else it was an export that was removed at the last minute and neither the header nor the docs were updated appropriately.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, September 07, 2012 9:09 AM
To: Windows File Systems Devs Interest List
Subject: RE:[ntfsd] Windows 7, FltOplockFsctrlEx and FltOplockKeysEqual missing exports
I actually blogged about this function only being exported in Win8 here: http://fsfilters.blogspot.com/2011/09/whats-new-in-win8-for-file-system.html.
Well, I suspect that vacation for MS filter folks is to work on other components for a while :).
Thanks,
Alex.
NTFSD is sponsored by OSR
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
The export table for fltmgr.sys inadvertently omitted FltOplockFsctrlEx and FltOplockKeysEqual in Windows 7.
By the way, fastfat both in Win7 and Win8 does not use
FsRtlOplockFsctrlEx( OPLOCK_FSCTRL_FLAG_ALL_KEYS_MATCH ) ? it cannot grant RW/
RWH in specified case.
Correct. Only NTFS does this. The reason FAT/exFAT do not is that they don't have the structures necessary to find all the open handles to a particular file. That is, given a FAT FCB you can't find the FILE_OBJECTs pointing to that FCB. Since the oplock key is stored in the FILE_OBJECT extension, that makes it impossible to support the ALL_KEYS_MATCH functionality without adding a bunch of extra glue to FAT/exFAT just for that one feature.
And I just got back from two weeks off, so yeah, even we go on vacation from time to time. 
Christian [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
Thanks for the clarification, Christian.
By the way, I received notification from documentation team that the help
topic will be updated to state that the routine is available starting with
Windows 8.
Best regards,
Alexey Barabash