Hi, I am trying to find the last close operation on the memory mapped file which is created using the API “CreateFileMapping”. I have the stream context for this IRP_MJ_CLOSE but no information is provided in the IRP to differentiate whehtehr this is the call for close of memory mapped file. After noting down the PID and thread ID for the close operation, i found that the close operation for the memory mapped file is been issued by “System” process with PID 4 and the thread ID 0x5c which is of “MiDereferenceSegmentThread” thread module.
-
Can I confirmly say that MiDereferenceSegmentThread is the only responsible thread that issue close operation for memory mapped file?
-
Will the PID of “System” process which is 4 and thread ID of “MiDereferenceSegmentThread” is 0x5c remains same across all the flavours of windows and across platforms? Or will it change? I tried on two different PC running Server 2003 and found that this value remains constant even across reboots. If this value is unique, it will be easy to find whether this is the close operation issued to dereference the segment.
-
Is there any alternate way to track this last close specific to memory mapped file? As having a counter in the stream context incrementing for each Create and decrementing for each close will not match always. So tracking this last close by “system” is difficult using this counter method.
I guess it would be worth stepping back and finding out what you’re trying
to do. Nothing in the Windows architecture says that the segment dereference
thread will be thread 0x5C (or that there even has to be a dedicated thread
for this, I think you’ll find edge cases where this won’t be true…It’s a
big O/S and relying on things like this can get you into trouble).
-scott
–
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com
wrote in message news:xxxxx@ntfsd…
> Hi, I am trying to find the last close operation on the memory mapped file
> which is created using the API “CreateFileMapping”. I have the stream
> context for this IRP_MJ_CLOSE but no information is provided in the IRP to
> differentiate whehtehr this is the call for close of memory mapped file.
> After noting down the PID and thread ID for the close operation, i found
> that the close operation for the memory mapped file is been issued by
> “System” process with PID 4 and the thread ID 0x5c which is of
> “MiDereferenceSegmentThread” thread module.
>
> 1. Can I confirmly say that MiDereferenceSegmentThread is the only
> responsible thread that issue close operation for memory mapped file?
>
> 2. Will the PID of “System” process which is 4 and thread ID of
> “MiDereferenceSegmentThread” is 0x5c remains same across all the flavours
> of windows and across platforms? Or will it change? I tried on two
> different PC running Server 2003 and found that this value remains
> constant even across reboots. If this value is unique, it will be easy to
> find whether this is the close operation issued to dereference the
> segment.
>
> 3. Is there any alternate way to track this last close specific to memory
> mapped file? As having a counter in the stream context incrementing for
> each Create and decrementing for each close will not match always. So
> tracking this last close by “system” is difficult using this counter
> method.
>
> Hi, I am trying to find the last close operation on the memory mapped file which is created using the
API “CreateFileMapping”. I have the stream context for this IRP_MJ_CLOSE but no information is
provided in the IRP to differentiate whehtehr this is the call for close of memory mapped file.
Surely there is none.
Imagine C++ destructor. It also has no parameters 
MJ_CLOSE is a destructor for FILE_OBJECT (as also for FltMgr’s contexts).
Why there is any need to know who is killing the object?
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com