What's NtfsWaitForIoAtEof waits for?

OSR_Community_User · April 12, 2002, 8:34pm

It seems to hang forever on a resource. Can anybody give me an idea of
what’s going on there?
Here is the thread stack I’ve got from WinDbg (W2K):

Resource @ 0x81cbd9e8 Exclusively owned
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 820ad620-01

THREAD 820ad620 Cid 8.18 Teb: 00000000 Win32Thread: 00000000 WAIT:
(Executive) KernelMode Non-Alertable
eb42f800 NotificationEvent
Not impersonating
Owning Process 820ae8a0
WaitTime (seconds) 8134
Context Switch Count 757
UserTime 0:00:00.0000
KernelTime 0:00:00.0062
Start Address nt!ExpWorkerThread (0x80418a7c)
Stack Init eb430000 Current eb42f44c Base eb430000 Limit eb42d000 Call
0
Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
eb42f464 8042d774 e2b925b8 eb42f7f8 00000000 nt!KiSwapThread+0xc5
eb42f48c bff0b262 eb42f800 00000000 00000000
nt!KeWaitForSingleObject+0x1a1
eb42f4b4 bfef04ea e2b925b8 eb42f7c4 0000f000
Ntfs!NtfsWaitForIoAtEof+0x43
eb42f830 bfedf63f 81cb4ee8 bea49e90 00000000 Ntfs!NtfsCommonWrite+0xef3
eb42f89c 8041f511 82080020 bea49e90 81d17b00 Ntfs!NtfsFsdWrite+0xf0
eb42f8b0 f2947c07 81d17b00 00020000 81d17b00 nt!IopfCallDriver+0x35
eb42f904 f2942c10 81cb6e08 82080020 e2bdb020 MyDrv! WriteFile+0x270
eb42f9dc f294259c f2a7f000 bea43e70 82080020 MyDrv! CopyFileBlock+0x40e
eb42fa14 f2941874 f2a7f000 bea43e70 eb42fa98 MyDrv! OnFileRead+0x9c
eb42fa48 f2948b2c 81cb7768 f2a7f000 bea43e70 MyDrv! OnFileRead+0x84
eb42fa68 f294cfb6 81cb7768 f2a7f000 bea43e70 MyDrv! OnFileRead+0x2c
eb42fabc f29483ce bea43e70 81cb7768 82080020 MyDrv! OnRead+0x180
eb42fb08 f29433b6 bea43e70 81d17b00 bea43e70 MyDrv! Read+0xc9
eb42fb5c f294317c 81d17b00 bea43e70 eb42fb94 MyDrv! DispatchIRP+0x17c
eb42fb6c 8041f511 81d17b00 bea43e70 81cb6e08 MyDrv!
MainIRPDispatcher+0x1c
eb42fb80 80420856 00000000 00000000 80064bc4 nt!IopfCallDriver+0x35
eb42fb94 8043f7cb 81cb6e08 81d0bf80 81d0bf60 nt!IoPageRead+0xb1
eb42fbd4 8044824a 00000000 d3411000 c034d044 nt!MiDispatchFault+0x23d
eb42fc20 804454a8 00000000 00000000 00000000 nt!MmAccessFault+0x67b
eb42fc50 8040f51f d3411000 00000000 80473720
nt!MmCheckCachedPageState+0x28e
eb42fd0c 80414d7f 820ab088 8046afc0 820ad620
nt!CcPerformReadAhead+0x204
eb42fd78 80418b41 820ab088 00000000 00000000 nt!CcWorkerThread+0x141
eb42fda8 8045336a 820ab088 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000
nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

MyDrv is my driver that intersepts IRP_MJ_READ and before satisfying that
read
it writes to the same location and the same amount of bytes using the same
Irp->Flags as were found in the original IRP. To write I roll my own IRP
using
IoBuildAsynchronousFsdRequest.

TIA,

Vladimir

OSR_Community_User · April 12, 2002, 8:42pm

Oops… The resource this thread holds is actually mine and it causes (what
appears to be) a deadlock…
There is another thread waiting for that resource to be acquired and that’s
it. There are no more locks
reported (!locks in WinDgb).

Thanks again,

Vladimir

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@starbase.com]
Sent: Friday, April 12, 2002 5:23 PM
To: File Systems Developers
Subject: [ntfsd] What’s NtfsWaitForIoAtEof waits for?

It seems to hang forever on a resource. Can anybody give me an idea of
what’s going on there?
Here is the thread stack I’ve got from WinDbg (W2K):

Resource @ 0x81cbd9e8 Exclusively owned
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 820ad620-01

