Dead-lock in MiMappedPageWriter.

Hi All,

I am experiencing a dead-lock running my FSD on Windows 2k3 SP1 system in MiMappedPageWriter API. The output of the stack is shown below. This thread takes the PagingIoResource exclusively, and than calls KeWaitForSingleObject and never returns from it. Any suggestion of what might be causing it will be greatly appreciated.

f791ad00 80832f7a nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
f791ad2c 8082927a nt!KiSwapThread+0x284 (FPO: [Non-Fpo])
f791ad74 80847a51 nt!KeWaitForSingleObject+0x346 (FPO: [Non-Fpo])
f791adac 80948bb2 nt!MiMappedPageWriter+0x4d (FPO: [Non-Fpo])
f791addc 8088d4d2 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

I suspect that it migh have something to do with my driver not suppoprting the fast io calls, but I cannot put my finger on it.

Thanks in advance for yout help.

-Ilya.

>This thread takes the PagingIoResource exclusively, and than calls KeWaitForSingleObject

This thread calls FASTIO->AcquireForModWrite if it presents or acquires resource from the FSRTL_COMMON_FCB_HEADER( the acquired resource depends on the flags ), then sends asynchronous paging write request. The acquired resource is freed in the APC called after IRP completion. KeWaitForSingleObject, which you observed, waits for the event that signals that the thread must wake up and flush dirty pages. i.e.

MiMappedPageWriter(){

while( KeWaitForSingleObject( FlushDirtyPagesEvent ) ){
File = GetPagesToFlush();
AcquiredResource = AcquireResources( File );
SendAsynchronousWriteIrp( …File, … , ApcThatFreesAcquiredResource, AcquiredResource … );
}
}

I suspect that it migh have something to do with my driver not suppoprting the fast io calls,

I suspect that you do not properly complete the IRP or disable the normal APCs delivering for this thread( e.g. forget to call KeLeaveCriticalRegion() ).
If you acquire resources in FASTIO->AcquireForModWrite() you must release them in FASTIO->ReleaseForModWrite().


Slava Imameyev, xxxxx@hotmail.com

wrote in message news:xxxxx@ntfsd…
Hi All,

I am experiencing a dead-lock running my FSD on Windows 2k3 SP1 system in MiMappedPageWriter API. The output of the stack is shown below. This thread takes the PagingIoResource exclusively, and than calls KeWaitForSingleObject and never returns from it. Any suggestion of what might be causing it will be greatly appreciated.

f791ad00 80832f7a nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
f791ad2c 8082927a nt!KiSwapThread+0x284 (FPO: [Non-Fpo])
f791ad74 80847a51 nt!KeWaitForSingleObject+0x346 (FPO: [Non-Fpo])
f791adac 80948bb2 nt!MiMappedPageWriter+0x4d (FPO: [Non-Fpo])
f791addc 8088d4d2 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

I suspect that it migh have something to do with my driver not suppoprting the fast io calls, but I cannot put my finger on it.

Thanks in advance for yout help.

-Ilya.

I’ve returned from my vacation and back to this issue - I still have not resolved it, but I have more information this time.

Here is what I think is happening:
After grabbing the PagingIoResource as Shared via AcquireForModWrite call back APi, the MiMappedPageWriter was issuing an FsdWrite request that I was always posting since the wait was set to FALSE(The IRP_CONTEXT_FLAG_WAIT was not set)… In normal case, after processing the posted write request and completing the IRP, the MiMappedPageWriter would release the PagingIoResource via ReleaseForModWrite. However in some cases the worker thread tasked with processing the posted write request would get stack trying to acquire the PagingIoResource as Shared. After quick analysis, I found that the PagingIoResource was already acquired exclusively by MiMappedPageWriter, which I suspect is at the root of my problem and begs a question. How did the resource get acquired exclusively by MiMappedPageWriter while I always acquire it as shared in call-back APIs??? Another question is if it is OK to post the MiMappedPageWriter issued write requests?
-Ilya.
-------------- Original message --------------
From: “Ilya Levin”

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
Sent: Monday, December 25, 2006 9:15 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Dead-lock in MiMappedPageWriter.

>This thread takes the PagingIoResource exclusively, and than calls KeWaitForSingleObject

This thread calls FASTIO->AcquireForModWrite if it presents or acquires resource from the FSRTL_COMMON_FCB_HEADER( the acquired resource depends on the flags ), then sends asynchronous paging write request. The acquired resource is freed in the APC called after IRP completion. KeWaitForSingleObject, which you observed, waits for the event that signals that the thread must wake up and flush dirty pages. i.e.

MiMappedPageWriter(){

while( KeWaitForSingleObject( FlushDirtyPagesEvent ) ){
File = GetPagesToFlush();
AcquiredResource = AcquireResources( File );
SendAsynchronousWriteIrp( …File, … , ApcThatFreesAcquiredResource, AcquiredResource … );
}
}

>I suspect that it migh have something to do with my driver not suppoprting the fast io calls,

I suspect that you do not properly complete the IRP or disable the normal APCs delivering for this thread( e.g. forget to call KeLeaveCriticalRegion() ).
If you acquire resources in FASTIO->AcquireForModWrite() you must release them in FASTIO->ReleaseForModWrite().


