Hang in CcPurgeCacheSection while AcquireForModWrite is blocked

NTFSD
1

Hi,

I have a question regarding the implementation of the AcquireForModWrite
callback.
In one edge case, this callback is blocked waiting on an event. During the
same time,
another thread calls CcPurgeCacheSection, and gets stuck in
KeWaitForSingleObject.
So what are my choices? Return STATUS_CANT_WAIT and hope that the MPW
will retry in its next scan? Or will it simply throw these dirty pages
away?
I understand that returning any status other than SUCCESS or CANT_WAIT will
result in the default behavior (Main/PagingIo resource dependent on
FCB->Flags),
which is not sufficient in our FSD’s case.

So, I shouldn’t really block at all in this callback? Or is there any way to
avoid this
deadlock. I was under the assumption that during AcquireForModWrite,
no VM resources are acquired, to enforce the FSD-CM-VM locking hierarchy.
In this case, it looks like though that the MiMappedPageWriter is holding
some
internal dispatcher object which the MmPurgeSection now wants!

The following are the 2 threads:

0: kd> .thread 85e203a0
Implicit thread is now 85e203a0
0: kd> kbL
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
eb473a5c f00ee1cf 85984408 00000000 00000000 nt!KeWaitForSingleObject+0x1a3
eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD!__wait+0x3f
eb473aa4 f0105707 e234af8c 00000000 e234af30 MYFSD!__acquire_shared+0x98
eb473ad0 f00f0a3c e234aed0 00000001 00000000 MYFSD!__AcquireObject+0xaf
eb473b2c f00f06a6 e234aed0 00000002 00000000 MYFSD!acq_lock+0x14f
eb473b50 f00f058a e234aed0 00000002 00000000 MYFSD!__LockDataW+0x106
eb473b6c f005649a e234aed0 00000002 00000000 MYFSD!__LockData+0x1a
eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
eb473d40 f0052f12 85e207f8 85e2081c eb473d74 MYFSD!AcquireForModWrite+0x175
eb473d50 8049b960 8586db68 85e207f8 85e2081c
MYFSD!FastIoAcquireForModWrite+0x22
eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
nt!FsRtlAcquireFileForModWrite+0x2e
eb473da8 804554ce 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
eb473ddc 8046a9d2 8043d042 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

0: kd> .thread 85864da0
Implicit thread is now 85864da0
0: kd> kbL
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
f01a3aac 8043e2d6 80483e70 00000013 00000000 nt!KeWaitForSingleObject+0x1a3
f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328
f01a3b5c f0057d9e 858972ec 00000000 00000000 nt!CcPurgeCacheSection+0x108
f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee MYFSD!SyncFunctionI+0x541
f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b
f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
f01a3d10 f01267db e23b0c68 e25bb020 e25bb020 MYFSD!process_request+0xc1
f01a3d2c f0151a00 e23b0e28 00000000 00000000 MYFSD!ThreadRoot+0x127
f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Thanks in advance.
-Vipul.

2

I believe that when you call CcPurgeCacheSection you shouldn’t held any
resources that may block AcquireForModWrite or LazyWriter callbacks for
this file.
At least FASTFAT never held PagingIoResource when it calls
CcPurgeCacheSection. You need to held only Main resource for the file to
suspend user activity.

Alexei.

“Vipul” wrote in message news:xxxxx@ntfsd…
>
> Hi,
>
> I have a question regarding the implementation of the AcquireForModWrite
> callback.
> In one edge case, this callback is blocked waiting on an event. During the
> same time,
> another thread calls CcPurgeCacheSection, and gets stuck in
> KeWaitForSingleObject.
> So what are my choices? Return STATUS_CANT_WAIT and hope that the MPW
> will retry in its next scan? Or will it simply throw these dirty pages
> away?
> I understand that returning any status other than SUCCESS or CANT_WAIT
will
> result in the default behavior (Main/PagingIo resource dependent on
> FCB->Flags),
> which is not sufficient in our FSD’s case.
>
> So, I shouldn’t really block at all in this callback? Or is there any way
to
> avoid this
> deadlock. I was under the assumption that during AcquireForModWrite,
> no VM resources are acquired, to enforce the FSD-CM-VM locking hierarchy.
> In this case, it looks like though that the MiMappedPageWriter is holding
> some
> internal dispatcher object which the MmPurgeSection now wants!
>
> The following are the 2 threads:
>
> 0: kd> .thread 85e203a0
> Implicit thread is now 85e203a0
> 0: kd> kbL
> Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
> eb473a5c f00ee1cf 85984408 00000000 00000000
nt!KeWaitForSingleObject+0x1a3
> eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD! wait+0x3f
> eb473aa4 f0105707 e234af8c 00000000 e234af30 MYFSD! acquire_shared+0x98
> eb473ad0 f00f0a3c e234aed0 00000001 00000000 MYFSD! AcquireObject+0xaf
> eb473b2c f00f06a6 e234aed0 00000002 00000000 MYFSD!acq_lock+0x14f
> eb473b50 f00f058a e234aed0 00000002 00000000 MYFSD! LockDataW+0x106
> eb473b6c f005649a e234aed0 00000002 00000000 MYFSD!__LockData+0x1a
> eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
> eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
> eb473d40 f0052f12 85e207f8 85e2081c eb473d74
MYFSD!AcquireForModWrite+0x175
> eb473d50 8049b960 8586db68 85e207f8 85e2081c
> MYFSD!FastIoAcquireForModWrite+0x22
> eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
> nt!FsRtlAcquireFileForModWrite+0x2e
> eb473da8 804554ce 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
> eb473ddc 8046a9d2 8043d042 00000000 00000000
nt!PspSystemThreadStartup+0x54
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> 0: kd> .thread 85864da0
> Implicit thread is now 85864da0
> 0: kd> kbL
> Stack trace for last set context - .thread/.cxr resets it
> ChildEBP RetAddr Args to Child
> f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
> f01a3aac 8043e2d6 80483e70 00000013 00000000
nt!KeWaitForSingleObject+0x1a3
> f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328
> f01a3b5c f0057d9e 858972ec 00000000 00000000 nt!CcPurgeCacheSection+0x108
> f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
> f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
> f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee MYFSD!SyncFunctionI+0x541
> f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b
> f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
> f01a3d10 f01267db e23b0c68 e25bb020 e25bb020 MYFSD!process_request+0xc1
> f01a3d2c f0151a00 e23b0e28 00000000 00000000 MYFSD!ThreadRoot+0x127
> f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
> f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000
nt!PspSystemThreadStartup+0x54
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> Thanks in advance.
> -Vipul.
>
>
>
>