THREAD 820ad620 Cid 8.18 Teb: 00000000 Win32Thread: 00000000 WAIT:
(Executive) KernelMode Non-Alertable
eb42f800 NotificationEvent
Not impersonating
Owning Process 820ae8a0
WaitTime (seconds) 8134
Context Switch Count 757
UserTime 0:00:00.0000
KernelTime 0:00:00.0062
Start Address nt!ExpWorkerThread (0x80418a7c)
Stack Init eb430000 Current eb42f44c Base eb430000 Limit eb42d000 Call
0
Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
eb42f464 8042d774 e2b925b8 eb42f7f8 00000000 nt!KiSwapThread+0xc5
eb42f48c bff0b262 eb42f800 00000000 00000000
nt!KeWaitForSingleObject+0x1a1
eb42f4b4 bfef04ea e2b925b8 eb42f7c4 0000f000
Ntfs!NtfsWaitForIoAtEof+0x43
eb42f830 bfedf63f 81cb4ee8 bea49e90 00000000 Ntfs!NtfsCommonWrite+0xef3

eb42f89c 8041f511 82080020 bea49e90 81d17b00 Ntfs!NtfsFsdWrite+0xf0
eb42f8b0 f2947c07 81d17b00 00020000 81d17b00 nt!IopfCallDriver+0x35
eb42f904 f2942c10 81cb6e08 82080020 e2bdb020 MyDrv! WriteFile+0x270
eb42f9dc f294259c f2a7f000 bea43e70 82080020 MyDrv! CopyFileBlock+0x40e

eb42fa14 f2941874 f2a7f000 bea43e70 eb42fa98 MyDrv! OnFileRead+0x9c
eb42fa48 f2948b2c 81cb7768 f2a7f000 bea43e70 MyDrv! OnFileRead+0x84
eb42fa68 f294cfb6 81cb7768 f2a7f000 bea43e70 MyDrv! OnFileRead+0x2c
eb42fabc f29483ce bea43e70 81cb7768 82080020 MyDrv! OnRead+0x180
eb42fb08 f29433b6 bea43e70 81d17b00 bea43e70 MyDrv! Read+0xc9
eb42fb5c f294317c 81d17b00 bea43e70 eb42fb94 MyDrv! DispatchIRP+0x17c
eb42fb6c 8041f511 81d17b00 bea43e70 81cb6e08 MyDrv!
MainIRPDispatcher+0x1c
eb42fb80 80420856 00000000 00000000 80064bc4 nt!IopfCallDriver+0x35
eb42fb94 8043f7cb 81cb6e08 81d0bf80 81d0bf60 nt!IoPageRead+0xb1
eb42fbd4 8044824a 00000000 d3411000 c034d044 nt!MiDispatchFault+0x23d
eb42fc20 804454a8 00000000 00000000 00000000 nt!MmAccessFault+0x67b
eb42fc50 8040f51f d3411000 00000000 80473720
nt!MmCheckCachedPageState+0x28e
eb42fd0c 80414d7f 820ab088 8046afc0 820ad620
nt!CcPerformReadAhead+0x204
eb42fd78 80418b41 820ab088 00000000 00000000 nt!CcWorkerThread+0x141
eb42fda8 8045336a 820ab088 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000
nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

MyDrv is my driver that intersepts IRP_MJ_READ and before satisfying that
read
it writes to the same location and the same amount of bytes using the same
Irp->Flags as were found in the original IRP. To write I roll my own IRP
using
IoBuildAsynchronousFsdRequest.

TIA,

Vladimir

You are currently subscribed to ntfsd as: xxxxx@Starbase.com
To unsubscribe send a blank email to %%email.unsub%%

OSR_Community_User · April 15, 2002, 10:10am

Please include the stack for the other thread if this is a common deadlock scenario for filters?

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@starbase.com]
Sent: Friday, April 12, 2002 7:31 PM
To: File Systems Developers
Subject: [ntfsd] RE: What’s NtfsWaitForIoAtEof waits for?

Oops… The resource this thread holds is actually mine and it causes (what appears to be) a deadlock…
There is another thread waiting for that resource to be acquired and that’s it. There are no more locks
reported (!locks in WinDgb).

Thanks again,

Vladimir

-----Original Message-----
From: Chtchetkine, Vladimir [mailto:xxxxx@starbase.com]
Sent: Friday, April 12, 2002 5:23 PM
To: File Systems Developers
Subject: [ntfsd] What’s NtfsWaitForIoAtEof waits for?

It seems to hang forever on a resource. Can anybody give me an idea of what’s going on there?
Here is the thread stack I’ve got from WinDbg (W2K):

Resource @ 0x81cbd9e8 Exclusively owned
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 820ad620-01

