CcFlushCache under SRV2

As before I have a full FSD and not a filter driver. I am running mmap tests which succeed when run against the file system directly, but fail when run through SRV2. I have traced this failure to CcFlushCache, which does not seem to flush anything.

The specific test scenario, is as follows:

H = CreateFileW(“file0”, CREATE_ALWAYS, FILE_FLAG_NO_BUFFERING);
// notice the FILE_FLAG_NO_BUFFERING, it work without it! --+
M = CreateFileMappingW(H);
P = MapViewOfFile(M);
// fill buffer at P with random data
UnmapViewOfFile(P);
P = MapViewOfFile(M);
// test that buffer contains the expected random data
UnmapViewOfFile(M);
CloseHandle(M);
CloseHandle(H);

H = CreateFileW(“file0”, OPEN_EXISTING, FILE_FLAG_NO_BUFFERING);
// notice the FILE_FLAG_NO_BUFFERING, it work without it! --+
M = CreateFileMappingW(H);
P = MapViewOfFile(M);
// test that buffer contains the expected random data <– FAILURE HERE UNDER SRV2!
UnmapViewOfFile(M);
CloseHandle(M);
CloseHandle(H);

I run this test under the debugger (1) directly against the file system and (2) through SRV2. In case (1) I see IRP_MJ_WRITE IRP’s and the test works correctly. In case (2) I never see IRP_MJ_WRITE IRP’s and the test fails.

I have added CcFlushCache in a couple of places trying to resolve this issue. I find that in case (1) the CcFlushCache will always generate IRP_MJ_WRITE IRP’s and that in case (2) it never will. I have traced into CcFlushCache and have seen it call my AcquireForCcFlush and ReleaseForCcFlush. I have also seen it enter the internal Mm routine MiFlushSectionInternal, but this does *not* result in any WRITE IRP’s sent to my FSD. It is as if MiFlushSectionInternal determines that there is nothing to flush!

[Needless to say the test passes on NTFS (via SRV2). So my FSD is at fault.]

The Cc and Mm are a big black box for me and it is unclear how to troubleshoot this further. Your wisdom always appreciated.

Bill

I have enabled full logging on my FSD and run the test for cases (1) and (2).

Here is the log when running CcFlushCache during IRP_MJ_CLEANUP in case (1) (test run directly against the file system). Commentary inline:
<<
[0] WinFsp!FspAcquireForCcFlush(FileObject=FFFFFA8004544E50) = STATUS_SUCCESS
– This is the FastIo AcquireForCcFlush handler.

[0] WinFsp!FspWrite(FFFFF9800660CEA0, VolK, IRP_MJ_WRITE[IRP_MN_NORMAL], FileObject=FFFFFA8004544E50, UserBuffer=0000000000000000, MdlAddress=FFFFFA8002AA9EC0, Key=0, ByteOffset=0:0, Length=131172) = FSP_STATUS_IOQ_POST[0]
– This is the IRP_MJ_WRITE IRP. The status code FSP_STATUS_IOQ_POST is specific to my FSD; it instructs the FSD to post the IRP to an internal queue and return STATUS_PENDING.

[0] WinFsp!FspFileSystemControl(FFFFF98006636EA0, CtlU, IRP_MJ_FILE_SYSTEM_CONTROL[IRP_MN_USER_FS_REQUEST], FSP_FSCTL_TRANSACT, FileObject=FFFFFA8004733C00) = STATUS_SUCCESS[80]
– This is the user mode file system reaching into the FSD and getting the WRITE request to service it.

[0] WinFsp!FspFsvolWriteComplete(FFFFF9800660CEA0, VolK, IRP_MJ_WRITE[IRP_MN_NORMAL], FileObject=FFFFFA8004544E50, UserBuffer=0000000000000000, MdlAddress=FFFFFA8002AA9EC0, Key=0, ByteOffset=0:0, Length=131172) = STATUS_SUCCESS[131172]
– This is the completion phase of the IRP_MJ_WRITE IRP. It occurs after the user mode file system has serviced the WRITE request.

