how to distinguish the mmaped file

I’m writing a filter driver, and need to know
whether the file is memory mapped.

I saw the flag FSRTL_FLAG_USER_MAPPED_FILE indicated the file
had been memory mapped, but never seen it is unset again after
the mapped handle was closed.

Is there any way to distinguish the file is currently mapped or not.

Thanks,

mori

> I’m writing a filter driver, and need to know

whether the file is memory mapped.

I saw the flag FSRTL_FLAG_USER_MAPPED_FILE indicated the file
had been memory mapped, but never seen it is unset again after
the mapped handle was closed.

Is there any way to distinguish the file is currently mapped or not.

Try:

  • take the MainResource exclusively
  • check the SectionObjectPointer fields to be non-NULL.
  • release the lock.
    Maybe this will help.

Max

xxxxx@storagecraft.com writes:

> I’m writing a filter driver, and need to know
> whether the file is memory mapped.
>
> I saw the flag FSRTL_FLAG_USER_MAPPED_FILE indicated the file
> had been memory mapped, but never seen it is unset again after
> the mapped handle was closed.
>
> Is there any way to distinguish the file is currently mapped or not.

Try:

  • take the MainResource exclusively
  • check the SectionObjectPointer fields to be non-NULL.
  • release the lock.
    Maybe this will help.

Max

Thank you for your hint.

But, I’d like to know whether file is mapped by an application
through CreateFileMapping() or so.

Regardless of user mapping,
SectionObjectPointer is almost always set after IRP_MJ_CREATE succeed,
DataSectionObject is also set once cache has begun by cache manager.

BTW, is it legal taking MainResource lock by the filter driver?

mori

> But, I’d like to know whether file is mapped by an application

through CreateFileMapping() or so.

Regardless of user mapping,
SectionObjectPointer is almost always set after IRP_MJ_CREATE succeed,
DataSectionObject is also set once cache has begun by cache manager.

Then FSRTL_FLAG_USER_MAPPED_FILE can be the only way (except rev.eng. ing a
good deal of MM and dealing with its internal structures).

BTW, is it legal taking MainResource lock by the filter driver?

If this is a top level IRP (thread->TopLevelrp is NULL) - why not?
If this is NOT a top level IRP - then it is illegal, since the FSD have
already acquired it for this operation and another acquisition (from FSP
thread, for instance) can cause deadlock.

Max

xxxxx@storagecraft.com writes:

> But, I’d like to know whether file is mapped by an application
> through CreateFileMapping() or so.
>
> Regardless of user mapping,
> SectionObjectPointer is almost always set after IRP_MJ_CREATE succeed,
> DataSectionObject is also set once cache has begun by cache manager.

Then FSRTL_FLAG_USER_MAPPED_FILE can be the only way (except rev.eng. ing a
good deal of MM and dealing with its internal structures).

As I haven’t seen FSRTL_FLAG_USER_MAPPED_FILE was unset
after all user mapping had finished, it’s useless in my case.

> BTW, is it legal taking MainResource lock by the filter driver?

If this is a top level IRP (thread->TopLevelrp is NULL) - why not?
If this is NOT a top level IRP - then it is illegal, since the FSD have
already acquired it for this operation and another acquisition (from FSP
thread, for instance) can cause deadlock.

Then, I’ll try to take MainResource, and ask VMM with MmCanFileBeTruncated().
How do you think it works?

Thanks, Best regard,

mori