Re: Question about FILE_OBJECT

Hi mate

NDIS IM is a driver that fully conforms to the model, defined by MSFT
for intermediate NDIS drivers. One of these requirements is that it has
to register itself as miniport driver with NDIS library. Any driver
that does so cannot expose regular Dispatch interface, for the simple
reason that miniport driver's functions are not supposed to be called
by anyone,apart from NDIS library. Opening file handle requires
IRP_MJ_CREATE's handler. Therefore, you cannot open a handle on NDIS
IM.

Apart from this, NDIS IM may pose quite a few other problems. For
example, NDIS IM often
fails with virtual adapters. In order to avoid all these troubles, you
can hook NDIS calls, instead of writing NDIS IM. From the logical
standpoint, NDIS-hooking driver exposes all functionality of NDIS IM,
but is much more flexible. This is what PCAUSA samples are all about -
these are NDIS-hooking samples, rather than NDIS IM drivers. In fact,
NDIS hooking is, apparently, the only "unsupported technology" that is
much more reliable than its "officially supported" functional
equivalent (i.e. NDIS IM). In other words, you chose absolutely right
approach to the problem you have to solve.

Your driver relies upon NDIS hooking, so that it can expose any
interface it likes. Once it does not register itself as miniport
driver, you can open handles on it. However, in your original post you
said that your driver is NDIS IM, which lead to misunderstanding


Anton Bassov


John S wrote:
I think your missing something First the driver is an ndis intermediate
driver, pcausa does have other packages that are not intermediate drivers
though. Regardless of, my driver creates an object which can be opened in
user mode (via CreateFile) and requests can be made. When the user mode
opens up a the object, a file handle is opened and IRP_MJ_CREATE is issued.
However It doesnt matter that this driver is an ndis intermediate driver or
not. This question has nothing to do w/ ndis at all it was just a reference
point on what i was doing, which is why i didnt go into specifics on it.
The question just has to do w/ the PFILE_OBJECT passed in on irp
IRP_MJ_CREATE and susequent ioctl/irp's for any driver object in general.

John.

"anton bassov" wrote:

Hi mate

This came about
because I was making some vista compatibility changes to our PCAUSA based
intermediate driver......

This is what you should have said from the very, very beginning.
However, originally you mentioned "NDIS IM". PCAUSA - based driver is
DEFINITELY not NDIS IM. If you have formulated your question properly,
I would have no need to explain to you that you cannot
open FILE_OBJECT on NDIS IM. Instead, I would have answered the
question that you had asked

Anton Bassov




John S wrote:
Yeah, I completely agree that would be the best way to doit. Unfortunetly I
would say I'm almost scared to make that large of a change. This came about
because I was making some vista compatibility changes to our PCAUSA based
intermediate driver and realized that the mapping they had been using was a
simple dword index, I.E. every time they allocated a new context object they
increased the value of a global variable by 1, store it in the context
object, and store it in FsContext2 and used that to map it back. Heck they
didnt even use an incremental update on the global variable, just a straight
old ++g_nNextOpenRefnum;. In the current code, FsContext, points to a
context object that is allocated per adapter, and then FsContext2 is looked
up in the per adapters binding list. I mean technically i could probably
changed the current ++g_nNextOpenRefNum to an incremental update and hope
that no one ever opens ... 0xFFFFFFFF instances of a this thing, but that
kind of scares me. I dont want to make drastic changes to the driver either
though. This will be going out fairly large customers and will have a high
distribution rate... So i have been trying to minimize the changes for the
simple purpose of minimizing bugs. Since there is no room for error.

"Doron Holan [MS]" wrote:

intead of allocating/freeing the context in FsContext2 on the IOCTL calls,
create a context in create and freed in close and have this context contain
the list of contexts that you allocate on an IOCTL basis. this way, the
structure of your data is localized per file object and can track better.

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.


"John S" <JohnS@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8599DBA8-6ECC-468E-9AEC-35D5D76F9543@xxxxxxxxxxxxxxxx
Ok so if i understand correctly the PFILE_OBJECT ptr for that handle will
always be the same. I.E. when subsequent ioctl's are made.