3

FastFat holds the paging resource in addition to main in some cases
where it calls CcPurgeCacheSection - for example, while processing a
non-cached non-paging I/O write, to force page faults coming down on
mapped views of the file to wait.

Alexei Jelvis wrote:

I believe that when you call CcPurgeCacheSection you shouldn’t held any
resources that may block AcquireForModWrite or LazyWriter callbacks for
this file.
At least FASTFAT never held PagingIoResource when it calls
CcPurgeCacheSection. You need to held only Main resource for the file to
suspend user activity.

Alexei.

“Vipul” wrote in message news:xxxxx@ntfsd…
>
>>Hi,
>>
>>I have a question regarding the implementation of the AcquireForModWrite
>>callback.
>>In one edge case, this callback is blocked waiting on an event. During the
>>same time,
>> another thread calls CcPurgeCacheSection, and gets stuck in
>>KeWaitForSingleObject.
>> So what are my choices? Return STATUS_CANT_WAIT and hope that the MPW
>> will retry in its next scan? Or will it simply throw these dirty pages
>>away?
>> I understand that returning any status other than SUCCESS or CANT_WAIT
>
> will
>
>> result in the default behavior (Main/PagingIo resource dependent on
>>FCB->Flags),
>>which is not sufficient in our FSD’s case.
>>
>>So, I shouldn’t really block at all in this callback? Or is there any way
>
> to
>
>>avoid this
>> deadlock. I was under the assumption that during AcquireForModWrite,
>> no VM resources are acquired, to enforce the FSD-CM-VM locking hierarchy.
>>In this case, it looks like though that the MiMappedPageWriter is holding
>>some
>> internal dispatcher object which the MmPurgeSection now wants!
>>
>>The following are the 2 threads:
>>
>>0: kd> .thread 85e203a0
>>Implicit thread is now 85e203a0
>>0: kd> kbL
>> Stack trace for last set context - .thread/.cxr resets it
>>ChildEBP RetAddr Args to Child
>>eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
>>eb473a5c f00ee1cf 85984408 00000000 00000000
>
> nt!KeWaitForSingleObject+0x1a3
>
>>eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD! wait+0x3f
>>eb473aa4 f0105707 e234af8c 00000000 e234af30 MYFSD! acquire_shared+0x98
>>eb473ad0 f00f0a3c e234aed0 00000001 00000000 MYFSD! AcquireObject+0xaf
>>eb473b2c f00f06a6 e234aed0 00000002 00000000 MYFSD!acq_lock+0x14f
>>eb473b50 f00f058a e234aed0 00000002 00000000 MYFSD! LockDataW+0x106
>>eb473b6c f005649a e234aed0 00000002 00000000 MYFSD!__LockData+0x1a
>>eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
>>eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
>>eb473d40 f0052f12 85e207f8 85e2081c eb473d74
>
> MYFSD!AcquireForModWrite+0x175
>
>>eb473d50 8049b960 8586db68 85e207f8 85e2081c
>>MYFSD!FastIoAcquireForModWrite+0x22
>>eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
>>nt!FsRtlAcquireFileForModWrite+0x2e
>>eb473da8 804554ce 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
>>eb473ddc 8046a9d2 8043d042 00000000 00000000
>
> nt!PspSystemThreadStartup+0x54
>
>>00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>
>>0: kd> .thread 85864da0
>>Implicit thread is now 85864da0
>>0: kd> kbL
>> Stack trace for last set context - .thread/.cxr resets it
>>ChildEBP RetAddr Args to Child
>>f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
>>f01a3aac 8043e2d6 80483e70 00000013 00000000
>
> nt!KeWaitForSingleObject+0x1a3
>
>>f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328
>>f01a3b5c f0057d9e 858972ec 00000000 00000000 nt!CcPurgeCacheSection+0x108
>>f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
>>f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
>>f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee MYFSD!SyncFunctionI+0x541
>>f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b
>>f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
>>f01a3d10 f01267db e23b0c68 e25bb020 e25bb020 MYFSD!process_request+0xc1
>>f01a3d2c f0151a00 e23b0e28 00000000 00000000 MYFSD!ThreadRoot+0x127
>>f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
>>f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000
>
> nt!PspSystemThreadStartup+0x54
>
>>00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>>
>>Thanks in advance.
>>-Vipul.
>>
>>
>>
>>
>
>
>
>
>