THREAD 820ad620 Cid 8.18 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
eb42f800 NotificationEvent
Not impersonating
Owning Process 820ae8a0
WaitTime (seconds) 8134
Context Switch Count 757
UserTime 0:00:00.0000
KernelTime 0:00:00.0062
Start Address nt!ExpWorkerThread (0x80418a7c)
Stack Init eb430000 Current eb42f44c Base eb430000 Limit eb42d000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
eb42f464 8042d774 e2b925b8 eb42f7f8 00000000 nt!KiSwapThread+0xc5
eb42f48c bff0b262 eb42f800 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
eb42f4b4 bfef04ea e2b925b8 eb42f7c4 0000f000 Ntfs!NtfsWaitForIoAtEof+0x43
eb42f830 bfedf63f 81cb4ee8 bea49e90 00000000 Ntfs!NtfsCommonWrite+0xef3
eb42f89c 8041f511 82080020 bea49e90 81d17b00 Ntfs!NtfsFsdWrite+0xf0
eb42f8b0 f2947c07 81d17b00 00020000 81d17b00 nt!IopfCallDriver+0x35
eb42f904 f2942c10 81cb6e08 82080020 e2bdb020 MyDrv! WriteFile+0x270
eb42f9dc f294259c f2a7f000 bea43e70 82080020 MyDrv! CopyFileBlock+0x40e
eb42fa14 f2941874 f2a7f000 bea43e70 eb42fa98 MyDrv! OnFileRead+0x9c
eb42fa48 f2948b2c 81cb7768 f2a7f000 bea43e70 MyDrv! OnFileRead+0x84
eb42fa68 f294cfb6 81cb7768 f2a7f000 bea43e70 MyDrv! OnFileRead+0x2c
eb42fabc f29483ce bea43e70 81cb7768 82080020 MyDrv! OnRead+0x180
eb42fb08 f29433b6 bea43e70 81d17b00 bea43e70 MyDrv! Read+0xc9
eb42fb5c f294317c 81d17b00 bea43e70 eb42fb94 MyDrv! DispatchIRP+0x17c
eb42fb6c 8041f511 81d17b00 bea43e70 81cb6e08 MyDrv! MainIRPDispatcher+0x1c
eb42fb80 80420856 00000000 00000000 80064bc4 nt!IopfCallDriver+0x35
eb42fb94 8043f7cb 81cb6e08 81d0bf80 81d0bf60 nt!IoPageRead+0xb1
eb42fbd4 8044824a 00000000 d3411000 c034d044 nt!MiDispatchFault+0x23d
eb42fc20 804454a8 00000000 00000000 00000000 nt!MmAccessFault+0x67b
eb42fc50 8040f51f d3411000 00000000 80473720 nt!MmCheckCachedPageState+0x28e
eb42fd0c 80414d7f 820ab088 8046afc0 820ad620 nt!CcPerformReadAhead+0x204
eb42fd78 80418b41 820ab088 00000000 00000000 nt!CcWorkerThread+0x141
eb42fda8 8045336a 820ab088 00000000 00000000 nt!ExpWorkerThread+0xae
eb42fddc 804671c2 80418a7c 00000000 00000000 nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

MyDrv is my driver that intersepts IRP_MJ_READ and before satisfying that read
it writes to the same location and the same amount of bytes using the same
Irp->Flags as were found in the original IRP. To write I roll my own IRP using
IoBuildAsynchronousFsdRequest.

TIA,

Vladimir

You are currently subscribed to ntfsd as: xxxxx@Starbase.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntfsd as: xxxxx@inin.com
To unsubscribe send a blank email to %%email.unsub%%

OSR_Community_User · April 15, 2002, 10:35am

There was another thread accessing same file (READ) and blocked on my
driver’s resource (I have serialized access to the file for
simplicity of the prototype). So, if you “cut” stack trace that I’ve
provided at “MyDrv! CopyFileBlock” line you will have stack trace
for another thread.
There was another resource held (as !locks reported) but the thread that
owns this resource appears to be invalid. Besides, I always
see this lock with an invalid thread in the !locks list, so I didn’t pay
much attention to this fact ('cause I can’t get anything usefull from
it anyway).
Besides that, there were no more locks reported.
Another interesting thing is that sometimes MmFlushImageSection and/or
CcPurgeCacheSection takes minutes to complete even on
relatively small (2-3MB) execuatble files after their executions has been
completed.
What the heck did I touch?

Regards,

Vladimir

-----Original Message-----
From: Fuller, Rob [mailto:xxxxx@inin.com]
Sent: Monday, April 15, 2002 7:08 AM
To: File Systems Developers
Subject: [ntfsd] RE: What’s NtfsWaitForIoAtEof waits for?

Please include the stack for the other thread if this is a common deadlock
scenario for filters?