[0] WinFsp!FspReleaseForCcFlush(FileObject=FFFFFA8004544E50) = STATUS_SUCCESS
– This is the FastIo ReleaseForCcFlush handler.

>

Here is the log when running CcFlushCache during IRP_MJ_CLEANUP in case (2) (test run through SRV2). Commentary inline:
<<
[0] WinFsp!FspAcquireForCcFlush(FileObject=FFFFFA800344ECF0) = STATUS_SUCCESS
– This is the FastIo AcquireForCcFlush handler.

– WHERE IS THE IRP_MJ_WRITE?

[0] WinFsp!FspReleaseForCcFlush(FileObject=FFFFFA800344ECF0) = STATUS_SUCCESS
– This is the FastIo ReleaseForCcFlush handler.

>

Thanks again.

You can’t see IRP_MJ_WRITE only if there are no modified pages. Did i
understand right the fact if you reset FILE_FLAG_NO_BUFFERING flag for test
2 then the test would work well?

About test 1. If you wouldn’t see IRP_MJ_WRITE the test will succeeded any
way. The matter is buffer you’re filling is
stored in memory pages that memory manager allocated. When you map the file
second time, memory manager maps previously allocated memory pages, which
was filled by test at first
mapping. That’s why test would work whether you saw IRP_MJ_WRITE request or
not.

As far as test 2, do you run it after test 1 ran successfully?

Did you implement oplocks?

2016-10-30 2:39 GMT+03:00 :

> I have enabled full logging on my FSD and run the test for cases (1) and
> (2).
>
> Here is the log when running CcFlushCache during IRP_MJ_CLEANUP in case
> (1) (test run directly against the file system). Commentary inline:
> <<
> [0] WinFsp!FspAcquireForCcFlush(FileObject=FFFFFA8004544E50) =
> STATUS_SUCCESS
> – This is the FastIo AcquireForCcFlush handler.
>
> [0] WinFsp!FspWrite(FFFFF9800660CEA0, VolK, IRP_MJ_WRITE[IRP_MN_NORMAL],
> FileObject=FFFFFA8004544E50, UserBuffer=0000000000000000,
> MdlAddress=FFFFFA8002AA9EC0, Key=0, ByteOffset=0:0, Length=131172) =
> FSP_STATUS_IOQ_POST[0]
> – This is the IRP_MJ_WRITE IRP. The status code FSP_STATUS_IOQ_POST
> is specific to my FSD; it instructs the FSD to post the IRP to an internal
> queue and return STATUS_PENDING.
>
> [0] WinFsp!FspFileSystemControl(FFFFF98006636EA0, CtlU,
> IRP_MJ_FILE_SYSTEM_CONTROL[IRP_MN_USER_FS_REQUEST], FSP_FSCTL_TRANSACT,
> FileObject=FFFFFA8004733C00) = STATUS_SUCCESS[80]
> – This is the user mode file system reaching into the FSD and getting
> the WRITE request to service it.
>
> [0] WinFsp!FspFsvolWriteComplete(FFFFF9800660CEA0, VolK,
> IRP_MJ_WRITE[IRP_MN_NORMAL], FileObject=FFFFFA8004544E50,
> UserBuffer=0000000000000000, MdlAddress=FFFFFA8002AA9EC0, Key=0,
> ByteOffset=0:0, Length=131172) = STATUS_SUCCESS[131172]
> – This is the completion phase of the IRP_MJ_WRITE IRP. It occurs
> after the user mode file system has serviced the WRITE request.
>
> [0] WinFsp!FspReleaseForCcFlush(FileObject=FFFFFA8004544E50) =
> STATUS_SUCCESS
> – This is the FastIo ReleaseForCcFlush handler.
> >>
>
> Here is the log when running CcFlushCache during IRP_MJ_CLEANUP in case
> (2) (test run through SRV2). Commentary inline:
> <<
> [0] WinFsp!FspAcquireForCcFlush(FileObject=FFFFFA800344ECF0) =
> STATUS_SUCCESS
> – This is the FastIo AcquireForCcFlush handler.
>
> – WHERE IS THE IRP_MJ_WRITE?
>
> [0] WinFsp!FspReleaseForCcFlush(FileObject=FFFFFA800344ECF0) =
> STATUS_SUCCESS
> – This is the FastIo ReleaseForCcFlush handler.
> >>
>
> Thanks again.
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