4

The problem is not with the system but that you’re holding your OWN
private lock across CcPurgeCacheSection. You’re imposing your own
invisible web of dependencies on top of an existing, carefully
constructed, locking heirarchy. It’s possible only if you know you’re
only going to acquire at some specific place in the FSD-CM-VM heirarchy
every time.

Vipul wrote:

Hi,

I have a question regarding the implementation of the AcquireForModWrite
callback.
In one edge case, this callback is blocked waiting on an event. During the
same time,
another thread calls CcPurgeCacheSection, and gets stuck in
KeWaitForSingleObject.
So what are my choices? Return STATUS_CANT_WAIT and hope that the MPW
will retry in its next scan? Or will it simply throw these dirty pages
away?
I understand that returning any status other than SUCCESS or CANT_WAIT will
result in the default behavior (Main/PagingIo resource dependent on
FCB->Flags),
which is not sufficient in our FSD’s case.

So, I shouldn’t really block at all in this callback? Or is there any way to
avoid this
deadlock. I was under the assumption that during AcquireForModWrite,
no VM resources are acquired, to enforce the FSD-CM-VM locking hierarchy.
In this case, it looks like though that the MiMappedPageWriter is holding
some
internal dispatcher object which the MmPurgeSection now wants!

The following are the 2 threads:

0: kd> .thread 85e203a0
Implicit thread is now 85e203a0
0: kd> kbL
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
eb473a5c f00ee1cf 85984408 00000000 00000000 nt!KeWaitForSingleObject+0x1a3
eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD!__wait+0x3f
eb473aa4 f0105707 e234af8c 00000000 e234af30 MYFSD!__acquire_shared+0x98
eb473ad0 f00f0a3c e234aed0 00000001 00000000 MYFSD!__AcquireObject+0xaf
eb473b2c f00f06a6 e234aed0 00000002 00000000 MYFSD!acq_lock+0x14f
eb473b50 f00f058a e234aed0 00000002 00000000 MYFSD!__LockDataW+0x106
eb473b6c f005649a e234aed0 00000002 00000000 MYFSD!__LockData+0x1a
eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
eb473d40 f0052f12 85e207f8 85e2081c eb473d74 MYFSD!AcquireForModWrite+0x175
eb473d50 8049b960 8586db68 85e207f8 85e2081c
MYFSD!FastIoAcquireForModWrite+0x22
eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
nt!FsRtlAcquireFileForModWrite+0x2e
eb473da8 804554ce 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
eb473ddc 8046a9d2 8043d042 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

0: kd> .thread 85864da0
Implicit thread is now 85864da0
0: kd> kbL
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
f01a3aac 8043e2d6 80483e70 00000013 00000000 nt!KeWaitForSingleObject+0x1a3
f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328
f01a3b5c f0057d9e 858972ec 00000000 00000000 nt!CcPurgeCacheSection+0x108
f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee MYFSD!SyncFunctionI+0x541
f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b
f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
f01a3d10 f01267db e23b0c68 e25bb020 e25bb020 MYFSD!process_request+0xc1
f01a3d2c f0151a00 e23b0e28 00000000 00000000 MYFSD!ThreadRoot+0x127
f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Thanks in advance.
-Vipul.

5

The code you refer to is following:

ExAcquireResourceExclusive( FcbOrDcb->Header.PagingIoResource, TRUE );
ExReleaseResource( FcbOrDcb->Header.PagingIoResource );

CcPurgeCacheSection( FileObject->SectionObjectPointer,
WriteToEof ? &FcbOrDcb->Header.FileSize : &StartingByte,
ByteCount,
FALSE );

Fat doesn’t held resource while calling CcPurgeCacheSection, it acquire
and immediately release PagingIo resource.
You should not block modified page write or lazy writer activity while
purging cache because CcPurgeCacheSection waits for work in progress to
complete.

Alexei.

FastFat holds the paging resource in addition to main in some cases
where it calls CcPurgeCacheSection - for example, while processing a
non-cached non-paging I/O write, to force page faults coming down on
mapped views of the file to wait.

6

