Home/ Questions/Q 8186055
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T02:03:59+00:00

I want performant run-time memory metrics so I wrote a memory tracker based on

  • 0

I want performant run-time memory metrics so I wrote a memory tracker based on overloading new & delete. It basically lets walk your allocations in the heap and analyze everything about them – fragmentation, size, time, number, callstack, etc. But, it has 2 fatal flaws: It can’t track memory allocated in other DLLs and when ownership of objects is passed to DLLs or vice versa crashes ensue. And some smaller flaws: If a user uses malloc instead of new it’s untracked; or if a user makes a class defined new/delete.

How can I eliminate these flaws? I think I must be going about this fundamentally incorrectly by overloading new/delete, is there a better way?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The right way to implement this is to use detours and a separate tool that runs in its own process. The procedure is roughly the following:

    1. Create memory allocation in a remote process.
    2. Place there code of a small loader that will load your dll.
    3. Call CreateRemoteThread API that will run your loader.
    4. From inside of the loaded dll establish detours (hooks, interceptors) on the alloc/dealloc functions.
    5. Process the calls, track activity.

    If you implement your tool this way, it will be not important from what DLL or directly from exe the memory allocation routines are called. Plus you can track activities from any process, not necessarily that you compiled yourself.

    MS Windows allows checking contents of the virtual address space of the remote process. You can summarize use of virtual address space that was collected this way in a histogram, like the following:

    enter image description here

    From this picture you can see how many virtual allocation of what size are existing in your target process.

    enter image description here

    The picture above shows an overview of the virtual address space usage in 32-bit MSVC DevEnv. Blue stripe means a commited piece of emory, magenta stripe – reserved. Green is unoccupied part of the address space.

    You can see that lower addresses are pretty fragmented, while the middle area – not. Blue lines at high addresses – various dlls that are loaded into the process.

    • 0