Given that this is a page fault, is it possible that maybe you have the
address on which it is faulting? For instance, if this is a fault in some
kernel address you have one sort of problem (memory that has been freed, for
instance.) If this is a fault in some user address (hmm, like something
very close to zero) you could have a NULL pointer dereference or
uninitialized variable.
Of course, without having access to the code it is hard to look for what
could easily be a detail of the implementation type error. I presume you’ve
checked for obvious things (like setting
IoGetCurrentIrpStackLocation(Irp)->FileObject, which is not done by
IoBuildSynchronousFsdRequest, since the latter routine is used by an FSD to
call a storage driver and is thus normally superfluous…)
Best of luck - trying to debug problems like this via general descriptions
is (in my experience) a tough thing for this group (or anyone, really) to
accomplish.
Regards,
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
From: Neil Weicher [mailto:xxxxx@netlib.com]
Sent: Friday, March 10, 2000 8:16 PM
To: File Systems Developers
Subject: [ntfsd] page fault from synchronous FSD request in Create
Completion routine
A file filter driver is getting a page fault at CcFlushCache+1A2h as a
result
of a synchronous read request in the Completion routine of an IRP_MJ_CREATE
hander.
It seems to be going by the book with and has been checked over and over
again. It basically does:
KeInitializeEvent
IoBuildSynchronousFsdRequest
IoGetNextIrpStackLocation
IoCallDriver
KeWaitForSingleObject
The routines as always return STATUS_SUCCESS and it definitely has the
correct
values for the driver, file objects, irp, etc.
Does anyone have any experience with this and/or any any suggestions as to
what to
look for?
Thanks.
Neil
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)