vista sp1 RDR bug(rdbss!RxIterateOnFcbOpens)?Microsoft please explain it.

NTFSD
1

vista sp1 RDR bug(rdbss!RxIterateOnFcbOpens)?Microsoft please explain it.

I developped a very simple minifilter for test!It is base on the sample:swapbuffers.
In PostCreate on RDR,I just call FltCreateFile to open the original file.And then I call FltClose

to close it.

It's very simple!It works well in win2K,winxp,win2K3,and vista sp0.
But in vista SP1,it works very slowly calling FltClose!

When calling FltClose in my minifilter PostCreate,I break the WinDbg and trace the stacks:

nt!KiSwapContext+0x26
nt!KiSwapThread+0x44f
nt!KeDelayExecutionThread+0x472
rdbss!RxCommonCleanup+0x680
rdbss!RxFsdCommonDispatch+0x59c
rdbss!RxFsdDispatch+0x19f
mrxsmb!MRxSmbFsdDispatch+0x99
nt!IofCallDriver+0x63
mup!MupiCallUncProvider+0x10d
mup!MupStateMachine+0x9b
mup!MupCleanup+0x91
nt!IofCallDriver+0x63
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x251
fltmgr!FltpDispatch+0xc2
nt!IofCallDriver+0x63
nt!IopCloseFile+0x387
nt!ObpDecrementHandleCount+0x146
nt!ObpCloseHandleTableEntry+0x234
nt!ObpCloseHandle+0x73
nt!NtClose+0x20
nt!KiFastCallEntry+0x12a
nt!ZwClose+0x11

SwapBuffers!SwapPostCreate+0xc6 [d:\work2\2008.5.1\swapbuffers\swapbuffers.c @ 1107]

fltmgr!FltpPerformPostCallbacks+0x1f1
fltmgr!FltpProcessIoCompletion+0x10
fltmgr!FltpPassThroughCompletion+0x94
fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2e1
nt!IofCallDriver+0x63
nt!IopParseDevice+0xf61
nt!ObpLookupObjectName+0x5a8
nt!ObOpenObjectByName+0x13c
nt!IopCreateFile+0x63b
nt!NtCreateFile+0x34
nt!KiFastCallEntry+0x12a
ntdll!KiFastSystemCallRet

I analyzed the disassemble code in rdbss!RxCommonCleanup.
In this case(my Minifilter call FltClose very slowly),
rdbss!RxCommonCleanup will call rdbss!RxIterateOnFcbOpens.
After rdbss!RxIterateOnFcbOpens returned,it will test some condition,
result to call KeDelayExecutionThread(-280ms).
After the KeDelayExecutionThread(-280ms) expired,it will inc the loop counter,and do it again.
the loop counter's limit is 0x1e.
When the loop counter reached 0x1e,it will exit the case.

So,in my simple minifilter,calling FltClose will comsume 8 seconds.

In other case(the app call CreateFile and CloseHandle for a RDR file),
rdbss!RxCommonCleanup will not trap in the loop(will not call rdbss!RxIterateOnFcbOpens).

oh,anybody can explain it?What is it waiting for?Maybe we need MicroSoft team,haha.

Why I need call FltCreate and FltClose in PostCreate on RDR?
When I am interesting in the opened RDR file in PostCreate,I need issued a Oplock Break to it.
So,I call FltCreate to open the file,and issued my IRP to take a byte range lock,and call

FltClose.
Is there any idea for taking Oplock Break to the opened RDR file?

2

Clark,

This is a known issue in the RDR for Vista SP1 and Windows Server 2008. You should see a time-out of about 5 seconds if you hit this condition. The current work-around for this is for you to not issue your create in the post-create callback but to delay it until after the create completes to IO manager and a handle is created for the file. Alternatively, you can issue your create in the pre-op callback for the first IO to the file object.

This issue is fixed in Windows 7.

I am wondering why you need to issue your own create in post-create?

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

3

yes!the time-out is about 5 seconds!
I have described it:

Why I need call FltCreate and FltClose in PostCreate on RDR?
When I am interesting in the opened RDR file in PostCreate,I need issued a
Oplock Break to it.
So,I call FltCreate to open the file,and issued my IRP to take a byte range
lock,and call FltClose.
Is there any idea for taking Oplock Break to the opened RDR file?

4

Why do you need to cause the oplock break? Can you do it asynchronously to the create? Can you do it at the next IO?

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

5

OK.I can do it in the next IO.This is a work-aroud for me.
I need to cause the oplock break for the cache is invalid,because my minifilter is a encrypted minifilter.
I can’t resolve encrypte/decrypte the file data for RDR,because the cache is not only according to the IRP flags.

6

oh,there is a question I want to know.
If in the PostCreate callback,the original FO is a fake fo(in the stack),I call FltCreate and FltClose is OK(the time-out will not happen)?

7

I finded a interesting phenomena.
When the file has been opened(a Application has opened the file,but not call CloseHandle to close it),a App call CreateFile to open the file,my minifilter do the same work(in PostCreate callback,I call FltCreateFile and FltClose) will be fast(no time-out 5 seconds).
can you explain it?
I guess If there are Created Handles for the File (FCB),the time-out will not happen.

8

Sarosh,can you confirm my two question?
1.
If in the PostCreate callback,the original FO is a fake fo(in the stack),I call
FltCreate and FltClose is OK(the time-out will not happen)?
2.
I finded a interesting phenomena.
When the file has been opened(a Application has opened the file,but not call
CloseHandle to close it),a App call CreateFile to open the file,my minifilter do
the same work(in PostCreate callback,I call FltCreateFile and FltClose) will be
fast(no time-out 5 seconds).
can you explain it?

9

  1. You should not see any stack based file object in Vista and beyond. If you do see them do let me know. If you do find them, I do not believe that the situation will be any different.

  2. As you correctly observed, presence of the outstanding handle affects the situation.

Regards,
Sarosh.
File System Filter Lead
Microsoft Corp

This posting is provided “AS IS” with no warranties, and confers no Rights

10

OK,thank you~~~
1.I don’t see any stack based fo in vista.
I just want to modify my solution for all windows version.
If fake fo is same with other fo,I can’t resolve my problem.So,I will just modify my solution for vista.