By the way, did you see IRP_MJ_READ through SRV2? Memory manager of remote
PC will read data first when test 2 access them. The matter can be test 1
filled buffer, but memory manager didn’t
write it yet. And before this writing your FSD could get IRP_MJ_READ
request through SRV2, and if SRV2 opened file with FILE_FLAG_NO_BUFFERING
flag set then test 2 could get stale data if you don’t flush
cache explicitly before reading on files which was opened with cache
disabled.

2016-10-30 9:43 GMT+03:00 Anatoly Mikhailov :

> You can’t see IRP_MJ_WRITE only if there are no modified pages. Did i
> understand right the fact if you reset FILE_FLAG_NO_BUFFERING flag for test
> 2 then the test would work well?
>
> About test 1. If you wouldn’t see IRP_MJ_WRITE the test will succeeded any
> way. The matter is buffer you’re filling is
> stored in memory pages that memory manager allocated. When you map the
> file second time, memory manager maps previously allocated memory pages,
> which was filled by test at first
> mapping. That’s why test would work whether you saw IRP_MJ_WRITE request
> or not.
>
> As far as test 2, do you run it after test 1 ran successfully?
>
> Did you implement oplocks?
>
> 2016-10-30 2:39 GMT+03:00 :
>
>> I have enabled full logging on my FSD and run the test for cases (1) and
>> (2).
>>
>> Here is the log when running CcFlushCache during IRP_MJ_CLEANUP in case
>> (1) (test run directly against the file system). Commentary inline:
>> <<
>> [0] WinFsp!FspAcquireForCcFlush(FileObject=FFFFFA8004544E50) =
>> STATUS_SUCCESS
>> – This is the FastIo AcquireForCcFlush handler.
>>
>> [0] WinFsp!FspWrite(FFFFF9800660CEA0, VolK, IRP_MJ_WRITE[IRP_MN_NORMAL],
>> FileObject=FFFFFA8004544E50, UserBuffer=0000000000000000,
>> MdlAddress=FFFFFA8002AA9EC0, Key=0, ByteOffset=0:0, Length=131172) =
>> FSP_STATUS_IOQ_POST[0]
>> – This is the IRP_MJ_WRITE IRP. The status code FSP_STATUS_IOQ_POST
>> is specific to my FSD; it instructs the FSD to post the IRP to an internal
>> queue and return STATUS_PENDING.
>>
>> [0] WinFsp!FspFileSystemControl(FFFFF98006636EA0, CtlU,
>> IRP_MJ_FILE_SYSTEM_CONTROL[IRP_MN_USER_FS_REQUEST], FSP_FSCTL_TRANSACT,
>> FileObject=FFFFFA8004733C00) = STATUS_SUCCESS[80]
>> – This is the user mode file system reaching into the FSD and
>> getting the WRITE request to service it.
>>
>> [0] WinFsp!FspFsvolWriteComplete(FFFFF9800660CEA0, VolK,
>> IRP_MJ_WRITE[IRP_MN_NORMAL], FileObject=FFFFFA8004544E50,
>> UserBuffer=0000000000000000, MdlAddress=FFFFFA8002AA9EC0, Key=0,
>> ByteOffset=0:0, Length=131172) = STATUS_SUCCESS[131172]
>> – This is the completion phase of the IRP_MJ_WRITE IRP. It occurs
>> after the user mode file system has serviced the WRITE request.
>>
>> [0] WinFsp!FspReleaseForCcFlush(FileObject=FFFFFA8004544E50) =
>> STATUS_SUCCESS
>> – This is the FastIo ReleaseForCcFlush handler.
>> >>
>>
>> Here is the log when running CcFlushCache during IRP_MJ_CLEANUP in case
>> (2) (test run through SRV2). Commentary inline:
>> <<
>> [0] WinFsp!FspAcquireForCcFlush(FileObject=FFFFFA800344ECF0) =
>> STATUS_SUCCESS
>> – This is the FastIo AcquireForCcFlush handler.
>>
>> – WHERE IS THE IRP_MJ_WRITE?
>>
>> [0] WinFsp!FspReleaseForCcFlush(FileObject=FFFFFA800344ECF0) =
>> STATUS_SUCCESS
>> – This is the FastIo ReleaseForCcFlush handler.
>> >>
>>
>> Thanks again.
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>>
>> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>> software drivers!
>> Details at http:
>>
>> To unsubscribe, visit the List Server section of OSR Online at <
>> http://www.osronline.com/page.cfm?name=ListServer&gt;
>>
>
></http:>

