Determing Process ID with shared memory

NTFSD
1

I have a filter driver that can potentially have any number of processes set up its own shared memory.  I segregate the separate locked pages by using the process ID of the requesting processs using PsGetCurrentProcessId().  When the process terminates (normally or otherwise) the IRP_MJ_CLEANUP dispatch handler looks up the current process id, matches it with the process id that belongs to the locked pages, and then unlocks the pages.  This appears to be a design flaw, however, because I’m seeing evidence that the process ID of the process that requested the shared memory and the process ID of the same process that terminates are not always the same number.  In my particular test run there was only one process

requesting/terminating, so I know it’s not an issue of multiple processes.  Is there a better way to resolve the terminating process’ shared memory than using PsGetCurrentProcessId()?  Would IoGetRequestorProcessID() be the better thing to use?  Thanks for any help or advice.

2

> I have a filter driver that can potentially have any number of processes set
up its

own shared memory. I segregate the separate locked pages by using the
process ID of the requesting processs using PsGetCurrentProcessId(). When

You can lock the pages by pending the METHOD_xxx_DIRECT IOCTL IRP, instead of
doing your own MmProbeAndLockPages.

If this IRP will be cancellable - then its completion at cancellation will
automatically do the job.

In MJ_CLEANUP handler, just cancel all pending IRPs.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Use PsGetCurrentProcess instead of PsGetCurrentProcessId.

IIRC, in the XP, PsGetCurrentProcessId returned Dr. watson’s PID when the
process was terminated abnormally but PsGetCurrentProcess didn’t.

Sean SungHyun Kim