Jonathan,
STATUS_CANT_WAIT is used internally in NTFS to post the request. There
are a number of reasons this can happen - and even in the create path,
NTFS still serializes its internal operations and that can lead to
interesting (internal) lock conditions.
You can’t know. This is an internal matter within the file system;
there is nothing you can do outside of the file system to cause or
prevent this condition from arising in a systematic way (the conditions
under which this occurs could easily change over time).
What is more likely is that something in your filter is causing
excessive stack consumption and THAT is causing what would normally be a
successful posting operation to fail.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jonathan Ludwig
Sent: Tuesday, December 14, 2004 2:10 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Re:Why is Ntfs calling ExRaiseStatus with
STATUS_CANT_WAIT on a create Irp I pass to it?
Tony,
I’m still a little wet behind the ears on this stuff. This is a create
so
the file object is new and the FsContext is NULL. Why would their be a
lock
problem? What can my filter do in this situation?
I guess what I need to understand is how do I determine that this
request
will cause NTFS to assert and how do I handle the situation? I know
that
the IRP has the IRP_SYNCHRONOUS_API flag is set, but how do I know if
NTFS
can wait or not?
The other questions is, what is my fliter driver doing that causes NTFS
to
respond to this request this way?
Thanks for the help. If you can point me in the right place for
documentation on this, that would be helpful.
Thanks,
Jonathan
“Tony Mason” wrote in message news:xxxxx@ntfsd…
STATUS_CANT_WAIT arises in a number of cases, generally related to locks
that cannot be immediately acquired. In that case, the caller generally
needs to post the work to a separate thread where the locks CAN be
acquired in correct order and blocked for in a safe fashion.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
Looking forward to seeing you at the Next OSR File Systems Class April
4, 2004 in Boston!
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jonathan Ludwig
Sent: Tuesday, December 14, 2004 12:33 PM
To: ntfsd redirect
Subject: Re:[ntfsd] Re:Re:Why is Ntfs calling ExRaiseStatus with
STATUS_CANT_WAIT on a create Irp I pass to it?
I’m not really to concerned why I’m getting a double fault. I just
wanted
to see if someone knows why Ntfs is calling ExRaiseStatus with
STATUS_CANT_WAIT.
Jonathan
“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
> Probably ExRaiseStatus causes stack overflow.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
> ----- Original Message -----
> From: “Jonathan Ludwig”
> Newsgroups: ntfsd
> To: “Windows File Systems Devs Interest List”
> Sent: Thursday, December 09, 2004 1:19 AM
> Subject: Re:[ntfsd] Re:Why is Ntfs calling ExRaiseStatus with
> STATUS_CANT_WAIT
> on a create Irp I pass to it?
>
>
>> Would Ntfs explicitly call ExRaiseStatus via NtfsRaiseStatus in this
>> situation?
>>
>> “Maxim S. Shatskih” wrote in message
>> news:xxxxx@ntfsd…
>> > Kernel stack overflow.
>> > Nearly for sure.
>> >
>> > Maxim Shatskih, Windows DDK MVP
>> > StorageCraft Corporation
>> > xxxxx@storagecraft.com
>> > http://www.storagecraft.com
>> >
>> > ----- Original Message -----
>> > From: “Jonathan Ludwig”
>> > Newsgroups: ntfsd
>> > To: “Windows File Systems Devs Interest List”
>> > Sent: Wednesday, December 08, 2004 11:57 PM
>> > Subject: Re:[ntfsd] Why is Ntfs calling ExRaiseStatus with
>> > STATUS_CANT_WAIT on
>> > a create Irp I pass to it?
>> >
>> >
>> >> Sorry, this is not getting a double fault bug check but an
>> >> UNEXPECTED_KERNEL_MODE_TRAP (7f) bug check of type double fault.
>> >>
>> >> Here is the file object:
>> >> 1: kd> dt -b nt!_FILE_OBJECT 8555dc48
>> >> +0x000 Type : 5
>> >> +0x002 Size : 112
>> >> +0x004 DeviceObject : 0x85ddc5d0
>> >> +0x008 Vpb : (null)
>> >> +0x00c FsContext : (null)
>> >> +0x010 FsContext2 : (null)
>> >> +0x014 SectionObjectPointer : (null)
>> >> +0x018 PrivateCacheMap : (null)
>> >> +0x01c FinalStatus : 0
>> >> +0x020 RelatedFileObject : (null)
>> >> +0x024 LockOperation : 0 ‘’
>> >> +0x025 DeletePending : 0 ‘’
>> >> +0x026 ReadAccess : 0 ‘’
>> >> +0x027 WriteAccess : 0 ‘’
>> >> +0x028 DeleteAccess : 0 ‘’
>> >> +0x029 SharedRead : 0 ‘’
>> >> +0x02a SharedWrite : 0 ‘’
>> >> +0x02b SharedDelete : 0 ‘’
>> >> +0x02c Flags : 0
>> >> +0x030 FileName : “\WINNT\System32\RDPDD.dll”
>> >> +0x000 Length : 0x32
>> >> +0x002 MaximumLength : 0x38
>> >> +0x004 Buffer : 0xe2e6fee8 “\WINNT\System32\RDPDD.dll”
>> >> +0x038 CurrentByteOffset : 0x0
>> >> +0x000 LowPart : 0
>> >> +0x004 HighPart : 0
>> >> +0x000 u :
>> >> +0x000 LowPart : 0
>> >> +0x004 HighPart : 0
>> >> +0x000 QuadPart : 0
>> >> +0x040 Waiters : 0
>> >> +0x044 Busy : 0
>> >> +0x048 LastLock : (null)
>> >> +0x04c Lock :
>> >> +0x000 Header :
>> >> +0x000 Type : 0 ‘’
>> >> +0x001 Absolute : 0 ‘’
>> >> +0x002 Size : 0 ‘’
>> >> +0x003 Inserted : 0 ‘’
>> >> +0x004 SignalState : 0
>> >> +0x008 WaitListHead : [0x0 - 0x0]
>> >> +0x000 Flink : (null)
>> >> +0x004 Blink : (null)
>> >> +0x05c Event :
>> >> +0x000 Header :
>> >> +0x000 Type : 0 ‘’
>> >> +0x001 Absolute : 0 ‘’
>> >> +0x002 Size : 0x4 ‘’
>> >> +0x003 Inserted : 0 ‘’
>> >> +0x004 SignalState : 0
>> >> +0x008 WaitListHead : [0x8555dcac - 0x8555dcac]
>> >> +0x000 Flink : 0x8555dcac
>> >> +0x004 Blink : 0x8555dcac
>> >> +0x06c CompletionContext : (null)
>> >>
>> >> “Jonathan Ludwig” wrote in message
>> >> news:xxxxx@ntfsd…
>> >> >I have a file system filter. Does anyone know why Ntfs calls
>> >> >ExRaiseStatus
>> >> >with STATUS_CANT_WAIT when I pass a synchronous create Irp down
to
>> >> >it?
>> >> >
>> >> > Here is the Irp:
>> >> >
>> >> > 1: kd> !irp 854239c8 1
>> >> > Irp is active with 14 stacks 11 is current (= 0x85423ba0)
>> >> > No Mdl Thread 85484700: Irp stack trace.
>> >> > Flags = 00000884
>> >> > ThreadListEntry.Flink = 85424b18
>> >> > ThreadListEntry.Blink = 8548490c
>> >> > IoStatus.Status = 00000000
>> >> > IoStatus.Information = 00000000
>> >> > RequestorMode = 00000000
>> >> > Cancel = 00
>> >> > CancelIrql = 0
>> >> > ApcEnvironment = 00
>> >> > UserIosb = f0038f90
>> >> > UserEvent = 00000000
>> >> > Overlay.AsynchronousParameters.UserApcRoutine = 00000000
>> >> > Overlay.AsynchronousParameters.UserApcContext = 00000000
>> >> > Overlay.AllocationSize = 00000000 - 00000000
>> >> > CancelRoutine = 00000000
>> >> > UserBuffer = 00000000
>> >> > &Tail.Overlay.DeviceQueueEntry = 00e1cf3c
>> >> > Tail.Overlay.Thread = 85484700
>> >> > Tail.Overlay.AuxiliaryBuffer = 00000000
>> >> > Tail.Overlay.ListEntry.Flink = 00000000
>> >> > Tail.Overlay.ListEntry.Blink = 00000000
>> >> > Tail.Overlay.CurrentStackLocation = 85423ba0
>> >> > Tail.Overlay.OriginalFileObject = 8555dc48
>> >> > Tail.Apc = 00000000
>> >> > Tail.CompletionKey = 00000000
>> >> > cmd flg cl Device File Completion-Context
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> > [0, 0] 0 0 00000000 00000000 00000000-00000000
>> >> > Args: 00000000 00000000 00000000 00000000
>> >> >>[0, 0] 0 e0 85cf4020 8555dc48 f7461c02-f0038c28 Success Error
>> >> >>Cancel
>> >> > \FileSystem\Ntfs Ntfs!NtfsCreateCompletionRoutine
>> >> > Args: f0038fd0 01000000 00070000 00000000
>> >> > [0, 0] 0 e0 85cf4020 8555dc48 f74d1fc2-85d40a78 Success Error
>> >> > Cancel
>> >> > \FileSystem\Ntfs SymSnap!SymSnapIrpCompletion
>> >> > Args: f0038fd0 01000000 00070000 00000000
>> >> > [0, 0] 0 e0 85d409c0 8555dc48 efc741b3-f0038df8 Success Error
>> >> > Cancel
>> >> > \FileSystem\SymSnap SYMEVENT
>> >> > Args: f0038fd0 01000000 00070000 00000000
>> >> > [0, 0] 0 0 85499f00 8555dc48 00000000-00000000
>> >> > \Driver\SymEvent
>> >> > Args: f0038fd0 01000000 00070000 00000000
>> >> >
>> >> > I actually get a double fault bug check. I assume this means
the
>> >> > system
>> >> > was handling a page fault at the time.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Jonathan
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> —
>> >> Questions? First check the IFS FAQ at
>> > https://www.osronline.com/article.cfm?id=17
>> >>
>> >> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> >> To unsubscribe send a blank email to xxxxx@lists.osr.com
>> >>
>> >
>> >
>>
>>
>>
>> —
>> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>>
>> You are currently subscribed to ntfsd as: xxxxx@storagecraft.com
>> To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>
>
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com