I believe it is normal that there is nothing to flush on cleanup as the server side should translate FILE_FLAG_NO_BUFFERING on a client side to FO_WRITE_THROUGH flag on the server side. So the cache is flushed before cached write completes( i.e. inside CcCopyWrite or CcMdlWriteComplete ). This might explain why there were no dirty pages on cleanup.

I would suggest to verify recursive FSD entry( paging write) from CcCopyWrite or CcMdlWriteComplete.

> I believe it is normal that there is nothing to flush on cleanup as the
server side should translate FILE_FLAG_NO_BUFFERING on a client side to
FO_WRITE_THROUGH flag on the server side. So the cache is flushed before
cached > write completes( i.e. inside CcCopyWrite or CcMdlWriteComplete ).
This might explain why there were no dirty pages on cleanup.

I would suggest to verify recursive FSD entry( paging write) from
CcCopyWrite or CcMdlWriteComplete.

Could be. But still doesn’t explain why test 2 fails.

2016-10-30 20:07 GMT+03:00 :

> I believe it is normal that there is nothing to flush on cleanup as the
> server side should translate FILE_FLAG_NO_BUFFERING on a client side to
> FO_WRITE_THROUGH flag on the server side. So the cache is flushed before
> cached write completes( i.e. inside CcCopyWrite or CcMdlWriteComplete ).
> This might explain why there were no dirty pages on cleanup.
>
> I would suggest to verify recursive FSD entry( paging write) from
> CcCopyWrite or CcMdlWriteComplete.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Anatoly and Slava thanks for your answers:

You can’t see IRP_MJ_WRITE only if there are no modified pages. Did i
understand right the fact if you reset FILE_FLAG_NO_BUFFERING flag for test
2 then the test would work well?

Correct.

As far as test 2, do you run it after test 1 ran successfully?

The tests are run independently. Test 1 always succeeds. Test 2 always fails.

Did you implement oplocks?

Not yet.

By the way, did you see IRP_MJ_READ through SRV2?

Yes, I see READ IRP’s.

Ok, I have now more information. The mystery deepens (for me).

I have since discovered the !ca WinDbg command. Running !ca on the DataSectionObject I get the following.

Case (1). Direct to the file system:
<<
kd> !ca @@(SectionObjectPointer->DataSectionObject)

ControlArea @ fffffa8003d976f0
Segment fffff8a002145620 Flink fffff800c20d3f20 Blink fffffa8004b55408
Section Ref 0 Pfn Ref 21 Mapped Views 0
User Ref 0 WaitForDel 0 Flush Count 0
File Object fffffa80048999e0 ModWriteCount 0 System Views 0
WritableRefs 0
Flags (8000080) File UserWritable

