-2

If I enumerate heaps in my process using GetProcessHeaps API, is there a way to tell which module(s) were those heaps created by?

Here's why I need this: For the purpose of my security application I need to lock virtual memory used by my process (i.e. memory used by the Windows common controls, anything allocated via the new operator, COM, etc.)

The reason I need to know which module created the heap is to eliminate any DLLs that can be loaded into my process that have nothing to do with it. Say, as an example, TeamViewer loads into running processes to add whatever-they-need-it-for, so I don't want to lock its private heap, if it has one, etc.

c00000fd
  • 20,994
  • 29
  • 177
  • 400
  • in process heap internal structures ([_HEAP](https://bekirkarul.com/posts/heap-notlari)) no any information about who (return address of caller ?) create this heap. system not care about this. so you and can not got not existing info. maximum what you can do here - hook `HeapCreate` and `RtlCreateHeap` for look who call this. but say *msvcrt* also create private heaps for client... you will be do stack walk ? think task not have any acceptable solution – RbMm May 29 '17 at 22:31
  • Hook the heap creation functions and walk the call stack. But I doubt this will be very robust. – David Heffernan May 29 '17 at 22:31
  • OK. Thank you both. That's what I was thinking. – c00000fd May 29 '17 at 22:33
  • And what about modules that implement their own heaps with VirtualAlloc or NUMA allocation functions? – David Heffernan May 29 '17 at 22:42
  • @DavidHeffernan: They will not be covered by this method. – c00000fd May 29 '17 at 22:44

1 Answers1

0

If you are only concerned with you own allocations then you can just use your own private heap and override the default new and delete handlers to use your heap.

Mike
  • 3,462
  • 22
  • 25
  • Like I said above, it's not just my own allocations. It's mostly common controls, `COM` objects, plus C++'s own implicit `new` operators. – c00000fd May 29 '17 at 22:38
  • If you are using com you will have other problems because of marshaling. You should probably make these objects logic based only and keep internal data on your protected heap. – Mike May 29 '17 at 22:44
  • I don't use `COM` specifically, but common controls do. For instance, RichEdit control does. Maybe just a plain EDIT textbox as well. – c00000fd May 29 '17 at 22:45
  • @c00000fd - all common controls use only `GetProcessHeap()` - so and lock only it and ignore all others – RbMm May 29 '17 at 22:49
  • @RbMm: I'm getting 5 heaps in this MFC dialog-based app. It's a stock project where I just added an edit & richedit controls, and also called `AfxInitRichEdit2()` and `OleInitialize()`. So there must be something else to it... – c00000fd May 29 '17 at 23:37
  • @c00000fd - but if correct understand you care only about edit/richedit controls, where they internally save displayed text. edit use process main heap and this is documented. richedit (as and another controls) also use it. despite this already not documented - quit reasonable. – RbMm May 29 '17 at 23:48
  • Monitoring COM allocations? Try [IMallocSpy](https://msdn.microsoft.com/en-us/library/windows/desktop/ms688508(v=vs.85).aspx). No idea if this will interfere with MFC, though. – andlabs May 30 '17 at 21:18