In my actual code the context object stored in FsContext2 is allocated and
stored on an ioctl that comes after the IRP_MJ_CREATE and can be freed on
IRP_MJ_CLOSE or prior to that via another ioctl code that my driver
handles.

My major concern was that somehow the location of the PFILE_OBJECT would
change and my validation of the context object would fail even though the
context object actually belonged to that file object.

Just an FYI the reason im storing the ptr of the PFILE_OBJECT in the
context
object is because i know its possible for the system to re-use that memory
location (after i have freed the original context object) when i allocate
another context object. So just making sure the value pointed to by
FsContext2 is in my table only lets me know that the memory is valid, not
that it actually belongs to the PFILE_OBJECT. By also checking to see
that
stored PFILE_OBJECT ptr in my context object matches the PFILE_OBJECT of
the
current irp then i am certain that the context object is not only valid
memory, but that the context object is actually associated w/ that
PFILE_OBJECT.

"Doron Holan [MS]" wrote:

the use of FsContext and FsContext2 are dictated by each driver in the
stack. you must make sure that no other driver (like NDIS itself) is
using
these fields. Once you know that you can use either field, you can set
it
and you own own. you don't have to validate it unless you are freeing it
before IRP_MJ_CLOSE, you can blindly use the pointer b/c no one else
knows
about it. Every i/o that is sent on that handle will have the same
PFILE_OBJECT pointer and the same pointer value you put into
FsContext(2).

d

--
Please do not send e-mail directly to this alias. this alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no
rights.


"John S" <John S@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0EFAF252-02EC-4550-BD0E-0B2030CD5435@xxxxxxxxxxxxxxxx
Ok, here is the scenario. I have an ndis intermetiate driver.
Basically a
new handle to my intermdiate driver is opened for each nic adapter that
a
user application wants to talk to.

On the open call (IRP_MJ_CREATE) I allocate a context structure and add
it
to a global list. I also store the pointer of the allocated context
memory
in IoGetCurrentIrpStackLocation(pIrp)->FileObject->FsContext2; I also
want
to save the pointer of the FileObject to a member in the the context
structure I allocated. Note that i will never attempt to read or write
to
the location i will just be using it later for validation.

Now, on susequent irp's instead of accessing the context memory at
FileObject->FsContext2 object directly, I want to use FsContext2 to
match
the
context structure in my global list (to assure that its valid). When
i
find i match i also want to make sure the FileObject pointer i stored
in
the
context memory matches the pointer to FileObject of the current irp.

So my question is.. Will a FILE_OBJECT change memory locations? I.E.
whence a file object is established, is it always found at that
location,
or can the os re-allocate and copy it to another memory location.

I know that this is probably a ridiculous amount of verification but
the
situation is a little more complicated than stated above, it's just
easier
to explain this way.
John.












.

Relevant Pages

  • Re: Question about FILE_OBJECT
    ... I think your missing something First the driver is an ndis intermediate ... I.E. every time they allocated a new context object they ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Problem with matching kind of NDIS driver.
    ... When it comes to outgoing packets, the reasons why his task is infeasible ... context of different threads. ... NDIS IM filter that is located immediately below ... We are telling you that in a NDIS Intermediate driver the process ...
    (microsoft.public.development.device.drivers)
  • Re: User vs. Worker threads
    ... is shut down or the thread terminates itself by calling ... Driver routines that run in a process context other than that of the system ... It has all the worker threads. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Running NDISTest on Vista with an NDIS IM Driver
    ... I had a quick look at the ndistest stuff in the WLK1.0c, ... actually some ndis driver in the ... I tried using the version that comes with WLK/DTM on PassThru (NDIS IM ...
    (microsoft.public.development.device.drivers)
  • Re: NDIS functionality details
    ... In my driver I need to decompress compressed video data and provide ... >> NDIS subsystem exports a lot of functions with Ndis* prefix. ... >> DDK says, that there is two ways, one is to copy each packet to driver ...
    (microsoft.public.development.device.drivers)