Micah,
Surely this helps the stack, but doesn’t this cause more difficulties in the
case of create file? Some arbitrary system thread context gets used to open
a file. What happens when this thread/process terminates? Or can we rely on
that not happening? Won’t the I/O Manager close the open handles at that
point, and won’t the file system dump the file object without warning,
leaving the poor driver with a tricky problem to debug? Can we indeed even
access the file object from a different context? Is it enough to lock the
object down with an ObReference?
Its been a while for me, maybe I’m worrying about nothing, but I’d like to
be sure of that one, if anybody cares to clarify.
Thanx,
Jack.
“Micah Brodsky” wrote in message news:xxxxx@ntdev…
> If you’re running out of stack space or otherwise can’t use your current
> thread context to do what you need, a good trick is to punt off to a work
> item. Set up a work item with IoAllocateWorkItem or suchlike and queue it
> with parameters indicating how to pick up where your current thread left
> off. If you’re at IRQL < DISPATCH_LEVEL, you can set up an event and wait
> until your work item is finished, and this more or less amounts to a
> manually initiated context switch to a free worker thread with plenty of
> stack to do your bidding.
>
> --Micah Brodsky
>
>
>
> “Anurag Sarin” wrote in message
> news:xxxxx@ntdev…
> Mark,
>
> I suppose “Calling createfile inline in the write path is probably not a
> good idea” because of Re-entrancy reasons , hence giving recursion. Am I
> right ?
>
> So what can be an alternative for ZwCreateFile and ZwWriteFile to be
> called in Write dispatch routine ?
>
> Also for knowledge : from the stack trace below , how to find out that I
> am in 4 Stage of recursion. As there are FileSpy functions but are
> different function , how to know that the same function is been called 4
> times… ???
>
> Thanks
> Anurag
>
>
>
>
>