Monitoring access to memory mapped files (backed by page file)

Question

Can someone point out a tool (or tools) to monitor the access to memory mapped files on Windows systems?

Procmon from Sysinternals/Microsoft is not suitable for the task, apparently. It does not seem to be able to monitor operations that are backed by the paging file itself.

Update: my question is not about the amounts/distribution of various allocation methods. I'm interested in a tool (or tools) that show me accesses (mainly open/create/close) to MMFs.

Answer 1

As you noticed, when sharing memory between processes there's no provision for advertising/consuming the resource. So in addition to setting up the shared address region you will probably need to set up some kind of out-of-band negotiation infrastructure.

The obvious choice is to create a Win32 shared/named mutex alongside as well, for the purpose of coordinating things. The issuer process can create the synchronization object and then efficiently wait on it (i.e. without spinning, since it's a Kernel32 primitive) until the caller process connects and releases the server.

That serves as a "push" notification (to the server) to get things going; usually that would be for initialization purposes only, during which the client/server pairing establishes an (unpublished) private connection, if necessary, to last the lifetime of their session. If the design expected bandwidth is of a certain type, they might even establish a lock-free asynchronous link by CMPXCHG-ing on the shared memory, but any signaling mechanism will work, including each providing a mutex for each other's use.

So while named pipes have the setup/teardown procedures sort-of "built-in," with shared memory the disadvantage is that you're own your own. But you certainly have everything you need to roll-your-own dispatching, and the advantage is that you get to share memory chunks back-and-forth, instead of having to figure out how to serialize everything into a pipe.

In practice, you probably don't need to create the shared memory at all until a client calls, at which point either the client or server would map a new range of shared memory for private use between themselves. It your point here is to avoid using named pipes altogether, then figuring out how to communicate the (admittedly minimal) amount of setup information--namely the qword memory address of that block, at least--would be left as an exercise for the reader. It's a bootstrapping riddle (or chicken/egg problem, if you prefer).

Answer 2

This may have already been answered here with sysinternals vmmap. See if it suits your needs.