CODEWITHSUNDEEP
windowswindbg
Geek
Geek

Reputation: 23419

Printing In Memory objects with WinDbg

I have a simple C++ Service which reads text from a file and sends it over the Network. Over time the memory consumption of this service increases at customer site. No such behavior is observed in QA testing.

I would like to know if it is possible to extract all the String Objects that are in the memory at any given time.

Will it be possible to automate this process such that I take dumps from customer at different times and find out sizes or contents of the memory at each time and compare the results.

Upvotes: 1

Views: 1731

Answers (3)

Ana Betts
Ana Betts

Reputation: 74692

http://msdn.microsoft.com/en-us/library/ff558947(v=vs.85).aspx is your best bet for what you want to do.

Upvotes: 1

JasonE
JasonE

Reputation: 896

For c++ the answer is no (In C# is a different story). In the c++ world, if you suspect you have a leak you would want to enable usermode stack tracing (+ust in gflags.exe) on the process before the "leak" occurs. The after the leak has occurred, get a dump of the process and examine it. To examine it (I have assumed you are using the native windows heap in this response), you will want to walk throught he heap structures to find out where the allocations are, then examine the stack backtrace for a sampling of the most common allocation size.

Example.

  1. Before you apps is running, run gflags /i MyApp.exe +ust. This sets up the regkey that provides the OS the special instructions for how to handle the process MyApp.exe
  2. Run the program and let the "bad behavior" occur
  3. Collect a dump of the process while the bad behavior is easy to see (the easier it is to see, the easier it will be to find)
  4. Open the dump in Windbg
  5. !heap -summary and find the heap with the larges Virtual Byte count
  6. The first colomn is your heap handle. Use the heap handle from the entry you found in the previous step and run !heap -stat -h -grp. This will list the heap allocations that are using the most space in the given heap.
  7. So we now know which heap was large, and the size of the entries that are the most common. We know need the address of a few so we can look at the call stack that allocated them. Run !heap -flt s .
  8. Last step (we are sooo close). Run !heap -p -a . You will now have the stack backtrace for what codepath generated this allocation. Now you can go back to your code and find out why this is not getting freed.

Upvotes: 3

mslot
mslot

Reputation: 5224

It sounds like you have a memory leak. I only uses windbg to debug managed applications. Maybe this Link can help you a bit.

Upvotes: 1

Related Questions