You’re looking at the win2k version of FastFat. In XP and wnet, it
certainly does hold the paging I/O resource in some instances.
Apparently this is safe because the FastFat acquire for mod write
callback is a no-op (takes no locks), thus the modified page writer
thread is not blocked. (And apparently there must be no dependency on
the lazy writer thread, since the lazy write callback does take paging I/O).

From write.c, wnet version of FastFat:

//
// Now pick up and hold pagingIO exclusive. This serializes us with the
// completion of a coincedent lazy writer doing its part of the write of
// this range.
//
// We hold so that we will prevent a pagefault from occuring and seeing
// soon-to-be stale data from the disk. We used to believe this was
// something to be left to the app to synchronize; we now realize that
// noncached IO on a fileserver is doomed without the filesystem forcing
// the coherency issue. By only penalizing noncached coherency when
// needed, this is about the best we can do.
//

ExAcquireResourceExclusiveLite( FcbOrDcb->Header.PagingIoResource, TRUE);
PagingIoResourceAcquired = TRUE;

CcPurgeCacheSection( FileObject->SectionObjectPointer,
WriteToEof ? &FcbOrDcb->Header.FileSize :
&StartingByte,
ByteCount,
FALSE );

Alexei Jelvis wrote:

The code you refer to is following:

ExAcquireResourceExclusive( FcbOrDcb->Header.PagingIoResource, TRUE );
ExReleaseResource( FcbOrDcb->Header.PagingIoResource );

CcPurgeCacheSection( FileObject->SectionObjectPointer,
WriteToEof ? &FcbOrDcb->Header.FileSize : &StartingByte,
ByteCount,
FALSE );

Fat doesn’t held resource while calling CcPurgeCacheSection, it acquire
and immediately release PagingIo resource.
You should not block modified page write or lazy writer activity while
purging cache because CcPurgeCacheSection waits for work in progress to
complete.

Alexei.

>FastFat holds the paging resource in addition to main in some cases
>where it calls CcPurgeCacheSection - for example, while processing a
>non-cached non-paging I/O write, to force page faults coming down on
>mapped views of the file to wait.

7

A clarification… the mod write callback is not a no-op for FastFat, it
just isn’t set, which means the system will acquire the file itself in
FsRtlAcquireFileForModWriteEx. Without going through the trouble of
disassembling it myself, there seems to be a contradiction in several
comments as to which resource this function will take.

From ntifs.h:

//
// Following flags determine how the modified page writer should
// acquire the file. These flags can’t change while either resource
// is acquired. If neither of these flags is set then the
// modified/mapped page writer will attempt to acquire the paging io
// resource shared.
//

#define FSRTL_FLAG_ACQUIRE_MAIN_RSRC_EX (0x08)
#define FSRTL_FLAG_ACQUIRE_MAIN_RSRC_SH (0x10)

Now I’ve verified that FastFat does not set these flags, therefore it
would seem that FsRtlAcquireFileForModWriteEx would try to take paging
I/O, which would cause a deadlock on the assumption that
CcPurgeCacheSection is going to block on the mod write thread (which
seems to be true). But a comment in write.c indicates:

// Y’know, the PagingIo case is a mapped page writer, and
// MmFlushSection or the mapped page writer itself already
// snatched up the main exclusive for us via the AcquireForCcFlush
// or AcquireForModWrite logic (the default logic parallels FAT’s
// requirements since this order/model came first).

Now who is right? I assume ntifs.h is wrong and
FsRtlAcquireFileForModWriteEx will try to take main in the absence of
the two above flags, otherwise we have a nasty bug.

Nick Ryan wrote:

You’re looking at the win2k version of FastFat. In XP and wnet, it
certainly does hold the paging I/O resource in some instances.
Apparently this is safe because the FastFat acquire for mod write
callback is a no-op (takes no locks), thus the modified page writer
thread is not blocked. (And apparently there must be no dependency on
the lazy writer thread, since the lazy write callback does take paging
I/O).

From write.c, wnet version of FastFat:

//
// Now pick up and hold pagingIO exclusive. This serializes us with the
// completion of a coincedent lazy writer doing its part of the write of
// this range.
//
// We hold so that we will prevent a pagefault from occuring and seeing
// soon-to-be stale data from the disk. We used to believe this was
// something to be left to the app to synchronize; we now realize that
// noncached IO on a fileserver is doomed without the filesystem forcing
// the coherency issue. By only penalizing noncached coherency when
// needed, this is about the best we can do.
//

ExAcquireResourceExclusiveLite( FcbOrDcb->Header.PagingIoResource, TRUE);
PagingIoResourceAcquired = TRUE;

CcPurgeCacheSection( FileObject->SectionObjectPointer,
WriteToEof ? &FcbOrDcb->Header.FileSize :
&StartingByte,
ByteCount,
FALSE );

Alexei Jelvis wrote:

> The code you refer to is following:
>
> ExAcquireResourceExclusive( FcbOrDcb->Header.PagingIoResource, TRUE );
> ExReleaseResource( FcbOrDcb->Header.PagingIoResource );
>
> CcPurgeCacheSection( FileObject->SectionObjectPointer,
> WriteToEof ? &FcbOrDcb->Header.FileSize : &StartingByte,
> ByteCount,
> FALSE );
>
> Fat doesn’t held resource while calling CcPurgeCacheSection, it acquire
> and immediately release PagingIo resource.
> You should not block modified page write or lazy writer activity while
> purging cache because CcPurgeCacheSection waits for work in progress to
> complete.
>
> Alexei.
>
>
>> FastFat holds the paging resource in addition to main in some cases
>> where it calls CcPurgeCacheSection - for example, while processing a
>> non-cached non-paging I/O write, to force page faults coming down on
>> mapped views of the file to wait.
>
>
>
>
>

8

So, how appropriate is to return STATUS_CANT_WAIT. Should I expect the MPW
to retry after some time?

“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> The problem is not with the system but that you’re holding your OWN
> private lock across CcPurgeCacheSection. You’re imposing your own
> invisible web of dependencies on top of an existing, carefully
> constructed, locking heirarchy. It’s possible only if you know you’re
> only going to acquire at some specific place in the FSD-CM-VM heirarchy
> every time.
>
> Vipul wrote:
>
> > Hi,
> >
> > I have a question regarding the implementation of the AcquireForModWrite
> > callback.
> > In one edge case, this callback is blocked waiting on an event. During
the
> > same time,
> > another thread calls CcPurgeCacheSection, and gets stuck in
> > KeWaitForSingleObject.
> > So what are my choices? Return STATUS_CANT_WAIT and hope that the MPW
> > will retry in its next scan? Or will it simply throw these dirty pages
> > away?
> > I understand that returning any status other than SUCCESS or CANT_WAIT
will
> > result in the default behavior (Main/PagingIo resource dependent on
> > FCB->Flags),
> > which is not sufficient in our FSD’s case.
> >
> > So, I shouldn’t really block at all in this callback? Or is there any
way to
> > avoid this
> > deadlock. I was under the assumption that during AcquireForModWrite,
> > no VM resources are acquired, to enforce the FSD-CM-VM locking
hierarchy.
> > In this case, it looks like though that the MiMappedPageWriter is
holding
> > some
> > internal dispatcher object which the MmPurgeSection now wants!
> >
> > The following are the 2 threads:
> >
> > 0: kd> .thread 85e203a0
> > Implicit thread is now 85e203a0
> > 0: kd> kbL
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
> > eb473a5c f00ee1cf 85984408 00000000 00000000
nt!KeWaitForSingleObject+0x1a3
> > eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD! wait+0x3f
> > eb473aa4 f0105707 e234af8c 00000000 e234af30 MYFSD! acquire_shared+0x98
> > eb473ad0 f00f0a3c e234aed0 00000001 00000000 MYFSD! AcquireObject+0xaf
> > eb473b2c f00f06a6 e234aed0 00000002 00000000 MYFSD!acq_lock+0x14f
> > eb473b50 f00f058a e234aed0 00000002 00000000 MYFSD! LockDataW+0x106
> > eb473b6c f005649a e234aed0 00000002 00000000 MYFSD!__LockData+0x1a
> > eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
> > eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
> > eb473d40 f0052f12 85e207f8 85e2081c eb473d74
MYFSD!AcquireForModWrite+0x175
> > eb473d50 8049b960 8586db68 85e207f8 85e2081c
> > MYFSD!FastIoAcquireForModWrite+0x22
> > eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
> > nt!FsRtlAcquireFileForModWrite+0x2e
> > eb473da8 804554ce 00000000 00000000 00000000 nt!MiMappedPageWriter+0xaa
> > eb473ddc 8046a9d2 8043d042 00000000 00000000
nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> >
> > 0: kd> .thread 85864da0
> > Implicit thread is now 85864da0
> > 0: kd> kbL
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
> > f01a3aac 8043e2d6 80483e70 00000013 00000000
nt!KeWaitForSingleObject+0x1a3
> > f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328
> > f01a3b5c f0057d9e 858972ec 00000000 00000000
nt!CcPurgeCacheSection+0x108
> > f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
> > f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
> > f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee MYFSD!SyncFunctionI+0x541
> > f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b
> > f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
> > f01a3d10 f01267db e23b0c68 e25bb020 e25bb020 MYFSD!process_request+0xc1
> > f01a3d2c f0151a00 e23b0e28 00000000 00000000 MYFSD!ThreadRoot+0x127
> > f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
> > f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000
nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> > Thanks in advance.
> > -Vipul.
> >
> >
> >
> >
>
>
>

9

If you return STATUS_CANT_WAIT from AcquireForModWrite, the modified
page writer will not forget about these dirty pages – these pages will
be put at the end of the list and tried again later. Ntfs will return
STATUS_CANT_WAIT in some case.

Just remember that type of solution will only work if the state causing
you to return STATUS_CANT_WAIT is transient, otherwise the system can
run out of clean pages.

Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vipul
Sent: Tuesday, August 12, 2003 11:26 AM
To: File Systems Developers
Subject: [ntfsd] Re: Hang in CcPurgeCacheSection while
AcquireForModWrite is blocked

So, how appropriate is to return STATUS_CANT_WAIT. Should I expect the
MPW to retry after some time?

