Memory Leak

[Peter]

I have ran umdh application and created the log files but I do not know how
to interpert them.

the log files are over 1 MB zipped so I can't send the zip file to the news
group.

 

[Jeffrey Tan[MSFT]]

Hi Peter,

Thanks for your feedback.

First, you should create two log files for the application. You need to
take one log and perform some operation to reproduce the memory leak, and
then take a second log file.

After getting two log files, we may use the build-in analyze function of
UMDH.exe to compare these two log files. This is documented in the "Use
Umdh.exe to Compare UMDH Logs" section in the KB below:
http://support.microsoft.com/kb/q268343/

Let me explain the basic idea/logic here: the log file contains all the
Win32 native heap allocation stack traces(which explains the root cause of
each allocation), you can think of them as snapshot of the heap. Many of
the allocations are legal and are not the culprit of the memory leak, so we
need a way to find out the culprit allocation for the leaking. That is the
reason for comparing two log files. By comparing these two log files, the
UMDH will output the allocations that did not happen in the first snapshot
but happen between first and second snapshot(new allocations). These new
allocations are very likely the culprit for the memory leak.

After the comparison, the generated output file should big a much smaller
one. Can you paste the comparison output file here for analysis?

Also, the "UMDH Output Explained" section in the KB above explains how to
interpret the output if you want to analyze it yourself.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Peter]

I've tried to paste the comparison file bu it's still complaing the message
is too big to post to news group.
But I am pastting the end part of the file, don't know if it will do any
good.

Here's the output from the comparison

- 26000 ( 0 - 26000) 0 allocs BackTrace7331
- 26000 ( 0 - 26000) 0 allocs BackTrace7301
- 26520 ( 6528 - 33048) 544 allocs BackTrace578A
- 27104 ( 46496 - 73600) 604 allocs BackTrace578E
- 29352 ( 0 - 29352) 0 allocs BackTrace6C66
- 31972 ( 0 - 31972) 0 allocs BackTrace5453
- 35776 ( 0 - 35776) 0 allocs BackTrace7330
- 35776 ( 0 - 35776) 0 allocs BackTrace7300
- 37104 ( 0 - 37104) 0 allocs BackTrace538D
- 38880 ( 0 - 38880) 0 allocs BackTrace72FB
- 38880 ( 0 - 38880) 0 allocs BackTrace732B
- 41435 ( 0 - 41435) 0 allocs BackTraceBED0
- 42626 ( 0 - 42626) 0 allocs BackTrace7D62
- 43168 ( 18656 - 61824) 638 allocs BackTrace5790
- 43420 ( 0 - 43420) 0 allocs BackTrace7D64
- 43680 ( 0 - 43680) 0 allocs BackTrace7D5F
- 46304 ( 4704 - 51008) 147 allocs BackTrace57CE
- 46992 ( 47872 - 94864) 544 allocs BackTrace5786
- 47344 ( 26224 - 73568) 149 allocs BackTrace6270
- 48544 ( 0 - 48544) 0 allocs BackTrace6C5F
- 48840 ( 0 - 48840) 0 allocs BackTrace72FA
- 49674 ( 2174 - 51848) 85 allocs BackTrace31CE
- 51216 ( 0 - 51216) 0 allocs BackTrace732A
- 62624 ( 32560 - 95184) 1037 allocs BackTrace5D38
- 63488 ( 0 - 63488) 0 allocs BackTrace7D5E
- 68992 ( 18912 - 87904) 591 allocs BackTrace5791
- 70238 ( 278 - 70516) 11 allocs BackTrace2F00
- 70848 ( 16160 - 87008) 505 allocs BackTrace5787
- 110186 ( 0 - 110186) 0 allocs BackTrace6C64
- 110186 ( 0 - 110186) 0 allocs BackTrace6C62
- 151652 ( 0 - 151652) 0 allocs BackTrace6C5E
- 1383069 ( 41467 - 1424536) 586 allocs BackTraceF48
Total increase == -3437444 requested + -1574084 overhead = -5011528



Also:
I've ran the program and took the snap shot 2 times - 1 before and 1 after,
but the output does not make any sense to me.
For Instance I've serverched for BackTrace5787 in the 'after' snapshot and
this is what I found

20 bytes + 18 at 6AC3DC0 by BackTrace5787
7C8531E4
7C83D97A
7C8339E1
7C833D2D
77E6786F
6100119E
610011E5
61036F44
610013CE
43454C16

30 bytes + 18 at 6AFA3D8 by BackTrace5748
10 bytes + 18 at 6AFA420 by BackTrace578E
10 bytes + 18 at 6AFA448 by BackTrace5790
20 bytes + 18 at 6AFA470 by BackTrace5791
20 bytes + 18 at 6AFA4A8 by BackTrace57CE
20 bytes + 18 at 6AFA4E0 by BackTrace5787
C bytes + 1C at 6AFA518 by BackTrace578A
10 bytes + 18 at 6AFA540 by BackTrace5790
20 bytes + 18 at 6AFA568 by BackTrace5791
20 bytes + 18 at 6AFA5A0 by BackTrace57CE


So I don't know how would I find the location im my application.

Hi Peter,

Thanks for your feedback.

First, you should create two log files for the application. You need to
take one log and perform some operation to reproduce the memory leak, and
then take a second log file.

After getting two log files, we may use the build-in analyze function of
UMDH.exe to compare these two log files. This is documented in the "Use
Umdh.exe to Compare UMDH Logs" section in the KB below:
http://support.microsoft.com/kb/q268343/

Let me explain the basic idea/logic here: the log file contains all the
Win32 native heap allocation stack traces(which explains the root cause of
each allocation), you can think of them as snapshot of the heap. Many of
the allocations are legal and are not the culprit of the memory leak, so
we
need a way to find out the culprit allocation for the leaking. That is the
reason for comparing two log files. By comparing these two log files, the
UMDH will output the allocations that did not happen in the first snapshot
but happen between first and second snapshot(new allocations). These new
allocations are very likely the culprit for the memory leak.

After the comparison, the generated output file should big a much smaller
one. Can you paste the comparison output file here for analysis?

Also, the "UMDH Output Explained" section in the KB above explains how to
interpret the output if you want to analyze it yourself.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no
rights.

 

[Jeffrey Tan[MSFT]]

Hi Peter,

Thanks for your feedback.

Your comparison output is very strange since all the allocations are added
with minus sign "-" which should mean that the second snapshot freed all
these memory from the first snapshot. This basically means that the second
snapshot used less memory than the first snapshot. Do you compare these two
logs in the correct order in command line? We should always use it like
this: "umdh.exe -v [first log file] [second log file]". If we reverted the
order of these two files, the output will be incorrect.

Regarding the symbol not resolving issue, do you configure the symbol
server path correctly? This is documented in "Debug Symbols" of that KB
link. Once you configured the symbol path correctly, I think we have to use
"umdh -v dump_file_name" to resolve it as UMDH help output stated:
"If you want to investigate a particular dump, umdh -v dump_file_name can
be used to resolve the symbols. The output cannot be used for comparation."

Finally, due to the newsgroup support nature, I can not help you to perform
the debugging on-site. Since there is a step-by-step video embeded in that
KB, can you try to follow that video? I think it should be an informative
tutorial for this tool.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.