IIRC, when this bugcheck comes to life, the memory is not yet returned back
to the special pool . So you have a chanche to examine the IRP and see where
it was targeted, more relvant data, and so on.
Dan
----- Original Message -----
From: “James Dunning”
To: “File Systems Developers”
Sent: Thursday, September 05, 2002 10:58 AM
Subject: [ntfsd] Re: How to route the source of the Special pool detec ted
memory corruption?
> Thats what i thought when i looked at the stack backtrace, it only becomes
> confusing due to the fact that the IRP_MJ_WRITE is not even implemented on
> my Filesystem Driver.
>
> Regards
> James
>
> -----Original Message-----
> From: Dan Partelly [mailto:xxxxx@rdsor.ro]
> Sent: 03 September 2002 15:29
> To: File Systems Developers
> Subject: [ntfsd] Re: How to route the source of the Special pool detec
> ted memory corruption?
>
>
> 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%%
> >
>
>
>
> —
> You are currently subscribed to ntfsd as:
> xxxxx@generaldynamics.uk.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
> 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%%
>