“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> The problem is not with the system but that you’re holding your OWN
> private lock across CcPurgeCacheSection. You’re imposing your own
> invisible web of dependencies on top of an existing, carefully
> constructed, locking heirarchy. It’s possible only if you know you’re
> only going to acquire at some specific place in the FSD-CM-VM
> heirarchy every time.
>
> Vipul wrote:
>
> > Hi,
> >
> > I have a question regarding the implementation of the
> > AcquireForModWrite callback.
> > In one edge case, this callback is blocked waiting on an event.
> > During
the
> > same time,
> > another thread calls CcPurgeCacheSection, and gets stuck in
> > KeWaitForSingleObject.
> > So what are my choices? Return STATUS_CANT_WAIT and hope that the
> > MPW will retry in its next scan? Or will it simply throw these
> > dirty pages away?
> > I understand that returning any status other than SUCCESS or
> > CANT_WAIT
will
> > result in the default behavior (Main/PagingIo resource dependent on
> > FCB->Flags),
> > which is not sufficient in our FSD’s case.
> >
> > So, I shouldn’t really block at all in this callback? Or is there
> > any
way to
> > avoid this
> > deadlock. I was under the assumption that during
> > AcquireForModWrite, no VM resources are acquired, to enforce the
> > FSD-CM-VM locking
hierarchy.
> > In this case, it looks like though that the MiMappedPageWriter is
holding
> > some
> > internal dispatcher object which the MmPurgeSection now wants!
> >
> > The following are the 2 threads:
> >
> > 0: kd> .thread 85e203a0
> > Implicit thread is now 85e203a0
> > 0: kd> kbL
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
> > eb473a5c f00ee1cf 85984408 00000000 00000000
nt!KeWaitForSingleObject+0x1a3
> > eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD! wait+0x3f
> > eb473aa4 f0105707 e234af8c 00000000 e234af30
> > MYFSD! acquire_shared+0x98 eb473ad0 f00f0a3c e234aed0 00000001
> > 00000000 MYFSD! AcquireObject+0xaf eb473b2c f00f06a6 e234aed0
> > 00000002 00000000 MYFSD!acq_lock+0x14f eb473b50 f00f058a e234aed0
> > 00000002 00000000 MYFSD! LockDataW+0x106 eb473b6c f005649a e234aed0

> > 00000002 00000000 MYFSD!__LockData+0x1a
> > eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
> > eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
> > eb473d40 f0052f12 85e207f8 85e2081c eb473d74
MYFSD!AcquireForModWrite+0x175
> > eb473d50 8049b960 8586db68 85e207f8 85e2081c
> > MYFSD!FastIoAcquireForModWrite+0x22
> > eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
> > nt!FsRtlAcquireFileForModWrite+0x2e
> > eb473da8 804554ce 00000000 00000000 00000000
> > nt!MiMappedPageWriter+0xaa eb473ddc 8046a9d2 8043d042 00000000
> > 00000000
nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> >
> > 0: kd> .thread 85864da0
> > Implicit thread is now 85864da0
> > 0: kd> kbL
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
> > f01a3aac 8043e2d6 80483e70 00000013 00000000
nt!KeWaitForSingleObject+0x1a3
> > f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328

> > f01a3b5c f0057d9e 858972ec 00000000 00000000
nt!CcPurgeCacheSection+0x108
> > f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
> > f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
> > f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee
> > MYFSD!SyncFunctionI+0x541
> > f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b

> > f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
> > f01a3d10 f01267db e23b0c68 e25bb020 e25bb020
> > MYFSD!process_request+0xc1 f01a3d2c f0151a00 e23b0e28 00000000
> > 00000000 MYFSD!ThreadRoot+0x127
> > f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
> > f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000
nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> > Thanks in advance.
> > -Vipul.
> >
> >
> >
> >
>
>
>

—
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

10

Mystery solved. I got impatient and pulled apart
FsRtlAcquireFileForModWriteEx (XP SP1 Free). It does go after the paging
I/O resource if no flags are set, as the comment in ntifs.h indicates.
However, it calls ExAcquireSharedWaitForExclusive with Wait set to
FALSE, so that it will not block if somebody else has it exclusive.
Instead, STATUS_CANT_WAIT is returned. I refer to Molly’s comment on the
implications of this return value.

The second comment I pulled out of FastFat seems to be implying that the
AcquireForModWrite action is ‘snatching up the main exclusive’, but the
comment is in a different context and the grammar could be ambiguous, so
I’ll let it pass. (No programmer anticipates their comments to be
subjected to Talmudic-level analysis anyways…)

Nick Ryan wrote:

A clarification… the mod write callback is not a no-op for FastFat, it
just isn’t set, which means the system will acquire the file itself in
FsRtlAcquireFileForModWriteEx. Without going through the trouble of
disassembling it myself, there seems to be a contradiction in several
comments as to which resource this function will take.

From ntifs.h:

//
// Following flags determine how the modified page writer should
// acquire the file. These flags can’t change while either resource
// is acquired. If neither of these flags is set then the
// modified/mapped page writer will attempt to acquire the paging io
// resource shared.
//