Slava Imameyev, xxxxx@hotmail.com

wrote in message news:xxxxx@ntfsd…
Hi All,

I am experiencing a dead-lock running my FSD on Windows 2k3 SP1 system in MiMappedPageWriter API. The output of the stack is shown below. This thread takes the PagingIoResource exclusively, and than calls KeWaitForSingleObject and never returns from it. Any suggestion of what might be causing it will be greatly appreciated.

f791ad00 80832f7a nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
f791ad2c 8082927a nt!KiSwapThread+0x284 (FPO: [Non-Fpo])
f791ad74 80847a51 nt!KeWaitForSingleObject+0x346 (FPO: [Non-Fpo])
f791adac 80948bb2 nt!MiMappedPageWriter+0x4d (FPO: [Non-Fpo])
f791addc 8088d4d2 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
00000000 00000000 nt!KiThreadStartup+0x16

I suspect that it migh have something to do with my driver not suppoprting the fast io calls, but I cannot put my finger on it.

Thanks in advance for yout help.

-Ilya.


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

I think that the worker thread’s work item must call IoSetTopLevelIrp with
some non-NULL argument before calling into the FSD.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
> I’ve returned from my vacation and back to this issue - I still have not
resolved it, but I have more information this time.
>
> Here is what I think is happening:
> After grabbing the PagingIoResource as Shared via AcquireForModWrite call
back APi, the MiMappedPageWriter was issuing an FsdWrite request that I was
always posting since the wait was set to FALSE(The IRP_CONTEXT_FLAG_WAIT was
not set)… In normal case, after processing the posted write request and
completing the IRP, the MiMappedPageWriter would release the PagingIoResource
via ReleaseForModWrite. However in some cases the worker thread tasked with
processing the posted write request would get stack trying to acquire the
PagingIoResource as Shared. After quick analysis, I found that the
PagingIoResource was already acquired exclusively by MiMappedPageWriter, which
I suspect is at the root of my problem and begs a question. How did the
resource get acquired exclusively by MiMappedPageWriter while I always acquire
it as shared in call-back APIs??? Another question is if it is OK to post the
MiMappedPageWriter issued write requests?
> -Ilya.
> -------------- Original message --------------
> From: “Ilya Levin”
>
>
>
>
>
>
> From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Slava Imameyev
> Sent: Monday, December 25, 2006 9:15 AM
> To: Windows File Systems Devs Interest List
> Subject: Re:[ntfsd] Dead-lock in MiMappedPageWriter.
>
> >This thread takes the PagingIoResource exclusively, and than calls
KeWaitForSingleObject
>
> This thread calls FASTIO->AcquireForModWrite if it presents or acquires
resource from the FSRTL_COMMON_FCB_HEADER( the acquired resource depends on the
flags ), then sends asynchronous paging write request. The acquired resource is
freed in the APC called after IRP completion. KeWaitForSingleObject, which you
observed, waits for the event that signals that the thread must wake up and
flush dirty pages. i.e.
>
> MiMappedPageWriter(){
>
> while( KeWaitForSingleObject( FlushDirtyPagesEvent ) ){
> File = GetPagesToFlush();
> AcquiredResource = AcquireResources( File );
> SendAsynchronousWriteIrp( …File, … , ApcThatFreesAcquiredResource,
AcquiredResource … );
> }
> }
>
> >I suspect that it migh have something to do with my driver not suppoprting
the fast io calls,
>
> I suspect that you do not properly complete the IRP or disable the normal
APCs delivering for this thread( e.g. forget to call KeLeaveCriticalRegion() ).
> If you acquire resources in FASTIO->AcquireForModWrite() you must release
them in FASTIO->ReleaseForModWrite().
>
> –
> Slava Imameyev, xxxxx@hotmail.com
>
>
> wrote in message news:xxxxx@ntfsd…
> Hi All,
>
> I am experiencing a dead-lock running my FSD on Windows 2k3 SP1 system in
MiMappedPageWriter API. The output of the stack is shown below. This thread
takes the PagingIoResource exclusively, and than calls KeWaitForSingleObject
and never returns from it. Any suggestion of what might be causing it will be
greatly appreciated.
>
> f791ad00 80832f7a nt!KiSwapContext+0x26 (FPO: [Uses EBP] [0,0,4])
> f791ad2c 8082927a nt!KiSwapThread+0x284 (FPO: [Non-Fpo])
> f791ad74 80847a51 nt!KeWaitForSingleObject+0x346 (FPO: [Non-Fpo])
> f791adac 80948bb2 nt!MiMappedPageWriter+0x4d (FPO: [Non-Fpo])
> f791addc 8088d4d2 nt!PspSystemThreadStartup+0x2e (FPO: [Non-Fpo])
> 00000000 00000000 nt!KiThreadStartup+0x16
>
>
> I suspect that it migh have something to do with my driver not suppoprting
the fast io calls, but I cannot put my finger on it.
>
> Thanks in advance for yout help.
>
> -Ilya.
>
> —
> Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com