Hi, Prokash:
If you need accurate info on executable images open handle count, you may
have no choice but write a file system filter driver that monitor
IRP_MJ_READ/IRP_MJ_CLOSE/IRP_MJ_CLEANUP of the executables. You can find out
if a file is executable by looking at its magic number in its dos header
(see PE spec.). This should be a fairly easy driver to write.
Bi
-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@zonelabs.com]
Sent: Friday, October 25, 2002 6:06 PM
To: File Systems Developers
Subject: [ntfsd] RE: Module load notification
Thanx BI,
I will be done on this, if I also get the Unload notification. There does
not seem to be ddk routine that I can use for unload notification…
Any idea !!!
Help !!!
-prokash
-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Thursday, October 24, 2002 11:23 AM
To: File Systems Developers
Subject: [ntfsd] RE: Module load notification
Whenever a file is mapped, it does not matter if it is mapped somewhere
else, a section object for this mapping is always created.
In one of my previous use of this callback, I kept my own database for
modules mapped into any process address space. Therefore, I keep reference
counter of the file mapping myself. A simple hash table was used to locate
element in the database.
Bi
-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@zonelabs.com]
Sent: Thursday, October 24, 2002 11:06 AM
To: File Systems Developers
Subject: [ntfsd] RE: Module load notification
Thanx Bi,
Since module loads are filemapped, how could I get unique notification. If a
shared dll is loaded under proc context A, proc context B get the advantage
…
While the *process creation for proc B* takes place the (in built) loader
with the help of VMM knows how create the PPTE, so there must be a way to
programmatically observe only new loads …
If the notification comes under the *proc New* context, then possibly I can
grab the module name being loaded, and then I will have to cache infos to
find out if the module was previously loaded or not.
*Essence of the problem is how to find the refcount of usr module that are
being shared*. For kernel module ( sort of permanent residents in the
virtual space ) there is Zw*() routines to find refcount. *IT IS THOSE user
MODULES*.
-prokash
-----Original Message-----
From: Bi Chen [mailto:xxxxx@AppStream.com]
Sent: Thursday, October 24, 2002 9:38 AM
To: File Systems Developers
Subject: [ntfsd] RE: Module load notification
Yes. It will get called everytime a image is mapped into each and very
process address space.
Bi
-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@zonelabs.com]
Sent: Wednesday, October 23, 2002 11:40 AM
To: File Systems Developers
Subject: [ntfsd] Module load notification
Using PsSetLoadImageNotifyRoutine() , and a corresponding call back, I have
the following Qs.
Does the callback get notified for all user mode dll loads ?
Also there may be some usr dll that is being shared , and in that case
switching from one process context to another, does the loader notify such
events too . Specifically if process A , and process B both uses x.dll that
is currently loaded when process A is running, when process B becomes active
the loader ( most likely) don’t need to reload, just to craft the virt. Addr
space and point to PPTE. But not sure if another notification would come or
not.
Thanx in adv.
prokash
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntfsd as: xxxxx@zonelabs.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntfsd as: xxxxx@zonelabs.com
To unsubscribe send a blank email to %%email.unsub%%
You are currently subscribed to ntfsd as: xxxxx@appstream.com
To unsubscribe send a blank email to %%email.unsub%%