#define FSRTL_FLAG_ACQUIRE_MAIN_RSRC_EX (0x08)
#define FSRTL_FLAG_ACQUIRE_MAIN_RSRC_SH (0x10)

Now I’ve verified that FastFat does not set these flags, therefore it
would seem that FsRtlAcquireFileForModWriteEx would try to take paging
I/O, which would cause a deadlock on the assumption that
CcPurgeCacheSection is going to block on the mod write thread (which
seems to be true). But a comment in write.c indicates:

// Y’know, the PagingIo case is a mapped page writer, and
// MmFlushSection or the mapped page writer itself already
// snatched up the main exclusive for us via the AcquireForCcFlush
// or AcquireForModWrite logic (the default logic parallels FAT’s
// requirements since this order/model came first).

Now who is right? I assume ntifs.h is wrong and
FsRtlAcquireFileForModWriteEx will try to take main in the absence of
the two above flags, otherwise we have a nasty bug.

Nick Ryan wrote:

>
> You’re looking at the win2k version of FastFat. In XP and wnet, it
> certainly does hold the paging I/O resource in some instances.
> Apparently this is safe because the FastFat acquire for mod write
> callback is a no-op (takes no locks), thus the modified page writer
> thread is not blocked. (And apparently there must be no dependency on
> the lazy writer thread, since the lazy write callback does take paging
> I/O).
>
> From write.c, wnet version of FastFat:
>
> //
> // Now pick up and hold pagingIO exclusive. This serializes us with the
> // completion of a coincedent lazy writer doing its part of the write of
> // this range.
> //
> // We hold so that we will prevent a pagefault from occuring and seeing
> // soon-to-be stale data from the disk. We used to believe this was
> // something to be left to the app to synchronize; we now realize that
> // noncached IO on a fileserver is doomed without the filesystem forcing
> // the coherency issue. By only penalizing noncached coherency when
> // needed, this is about the best we can do.
> //
>
> ExAcquireResourceExclusiveLite( FcbOrDcb->Header.PagingIoResource, TRUE);
> PagingIoResourceAcquired = TRUE;
>
> CcPurgeCacheSection( FileObject->SectionObjectPointer,
> WriteToEof ? &FcbOrDcb->Header.FileSize :
> &StartingByte,
> ByteCount,
> FALSE );
>
> Alexei Jelvis wrote:
>
>> The code you refer to is following:
>>
>> ExAcquireResourceExclusive( FcbOrDcb->Header.PagingIoResource, TRUE );
>> ExReleaseResource( FcbOrDcb->Header.PagingIoResource );
>>
>> CcPurgeCacheSection( FileObject->SectionObjectPointer,
>> WriteToEof ? &FcbOrDcb->Header.FileSize : &StartingByte,
>> ByteCount,
>> FALSE );
>>
>> Fat doesn’t held resource while calling CcPurgeCacheSection, it acquire
>> and immediately release PagingIo resource.
>> You should not block modified page write or lazy writer activity while
>> purging cache because CcPurgeCacheSection waits for work in progress to
>> complete.
>>
>> Alexei.
>>
>>
>>> FastFat holds the paging resource in addition to main in some cases
>>> where it calls CcPurgeCacheSection - for example, while processing a
>>> non-cached non-paging I/O write, to force page faults coming down on
>>> mapped views of the file to wait.
>>
>>
>>
>>
>>
>>
>
>
>

11

So, if this transient condition was to persist and I were to keep returning
STATUS_CANT_WAIT, the VM is NOT going to simply discard these dirty pages
without going thru a AcquireForModWrite-PagingWrite-ReleaseForModWrite
sequence, in case the system starts running low on clean pages? Is there an
internal count it keeps track of for calls made to AcquireForModWrite for a
FCB (and which returned STATUS_CANT_WAIT).

Thanks a lot,

-Vipul.

“Molly Brown” wrote in message
news:xxxxx@ntfsd…

If you return STATUS_CANT_WAIT from AcquireForModWrite, the modified
page writer will not forget about these dirty pages – these pages will
be put at the end of the list and tried again later. Ntfs will return
STATUS_CANT_WAIT in some case.

Just remember that type of solution will only work if the state causing
you to return STATUS_CANT_WAIT is transient, otherwise the system can
run out of clean pages.

Molly Brown
Microsoft Corporation

This posting is provided “AS IS” with no warranties and confers no
rights.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vipul
Sent: Tuesday, August 12, 2003 11:26 AM
To: File Systems Developers
Subject: [ntfsd] Re: Hang in CcPurgeCacheSection while
AcquireForModWrite is blocked

So, how appropriate is to return STATUS_CANT_WAIT. Should I expect the
MPW to retry after some time?

