0

I'm using the heap_stat.py Python script for analysing memory dumps, in order to detect memory leaks, but I'm having following issue: regularly the "statistics" part contains following kind of "information":

            Type name    Count      Size
            =========    =====      ====
                  ...      ...       ...
oleaut32!CProxyWrapper    3944    Unknown
mfc110u!CPtrArray          148    Unknown

After some research, it looks like the "Unknown" part comes from the dump itself (I mean, the issue is not that the information is present in the dump and wrongly read, it looks like the information is not present in the dump).

Generally dump are taking using procdump -ma on customers' system (I mean that any solution should work on the resulting *.dmp file, I can't alter customers' systems).

Is there a way to increase the amount of information in the dump, so that the word "Unknown" does not show up in the memory dump statistics? (You can imagine that an "Unknown" piece of information make memory leak investigations quite difficult :-( )

Dominique
  • 16,450
  • 15
  • 56
  • 112
  • Looking at the `heap_stat.py` source, it seems to be getting the size out of the symbols. I'm not sure why that isn't working, but you might be able to work around it. Try keeping track of the total of the heap block sizes. [Here's my untested code](https://gist.github.com/SeanCline/1859cf59011f61ba2a46819509e10688/revisions) that takes a stab at adding an "Allocated Size" column. Keeping track of allocated sizes like this should actually be more accurate for arrays and structs with _flexible array member_s. – Sean Cline Aug 24 '17 at 11:48
  • Not sure if this can apply to the mentioned classes: the C++ Heap Manager forwards allocations >512k directly to VirtualAlloc() and does not manage them in heaps. It may simply forget about that allocation. Thus it also appears as `` in **!address -summary**. I doubt you have 3944 blocks >512k (2 GB) here. – Thomas Weller Aug 24 '17 at 13:07
  • @ThomasWeller: do you mean Sean's modifications are showing wrong results? That would be a pity, because after having tested it, it shows more information than the official version. – Dominique Aug 24 '17 at 13:36
  • @Dominique There are a few ways `heap_stat.py` can be wrong or unhelpful. If the official one (or my modifications) help figure out what is leaking, then cool. Otherwise you might need tool more suited to tracking leaks. Something like [debugdiag](https://blogs.msdn.microsoft.com/asiatech/2014/01/13/debug-diagnostic-2-0-creating-a-memory-leak-rule-unmanaged-code/), or the more hardcore [UMDH](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/using-umdh-to-find-a-user-mode-memory-leak), might be of help. They group allocations by callstack instead of by type. – Sean Cline Aug 24 '17 at 14:12
  • @SeanCline: the problem with `debugdiag` and `UMDH` is that those tools need to be installed on customers' system, while I need to get the most out of the customers' dumps, created using `procdump -ma` tool. – Dominique Aug 24 '17 at 14:30
  • Sorry, I can't judge on the modification of the Python code. It's very unlikely that this is a case of too large objects. I just mentioned it because I once had a huge leak and it was not traceable by UMDH and similar tools, because C++ did not manage it on its heap. – Thomas Weller Aug 24 '17 at 14:35
  • In that case, UMDH might be exactly what you want. You don't _need_ to install anything on the customer machine, you just need to enable _usermode stack traces_ in gflags. The documentation suggests using `gflags.exe` for that, but you can edit the registry manually. `reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\YourExecutable.exe" /v GlobalFlag /d 0x00001000` The stack information is stored in the dump. You can diff 2 dumps, grouped by stack trace, using `umdh.exe`, or display the stack of a single allocation windbg's `!heap -a [address]`. – Sean Cline Aug 24 '17 at 16:25

0 Answers0