Id say is somewhere in IRP_MJ_WRITE path. notice that this happen when
NtWriteFile
does IRP postprocessing / phase 2 (in context) IO completion.
nt!IopCompleteRequest –> in context IO
completion handling
nt!IopSynchronousServiceTail –> synch IO postprocessing
nt!NtWriteFile –> normal IO
It should be easy to identify the path folowed by the IRP in your FS in this
situation.
Dan
----- Original Message -----
From: “James Dunning”
To: “File Systems Developers”
Sent: Tuesday, September 03, 2002 3:27 PM
Subject: [ntfsd] Re: How to route the source of the Special pool detec ted
memory corruption?
> Thanks Dan,
>
> If this is the case, and that my driver is mishandling an IRP, how do I go
> about locating this mishandled IRP?
>
> Is it possible to determine which IRP’s were active prior to the crash
from
> analysing the stack backtrace?
>
> Regards,
> James Dunning
>
>
> -----Original Message-----
> From: Dan Partelly [mailto:xxxxx@rdsor.ro]
> Sent: 03 September 2002 12:09
> To: File Systems Developers
> Subject: [ntfsd] Re: How to route the source of the Special pool
> detected memory corru ption?
>
>
> James,
>
> Most likely you are facing a situation where your code corrupts memory
> through IRP
> mishandling. The stack trace shows that the driver verifyer catch this
error
> while
> validating the coherency of an IRP, at free Irp time. By checking the IRP
> you can pinpoint
> the routines in yuor driver which handled it, and check them for incorrect
> handling.
>
> Ciao, Dan
>
>
> General Dynamics United Kingdom Limited
> Registered in England and Wales No. 1911653
> Registered Office: 100 New Bridge Street, London, EC4V 6JA
>
>
> —
> You are currently subscribed to ntfsd as: xxxxx@rdsor.ro
> To unsubscribe send a blank email to %%email.unsub%%
>