“Nick Ryan” wrote in message news:xxxxx@ntfsd…
>
> The problem is not with the system but that you’re holding your OWN
> private lock across CcPurgeCacheSection. You’re imposing your own
> invisible web of dependencies on top of an existing, carefully
> constructed, locking heirarchy. It’s possible only if you know you’re
> only going to acquire at some specific place in the FSD-CM-VM
> heirarchy every time.
>
> Vipul wrote:
>
> > Hi,
> >
> > I have a question regarding the implementation of the
> > AcquireForModWrite callback.
> > In one edge case, this callback is blocked waiting on an event.
> > During
the
> > same time,
> > another thread calls CcPurgeCacheSection, and gets stuck in
> > KeWaitForSingleObject.
> > So what are my choices? Return STATUS_CANT_WAIT and hope that the
> > MPW will retry in its next scan? Or will it simply throw these
> > dirty pages away?
> > I understand that returning any status other than SUCCESS or
> > CANT_WAIT
will
> > result in the default behavior (Main/PagingIo resource dependent on
> > FCB->Flags),
> > which is not sufficient in our FSD’s case.
> >
> > So, I shouldn’t really block at all in this callback? Or is there
> > any
way to
> > avoid this
> > deadlock. I was under the assumption that during
> > AcquireForModWrite, no VM resources are acquired, to enforce the
> > FSD-CM-VM locking
hierarchy.
> > In this case, it looks like though that the MiMappedPageWriter is
holding
> > some
> > internal dispatcher object which the MmPurgeSection now wants!
> >
> > The following are the 2 threads:
> >
> > 0: kd> .thread 85e203a0
> > Implicit thread is now 85e203a0
> > 0: kd> kbL
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > eb473a34 8042bfc7 eb473b2c eb473a78 80065634 nt!KiSwapThread+0x1b1
> > eb473a5c f00ee1cf 85984408 00000000 00000000
nt!KeWaitForSingleObject+0x1a3
> > eb473a8c f012a378 e234af9c e234af30 00000001 MYFSD! wait+0x3f
> > eb473aa4 f0105707 e234af8c 00000000 e234af30
> > MYFSD! acquire_shared+0x98 eb473ad0 f00f0a3c e234aed0 00000001
> > 00000000 MYFSD! AcquireObject+0xaf eb473b2c f00f06a6 e234aed0
> > 00000002 00000000 MYFSD!acq_lock+0x14f eb473b50 f00f058a e234aed0
> > 00000002 00000000 MYFSD! LockDataW+0x106 eb473b6c f005649a e234aed0

> > 00000002 00000000 MYFSD!__LockData+0x1a
> > eb473ca4 f00533f4 00000002 cccccc00 8586db68 MYFSD!LockDataI+0x35a
> > eb473cec f0058e05 00000002 00000000 8586db68 MYFSD!LockData+0x54
> > eb473d40 f0052f12 85e207f8 85e2081c eb473d74
MYFSD!AcquireForModWrite+0x175
> > eb473d50 8049b960 8586db68 85e207f8 85e2081c
> > MYFSD!FastIoAcquireForModWrite+0x22
> > eb473d74 8043d0ec 8586db68 85e207f8 85e2081c
> > nt!FsRtlAcquireFileForModWrite+0x2e
> > eb473da8 804554ce 00000000 00000000 00000000
> > nt!MiMappedPageWriter+0xaa eb473ddc 8046a9d2 8043d042 00000000
> > 00000000
nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> >
> > 0: kd> .thread 85864da0
> > Implicit thread is now 85864da0
> > 0: kd> kbL
> > Stack trace for last set context - .thread/.cxr resets it
> > ChildEBP RetAddr Args to Child
> > f01a3a84 8042bfc7 8598f328 8641cd38 85cbeb88 nt!KiSwapThread+0x1b1
> > f01a3aac 8043e2d6 80483e70 00000013 00000000
nt!KeWaitForSingleObject+0x1a3
> > f01a3af4 80411158 8598f328 00000000 00000001 nt!MmPurgeSection+0x328

> > f01a3b5c f0057d9e 858972ec 00000000 00000000
nt!CcPurgeCacheSection+0x108
> > f01a3b98 f0057a65 00000000 00000000 cccccccc MYFSD!PurgeCacheI+0x28e
> > f01a3bc8 f0066df1 f01a3cf0 f01a3ca4 00000000 MYFSD!PurgeCache+0xf5
> > f01a3c88 f006689b 00000000 f01a3cf0 f00f30ee
> > MYFSD!SyncFunctionI+0x541
> > f01a3c94 f00f30ee 85897148 00000000 f01a3d90 MYFSD!SyncFunction+0x1b

> > f01a3cf0 f0126c65 e131e788 e25bb020 00000000 MYFSD!DemandLock+0x1c5
> > f01a3d10 f01267db e23b0c68 e25bb020 e25bb020
> > MYFSD!process_request+0xc1 f01a3d2c f0151a00 e23b0e28 00000000
> > 00000000 MYFSD!ThreadRoot+0x127
> > f01a3da8 804554ce 85c7f188 00000000 00000000 MYFSD!ThreadMain+0x109
> > f01a3ddc 8046a9d2 f01518f7 85c7f188 00000000
nt!PspSystemThreadStartup+0x54
> > 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
> >
> > Thanks in advance.
> > -Vipul.
> >
> >
> >
> >
>
>
>

—
You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com