\file0

[snip]

>

Case (2). Via SRV2:
<<
kd> !ca @@(SectionObjectPointer->DataSectionObject)

ControlArea @ fffffa80035cc680
Segment fffff8a002212080 Flink fffff800c20d3f20 Blink fffffa800467c688
Section Ref 0 Pfn Ref 21 Mapped Views 0
User Ref 0 WaitForDel 0 Flush Count 0
File Object fffffa8003599660 ModWriteCount 0 System Views 0
WritableRefs 0
Flags (8008080) File WasPurged UserWritable

winfsp-tests\file0

[snip]

>

Notice that the flags are different! (!!!1!!!1!!! :slight_smile: In the SRV2 case the DataSectionObject has WasPurged set. But why?

Some additional debugging has shown that the DataSectionObject may in fact be created with the WasPurged flag on in case (2). Unfortunately I have to take my son out and cannot investigate this any further at the moment. Will report back later.

Bill

> Yes, I see READ IRP’s.

I would debug this point right after IRP is completed. I would see data
read.

The tests are run independently. Test 1 always succeeds. Test 2 always
fails.

Then i can’t understand why you except random data in view right after file
mapping?

Notice that the flags are different! (!!!1!!!1!!! :slight_smile: In the SRV2 case
the DataSectionObject has WasPurged set. But why?

This flag could be set by memory manager if file size wasn’t passed to it
while the section creating. It’s ok because it could be a call of memory
manager(through the cache manager) by FSD. For this case that means the
file was opened with cache enabled and the section was just created.

>> The tests are run independently. Test 1 always succeeds. Test 2 always fails.

Then i can’t understand why you except random data in view right after file
mapping?

Here is an excerpt from the actual test, which I am hoping will clarify things:
<<
[snip]
// Parameters:
// FilePath
// CreateFlags: one of 0, FILE_FLAG_NO_BUFFERING, FILE_FLAG_WRITE_THROUGH
// EarlyClose: one of TRUE, FALSE

Handle = CreateFileW(FilePath,
GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL | CreateFlags, 0);
ASSERT(INVALID_HANDLE_VALUE != Handle);

Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE,
0, FileSize0 + FileSize1, 0);
ASSERT(0 != Mapping);

if (EarlyClose)
{
Success = CloseHandle(Handle);
ASSERT(Success);
}

MappedView = MapViewOfFile(Mapping, FILE_MAP_ALL_ACCESS, 0, 0, 0); // [1]
ASSERT(0 != MappedView);

srand(seed);
for (PUINT8 Bgn = MappedView + FileSize1 / 2, End = Bgn + FileSize0; End > Bgn; Bgn++)
*Bgn = rand() & 0xff; // [2]

Success = UnmapViewOfFile(MappedView);
ASSERT(Success);

MappedView = MapViewOfFile(Mapping, FILE_MAP_ALL_ACCESS, 0, 0, 0); // [3]
ASSERT(0 != MappedView);

srand(seed);
for (PUINT8 Bgn = MappedView + FileSize1 / 2, End = Bgn + FileSize0; End > Bgn; Bgn++)
ASSERT(*Bgn == (rand() & 0xff)); // [4]

Success = UnmapViewOfFile(MappedView);
ASSERT(Success);

Success = CloseHandle(Mapping);
ASSERT(Success);

if (!EarlyClose)
{
Success = CloseHandle(Handle);
ASSERT(Success);
}

Handle = CreateFileW(FilePath,
GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, 0,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | CreateFlags, 0);
ASSERT(INVALID_HANDLE_VALUE != Handle);

Mapping = CreateFileMappingW(Handle, 0, PAGE_READWRITE,
0, FileSize0 + FileSize1, 0);
ASSERT(0 != Mapping);

if (EarlyClose)
{
Success = CloseHandle(Handle);
ASSERT(Success);
}

MappedView = MapViewOfFile(Mapping, FILE_MAP_ALL_ACCESS, 0, 0, 0);
ASSERT(0 != MappedView);

srand(seed);
for (PUINT8 Bgn = MappedView + FileSize1 / 2, End = Bgn + FileSize0; End > Bgn; Bgn++)
ASSERT(*Bgn == (rand() & 0xff)); // [5]
[snip]

>

This test is run multiple times with different parameters. The two cases of interest are:

CASE (1): SUCCESS

  • Parameters
    FilePath = \?\GLOBALROOT\Device\Volume{GUID}\file0
    CreateFlags = FILE_FLAG_NO_BUFFERING
    EarlyClose = FALSE
  • Code References:
    [1]: MapViewOfFile succeeds
    [2]: I receive the first IRP_MJ_READ. The DataSectionObject is *not* NULL on my FCB. It is not marked WasPurged.
    [5]: The assertions pass.

Case (2): FAILURE

  • Parameters
    FilePath = \localhost\winfsp-tests-share\TESTDIR\file0 path
    winfsp-tests-share has been mapped using NetShareAdd
    CreateFlags = FILE_FLAG_NO_BUFFERING
    EarlyClose = FALSE
  • Code References:
    [1]: MapViewOfFile succeeds
    [2]: I receive the first IRP_MJ_READ. The DataSectionObject is *NULL* on my FCB!
    [3]: The DataSectionObject is still NULL here. I believe after this point it gets created. It is marked WasPurged.
    [5]: The assertions fail.

I cannot explain why at point [2] the DataSectionObject is NULL when running through SRV2, but I suspect that the reason is the answer we seek.

Many thanks for all your help.

Bill

> I cannot explain why at point [2] the DataSectionObject is NULL when
running through SRV2, but I suspect that the reason is the answer we seek.

Because a section is created by network redirector not by your FSD. SRV2
opens file for usual read/write. It can’t be the reason of your issue.

> Because a section is created by network redirector not by your FSD. SRV2
opens file for usual read/write. It can’t be the reason of your issue.

Fair enough.

But why does the redirector decide not to send me IRP_MJ_WRITE for the page modifications in loop [2]? And why does a DataSectionObject eventually get created after the MapViewOfFile in [3]?

[Both questions are for case (2).]

Bill

> And why does a DataSectionObject eventually get created after the
MapViewOfFile in [3]?

Because it was cached read likely. DataSectionObject is created not only
for memory mappings. It’s created for cache mapping also.

But why does the redirector decide not to send me IRP_MJ_WRITE for the
page modifications in loop [2]?

For example, network redirector delayed write to network to avoid its
overloading. If it’s so, the question is why
after file closing the write request wasn’t sent. Try to flush file after
buffer filling and before UnmapViewOfFile to see if IRP_MJ_WRITE will come.

This probably means your driver did not call Cache Manager to process this read. It is unlikely this was paging IO as there was no mapped pages (DataSectionObject was NULL) and MS designed components do not have a bad habit to issue paging read for such cases.

May be you need to trace this first read to verify that it was processed correctly. For example - it might have been IRP_MN_MDL read that you processed as non-cached read.

Slava Imameev wrote:
<<

This probably means your driver did not call Cache Manager to process this read.
It is unlikely this was paging IO as there was no mapped pages
(DataSectionObject was NULL) and MS designed components do not have a bad habit
to issue paging read for such cases.

May be you need to trace this first read to verify that it was processed
correctly. For example - it might have been IRP_MN_MDL read that you processed
as non-cached read.

>

My driver does not call the cache manager to process this read. This is because the IRP is marked as IRP_NOCACHE. It is also not marked IRP_MN_MDL.

Here is the full READ IRP:
<<
kd> !irp @@(Irp) 1
Irp is active with 2 stacks 1 is current (= 0xfffff98008b60f70)
Mdl=fffffa8004641cc8: No System Buffer: Thread fffffa8002ab2080: Irp stack trace.
Flags = 40000001
ThreadListEntry.Flink = fffff98008b60ec0
ThreadListEntry.Blink = fffff98008b60ec0
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000
Cancel = 00
CancelIrql = 0
ApcEnvironment = 00
UserIosb = 00000000
UserEvent = 00000000
Overlay.AsynchronousParameters.UserApcRoutine = 00000000
Overlay.AsynchronousParameters.UserApcContext = 00000000
Overlay.AllocationSize = 00000000 - 00000000
CancelRoutine = 00000000
UserBuffer = 00000000
&Tail.Overlay.DeviceQueueEntry = fffff98008b60f18
Tail.Overlay.Thread = fffffa8002ab2080
Tail.Overlay.AuxiliaryBuffer = 00000000
Tail.Overlay.ListEntry.Flink = 00000000
Tail.Overlay.ListEntry.Blink = 00000000
Tail.Overlay.CurrentStackLocation = fffff98008b60f70
Tail.Overlay.OriginalFileObject = fffffa8004bbe620
Tail.Apc = 00000000
Tail.CompletionKey = 00000000
cmd flg cl Device File Completion-Context

[IRP_MJ_READ(3), N/A(0)]
0 e0 fffffa80032e68f0 fffffa8004bbe620 fffff880015079a0-fffffa8002b084f0 Success Error Cancel
\FileSystem\WinFsp fltmgr!FltpPassThroughCompletion
Args: 00008000 00000000 00000000 00000000
[IRP_MJ_READ(3), N/A(0)]
0 e1 fffffa8004a2b350 fffffa8004bbe620 fffff88003651cd8-fffffa80046eecb0 Success Error Cancel pending
\FileSystem\FltMgr rdbss!RxShadowIrpCompletion
Args: 00008000 00000000 00000000 00000000
>

Anatoly Mikhailov wrote:

Try to flush file after buffer filling and
before UnmapViewOfFile to see if IRP_MJ_WRITE will come.

I tried doing FlushViewOfFile immediately after writing the buffer. When run under SRV2 I never received any WRITE’s to my FSD. [When run against the file system directly I receive AcquireForCcFlush, Write, ReleaseForCcFlush.]

I was asked earlier whether I implement oplocks. The answer is no. I am wondering if this somehow affects things.

Bill

No oplock implemented could affect. That’s why I asked you about it before.
First of all check if your FSD get some of them before any reading. You’ll
see them right after open request I think.

You can do test 2 with not your FSD also just to make sure it’s a bug in
your FSD.

31 окт. 2016 г. 9:26 PM пользователь “Anatoly Mikhailov” <
xxxxx@gmail.com> написал:

No oplock implemented could affect. That’s why I asked you about it
before. First of all check if your FSD get some of them before any reading.
You’ll see them right after open request I think.

> rdbss!RxShadowIrpCompletion

RDBSS is used to implement FSD. Looks like there is a file system above and it employs your FSD as a backend. Can you provide a call stack for this read request?

> RDBSS is used to implement FSD. Looks like there is a file system above
and it employs your FSD as a backend. Can you provide a call stack for this
read request?

RDBSS is used by network redirectors.

2016-10-31 21:56 GMT+03:00 :

> > rdbss!RxShadowIrpCompletion
>
> RDBSS is used to implement FSD. Looks like there is a file system above
> and it employs your FSD as a backend. Can you provide a call stack for this
> read request?
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

We are talking about the server side while network redirector( namely mrxsmb ) is on the client side.

> We are talking about the server side while network redirector( namely
mrxsmb ) is on the client side.

Server side open files as usual client of FSD.

2016-10-31 22:16 GMT+03:00 :

>


>
> We are talking about the server side while network redirector( namely
> mrxsmb ) is on the client side.
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>