Memory Leak

[Peter]

I am using VS2008.

I have a Windows Service application which creates Crystal Reports. This is
a multi theaded application which can run several reports at one time.
My problem - there is a memory leak someplace. I can not detect the memory
leak by running several reports by hand, but when I run tha app as a
servrice and process few hundred reports there is significant memory leak.
The application can consume over 1GB of memory where it should not go over
200 mb. I have few other applications that use Crystal Reports and those
applications do not have memory leak, the big difference is those
applications are single threaded.

My question is are there any free tools I can use to find the memory leak?

I have tried http://www.softprodigy.com but I could not get it to work it
just locks up.

Thank You


Peter

[Cor Ligthert[MVP]]

Re: Memory Leak

Peter,

Always the first questions on Memory Leaks in the dotnet newsgroup

How do you know that there is a Memory Leak?

Cor

"Peter" <czupet@nospam. nospamschreef in bericht
news:OSW0fZc0IH A.3756@TK2MSFTN GP04.phx.gbl...

>I am using VS2008.
>
I have a Windows Service application which creates Crystal Reports. This
is a multi theaded application which can run several reports at one time.
My problem - there is a memory leak someplace. I can not detect the memory
leak by running several reports by hand, but when I run tha app as a
servrice and process few hundred reports there is significant memory leak.
The application can consume over 1GB of memory where it should not go over
200 mb. I have few other applications that use Crystal Reports and those
applications do not have memory leak, the big difference is those
applications are single threaded.
>
My question is are there any free tools I can use to find the memory leak?
>
I have tried http://www.softprodigy.com but I could not get it to work it
just locks up.
>
Thank You
>
>
Peter
>

[Jeffrey Tan[MSFT]]

RE: Memory Leak

Hi Peter ,

Regarding .Net memory leak issue, an important step is determing if it is a
managed leak or unmanaged memory leak.

Can you tell me what memory counter do you get "over 1G memory" result?
Windows has a lot of memory counters which may cause fake memory leak
conclusions. Basically, we should monitor "Process/Private Bytes"(or "VM
Size" column in task manager.) counter to determine memory leak. Note: we
should not use the "Mem Usage" column in task manager which is misleading.
I highly recommend you to download Process Explorer tool from the link
below since it is more powerful tool than task manager:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

Once the "Private Bytes" is keeping increasing without decrease, it means
that the application is leaking memory. Now, you can monitor the ".Net CLR
Memory/# Bytes in all Heaps" counter. If the "Private Bytes" increases
while the ".Net CLR Memory" is stable, it indicates an unmanaged memory
leak. Otherwise, it basically means a managed memory leak. The article
below talks more information:
"I have a memory leak!!! What do i do? (defining the "where")"

http://blogs.msdn.com/tess/archive/2005/11/25/i-have-a-memory-leak-what-do-i

-do-defining-the-where.aspx

I will wait for your further feedback to determine if it is a managed or
unmanaged leak since they need totally different approach for
troubleshooting . 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:
msdnmg@microsof t.com.

=============== =============== =============== =====
Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif

ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.

[Peter]

Re: Memory Leak


"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message
news:195BA553-ECD7-4241-947B-3C73E8021294@mi crosoft.com...

Peter,
>
Always the first questions on Memory Leaks in the dotnet newsgroup
>
How do you know that there is a Memory Leak?
>
Cor
>
"Peter" <czupet@nospam. nospamschreef in bericht
news:OSW0fZc0IH A.3756@TK2MSFTN GP04.phx.gbl...

>>I am using VS2008.
>>
>I have a Windows Service application which creates Crystal Reports. This
>is a multi theaded application which can run several reports at one time.
>My problem - there is a memory leak someplace. I can not detect the
>memory leak by running several reports by hand, but when I run tha app as
>a servrice and process few hundred reports there is significant memory
>leak. The application can consume over 1GB of memory where it should not
>go over 200 mb. I have few other applications that use Crystal Reports
>and those applications do not have memory leak, the big difference is
>those applications are single threaded.
>>
>My question is are there any free tools I can use to find the memory
>leak?
>>
>I have tried http://www.softprodigy.com but I could not get it to work it
>just locks up.
>>
>Thank You
>>
>>
>Peter
>>

>

I do not know if it's the memory leak - that's what I am trying to find out.

The reason I am starting with this assumption is because when I look at the
"Mem Usage" in the Windows Task Manager the memory keeps growing and never
ever goes down and eventually the system goes to a craw until I restart the
application. Plus my other simullar applications when they run the "Mem
Usage" goes up and down and eventually goes back to the almost original
starting number when the applications is not processing anything.

[Peter]

Re: Memory Leak

I get "over 1G" on both "Mem Usage" and "VM Size", the VM Size is slightly
lower but it's consistant with "Mem Usage" so in this case "at least it
looks like Mem Usage is just as reliable"

I have also downlaoded the Process Exlprer and "Private Bytes" keep going up
and up, it does go down slightly at times but not as much as it goes up.


""Jeffrey Tan[MSFT]"" <jetan@online.m icrosoft.comwro te in message
news:qLhErFd0IH A.1788@TK2MSFTN GHUB02.phx.gbl. ..

Hi Peter ,
>
Regarding .Net memory leak issue, an important step is determing if it is
a
managed leak or unmanaged memory leak.
>
Can you tell me what memory counter do you get "over 1G memory" result?
Windows has a lot of memory counters which may cause fake memory leak
conclusions. Basically, we should monitor "Process/Private Bytes"(or "VM
Size" column in task manager.) counter to determine memory leak. Note: we
should not use the "Mem Usage" column in task manager which is misleading.
I highly recommend you to download Process Explorer tool from the link
below since it is more powerful tool than task manager:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

>
Once the "Private Bytes" is keeping increasing without decrease, it means
that the application is leaking memory. Now, you can monitor the ".Net CLR
Memory/# Bytes in all Heaps" counter. If the "Private Bytes" increases
while the ".Net CLR Memory" is stable, it indicates an unmanaged memory
leak. Otherwise, it basically means a managed memory leak. The article
below talks more information:
"I have a memory leak!!! What do i do? (defining the "where")"

http://blogs.msdn.com/tess/archive/2005/11/25/i-have-a-memory-leak-what-do-i

-do-defining-the-where.aspx
>
I will wait for your further feedback to determine if it is a managed or
unmanaged leak since they need totally different approach for
troubleshooting . 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:
msdnmg@microsof t.com.
>
=============== =============== =============== =====
Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif

ications.
>
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>

[Jeffrey Tan[MSFT]]

Re: Memory Leak

Hi Peter,

Thanks for your feedback.

This should mean a memory leak in your application. Then, have you checked
".Net CLR Memory/# Bytes in all Heaps" counter? It will help us to
distinguish between managed/unmanaged leak in the application.

The "Mem Usage" actually means the "Working Set Size" which is the physical
RAM that a process currently uses instead of virtual memory. In modern
Virtual Memory OS, the physical RAM usage normally makes no sense to
application developer since the kernel VMM manages this. The "Working Set"
increases/decreases based on the OS paging activities and the process
working set commit. For example, if you bring a GUI application to the
foreground, it "Mem Usage" will go up immediately while many other
background applications' "Mem Usage" may decrease. This has nothing to do
with the memory leak. Also, although one applicatin is leaking memory, if
it has reached the "Working Set" charge limit, you will find that "Mem
Usage" not change anymore, but the process is still leaking. So, "Mem
Usage" is basically a useless counter.

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:
msdnmg@microsof t.com.

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

[Peter]

Re: Memory Leak

The Private Bytes counter - Keeps increasing
The # Bytes in all Heaps - Keeps increasing
Gen 0 heap size - is stable (increases and decreases)
Gen 1 heap size - is stable (increases and decreases)
Gen 2 heap size - Keeps increasing



""Jeffrey Tan[MSFT]"" <jetan@online.m icrosoft.comwro te in message
news:Sxd9szp0IH A.1784@TK2MSFTN GHUB02.phx.gbl. ..

Hi Peter,
>
Thanks for your feedback.
>
This should mean a memory leak in your application. Then, have you checked
".Net CLR Memory/# Bytes in all Heaps" counter? It will help us to
distinguish between managed/unmanaged leak in the application.
>
The "Mem Usage" actually means the "Working Set Size" which is the
physical
RAM that a process currently uses instead of virtual memory. In modern
Virtual Memory OS, the physical RAM usage normally makes no sense to
application developer since the kernel VMM manages this. The "Working Set"
increases/decreases based on the OS paging activities and the process
working set commit. For example, if you bring a GUI application to the
foreground, it "Mem Usage" will go up immediately while many other
background applications' "Mem Usage" may decrease. This has nothing to do
with the memory leak. Also, although one applicatin is leaking memory, if
it has reached the "Working Set" charge limit, you will find that "Mem
Usage" not change anymore, but the process is still leaking. So, "Mem
Usage" is basically a useless counter.
>
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:
msdnmg@microsof t.com.
>
This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>

[Jeffrey Tan[MSFT]]

Re: Memory Leak

Hi Peter,

Thanks for your feedback.

Ok, this sounds like a managed memory leak in .Net.

To troubleshoot the managed memory leak, we normally use windbg+SOS.dll
extension which understands the internal data structure of .Net objects.
The basic idea is: first dumping all the managed objects on the managed
heap sorted by size. Then we can understand what type of object costs the
most of memory(which is the possible culprit for leaking). Then, we can use
"!gcroot" command to traverse all the root graph to find the call graph
that is holding the reference to the leaking objects. The articles talk
about the detailed steps regarding how to perform these steps:
"Tracking down managed memory leaks (how to find a GC leak)"

http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

".NET Memory Leak Case Study: The Event Handlers That Made The Memory
Baloon"

http://blogs.msdn.com/tess/archive/2006/01/23/net-memory-leak-case-study-the

-event-handlers-that-made-the-memory-baloon.aspx

Hope it helps.

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:
msdnmg@microsof t.com.

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

[Peter]

Re: Memory Leak

I've downloaded vadump.exe from Microsoft but I am getting error
'FAILURE query working set 24' when I run it.
and
Where can I find these tools like !dumpheap and !eeheap

I have VS2008 Archtect addition installed on my machine, but I don't have
those programs.



""Jeffrey Tan[MSFT]"" <jetan@online.m icrosoft.comwro te in message
news:TgwN97O1IH A.1788@TK2MSFTN GHUB02.phx.gbl. ..

Hi Peter,
>
Thanks for your feedback.
>
Ok, this sounds like a managed memory leak in .Net.
>
To troubleshoot the managed memory leak, we normally use windbg+SOS.dll
extension which understands the internal data structure of .Net objects.
The basic idea is: first dumping all the managed objects on the managed
heap sorted by size. Then we can understand what type of object costs the
most of memory(which is the possible culprit for leaking). Then, we can
use
"!gcroot" command to traverse all the root graph to find the call graph
that is holding the reference to the leaking objects. The articles talk
about the detailed steps regarding how to perform these steps:
"Tracking down managed memory leaks (how to find a GC leak)"

http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

".NET Memory Leak Case Study: The Event Handlers That Made The Memory
Baloon"

http://blogs.msdn.com/tess/archive/2006/01/23/net-memory-leak-case-study-the

-event-handlers-that-made-the-memory-baloon.aspx
>
Hope it helps.
>
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:
msdnmg@microsof t.com.
>
This posting is provided "AS IS" with no warranties, and confers no
rights.
>
>

[Jeffrey Tan[MSFT]]

Re: Memory Leak

Hi Peter,

Thanks for your feedback.

Actually, there is no need to run vadump.exe because we have used different
counters from Process Explorer to confirm the memory leak. So we may ignore
the first 3 steps in the link below and start from the step 4:

http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

!dumpheap and !eeheap are both the windbg extension commands exported by
SOS.dll which is written by the CLR team for internal debugging purpose.
So, we need to install windbg to debug this memory leak instead of using VS
debugger. Yes, we can use VS debugger with SOS.dll, but it is inconvenient.
The link below talks about how to use VS debugger+SOS.dl l for .Net
debugging:
".NET Finalizer Memory Leak: Debugging with sos.dll in Visual Studio"

http://blogs.msdn.com/tess/archive/2007/10/19/net-finalizer-memory-leak-debu

gging-with-sos-dll-in-visual-studio.aspx

I prefer windbg because it is more powerful and convenient for production
debugging than VS debugger and it is free. If you have never used windbg
before, you can follow the basic setup in the blog I written below:
"How to debug application crash/hang in production environment"

http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-application-cra

sh-hang-in-production-environment.asp x

After completing the windbg installation and configuration, you can follow
to start from "Step 4: Attach Windbg and load SOS" in the first blog link
above.

If there is anything unclear, please feel free to tell me, 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:
msdnmg@microsof t.com.

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

[Peter]

Re: Memory Leak

Thanks for our help

I have fallowed the instructions and it seems to be working, but I do not
know what the results mean, I don't know how to read them
Here's a partial output, but I do not know what to do next.

!DumpHeap -stat

00687e2c 3572 285760
CrystalDecision s.CrystalReport s.Engine.Report Document
00d9c33c 21518 860720
com.crystaldeci sions.common.ke ycode.KeycodeDe finitionDataXML +feature
79101fe4 22600 1265600 System.Collecti ons.Hashtable
790fd8c4 22576 1351096 System.String
0015bbc0 295 2175560 Free
7912d9bc 22600 3270432 System.Collecti ons.Hashtable+b ucket[]

!DumpHeap -type System.Collecti ons.Hashtable+b ucket[]
Address MT Size
00fd15bc 7912d9bc 144
00fd1684 7912d9bc 144
00fd174c 7912d9bc 144
00fd18c0 7912d9bc 144
00fd1a60 7912d9bc 144
00fd1bd0 7912d9bc 144
00fd1cc4 7912d9bc 144
00fd1d8c 7912d9bc 144
00fd2168 7912d9bc 144
00fd2230 7912d9bc 144
00fd28c4 7912d9bc 216
00fd30ec 7912d9bc 144
00fd442c 7912d9bc 144
00fd4d3c 7912d9bc 456
00fd4f3c 7912d9bc 456
00fdeca0 7912d9bc 2880
00fe2ae8 7912d9bc 288
00fe2e4c 7912d9bc 144
00fe306c 7912d9bc 144
00fe3134 7912d9bc 144
00fe34a4 7912d9bc 144
00fe3de4 7912d9bc 144
00fe4c40 7912d9bc 144
00fe5438 7912d9bc 1296
010bb2e4 7912d9bc 144
010bb574 7912d9bc 144
010bb84c 7912d9bc 144
010bb978 7912d9bc 144
010bbb3c 7912d9bc 144
010bbc74 7912d9bc 144
010bbe30 7912d9bc 144
010bc180 7912d9bc 144
010bcbf8 7912d9bc 144
010c2dc0 7912d9bc 1296
010cde14 7912d9bc 144

!gcroot 00fdeca0

Note: Roots found on stacks may be false positives. Run "!help gcroot" for
more info.
Scan Thread 0 OSTHread 1490
Scan Thread 2 OSTHread 15dc
Scan Thread 5 OSTHread 11b0
Scan Thread 13 OSTHread de0
Scan Thread 14 OSTHread 1c68
Scan Thread 15 OSTHread 1e50
DOMAIN(001652D0 ):HANDLE(WeakSh ):6612c4:Root:0 10d0f48(System. Diagnostics.Sou rceSwitch)->
010d11e0(System .Diagnostics.Sw itchElementsCol lection)->
00fd536c(System .Configuration. RuntimeConfigur ationRecord)->
00fd619c(System .Collections.Ha shtable)->
00fdeca0(System .Collections.Ha shtable+bucket[])


""Jeffrey Tan[MSFT]"" <jetan@online.m icrosoft.comwro te in message
news:prgf8Cb1IH A.5360@TK2MSFTN GHUB02.phx.gbl. ..

Hi Peter,
>
Thanks for your feedback.
>
Actually, there is no need to run vadump.exe because we have used
different
counters from Process Explorer to confirm the memory leak. So we may
ignore
the first 3 steps in the link below and start from the step 4:

http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

>
!dumpheap and !eeheap are both the windbg extension commands exported by
SOS.dll which is written by the CLR team for internal debugging purpose.
So, we need to install windbg to debug this memory leak instead of using
VS
debugger. Yes, we can use VS debugger with SOS.dll, but it is
inconvenient.
The link below talks about how to use VS debugger+SOS.dl l for .Net
debugging:
".NET Finalizer Memory Leak: Debugging with sos.dll in Visual Studio"

http://blogs.msdn.com/tess/archive/2007/10/19/net-finalizer-memory-leak-debu

gging-with-sos-dll-in-visual-studio.aspx
>
I prefer windbg because it is more powerful and convenient for production
debugging than VS debugger and it is free. If you have never used windbg
before, you can follow the basic setup in the blog I written below:
"How to debug application crash/hang in production environment"

http://blogs.msdn.com/msdnts/archive/2006/11/24/how-to-debug-application-cra

sh-hang-in-production-environment.asp x
>
After completing the windbg installation and configuration, you can follow
to start from "Step 4: Attach Windbg and load SOS" in the first blog link
above.
>
If there is anything unclear, please feel free to tell me, 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:
msdnmg@microsof t.com.
>
This posting is provided "AS IS" with no warranties, and confers no
rights.
>

[Jeffrey Tan[MSFT]]

Re: Memory Leak

Hi Peter,

Thanks for your feedback.

The "!DumpHeap - stat" command will group all the objects on the heap
based on their types. The output is sorted by the occupied space of each
type(3rd column), so we can find out the objects that occupy the largest
memory space. For detailed explanation of this command, please refer to:
"!dumpheap -stat explained¡ (debugging .net leaks)"
http://blogs.msdn.com/tess/archive/2...25/496973.aspx.

In your output, is "System.Collect ions.Hashtable+ bucket[]" the last line in
the output? From the output, "System.Collect ions.Hashtable+ bucket[]" type
only occupes about 3MB of memory(3270432) , so it may not be the culprit of
the leaking problem.

Can you paste the last several lines of the output? There should be a
summary line stating the total objects and total heap object sizes, like
"Total 9,712,896 objects, Total size: 1,032,127,612".

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:
msdnmg@microsof t.com.

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

[Peter]

Re: Memory Leak

Here are the results from !dumpheap -stat


!dumpheap -stat

00d951f4 13173 316152 CrystalDecision s.Shared.Export Options
790fa9d8 23429 374864 System.__ComObj ect
04e7c68c 12603 403296
CrystalDecision s.CrystalReport s.Engine.DataSo urceCacheItem
04e7715c 12603 403296 CrystalDecision s.CrystalReport s.Engine.Table
00687f64 13172 1053760
CrystalDecision s.CrystalReport s.Engine.Report Document
00164450 2373 2024340 Free
790fd8c4 60981 3590148 System.String
79101fe4 94954 5317424 System.Collecti ons.Hashtable
7912d9bc 94956 13689264 System.Collecti ons.Hashtable+b ucket[]
Total 449066 objects

!dumpheap -mt 7912d9bc

total 94956 objects
Statistics:
MT Count TotalSize Class Name
7912d9bc 94956 13689264 System.Collecti ons.Hashtable+b ucket[]
Total 94956 objects


""Jeffrey Tan[MSFT]"" <jetan@online.m icrosoft.comwro te in message
news:wUNK%23t21 IHA.1784@TK2MSF TNGHUB02.phx.gb l...

Hi Peter,
>
Thanks for your feedback.
>
The "!DumpHeap - stat" command will group all the objects on the heap
based on their types. The output is sorted by the occupied space of each
type(3rd column), so we can find out the objects that occupy the largest
memory space. For detailed explanation of this command, please refer to:
"!dumpheap -stat explained¡ (debugging .net leaks)"
http://blogs.msdn.com/tess/archive/2...25/496973.aspx.
>
In your output, is "System.Collect ions.Hashtable+ bucket[]" the last line
in
the output? From the output, "System.Collect ions.Hashtable+ bucket[]" type
only occupes about 3MB of memory(3270432) , so it may not be the culprit of
the leaking problem.
>
Can you paste the last several lines of the output? There should be a
summary line stating the total objects and total heap object sizes, like
"Total 9,712,896 objects, Total size: 1,032,127,612".
>
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:
msdnmg@microsof t.com.
>
This posting is provided "AS IS" with no warranties, and confers no
rights.
>

[Jeffrey Tan[MSFT]]

Re: Memory Leak

Hi Peter,

Thanks for your feedback.

The command output indicates that the largest object size on the GC heap is
of type "System.Collect ions.Hashtable+ bucket[]". However, it only costs
less than 14M memory: "13689264". So, it should not be the culprit of the
memory leaking problem.

Can you issue command "!eeheap" in your application? This command will dump
a summary report of all the managed heaps in the application. I suspect the
GC heap is not leaking that much memory yet. You may paste the "!eeheap"
command output here for analysis. 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:
msdnmg@microsof t.com.

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

[Peter]

Re: Memory Leak

Here it is the !eeheap


Loader Heap:
--------------------------------------
System Domain: 7a3bc8b8
LowFrequencyHea p: Size: 0x0(0)bytes.
HighFrequencyHe ap: 00672000(8000:1 000) Size: 0x1000(4096)byt es.
StubHeap: 0067a000(2000:2 000) 04150000(10000: 7000) Size: 0x9000(36864)by tes.
Virtual Call Stub Heap:
IndcellHeap: Size: 0x0(0)bytes.
LookupHeap: Size: 0x0(0)bytes.
ResolveHeap: Size: 0x0(0)bytes.
DispatchHeap: Size: 0x0(0)bytes.
CacheEntryHeap: Size: 0x0(0)bytes.
Total size: 0xa000(40960)by tes
--------------------------------------
Shared Domain: 7a3bc560
LowFrequencyHea p: 006a0000(2000:1 000) Size: 0x1000(4096)byt es.
HighFrequencyHe ap: 006a2000(8000:1 000) Size: 0x1000(4096)byt es.
StubHeap: 006aa000(2000:1 000) Size: 0x1000(4096)byt es.
Virtual Call Stub Heap:
IndcellHeap: 006b0000(2000:1 000) Size: 0x1000(4096)byt es.
LookupHeap: 006b5000(2000:1 000) Size: 0x1000(4096)byt es.
ResolveHeap: 006bb000(5000:1 000) Size: 0x1000(4096)byt es.
DispatchHeap: 006b7000(4000:1 000) Size: 0x1000(4096)byt es.
CacheEntryHeap: 006b2000(3000:1 000) Size: 0x1000(4096)byt es.
Total size: 0x7000(28672)by tes
--------------------------------------
Domain 1: 15a790
LowFrequencyHea p: 00680000(2000:2 000) 00b90000(10000: d000)
00d80000(10000: 10000) 00dc0000(10000: f000) 03890000(10000: f000)
039a0000(10000: f000) 00ac0000(10000: f000) 077b0000(10000: 10000)
07ee0000(10000: 10000) 08860000(10000: 10000) 07000000(10000: d000)
05c90000(20000: 20000) 05e40000(10000: c000) Size: 0xc4000(802816) bytes.
Wasted: 0xa000(40960)by tes.
HighFrequencyHe ap: 00682000(8000:8 000) 00d90000(10000: 10000)
04e70000(10000: 10000) 07ab0000(10000: 10000) 07ed0000(10000: 10000)
07f50000(10000: 10000) 055c0000(10000: 10000) 05cc0000(10000: a000) Size:
0x72000(466944) bytes.
StubHeap: 0068a000(2000:2 000) 07ac0000(10000: 3000) Size: 0x5000(20480)by tes.
Virtual Call Stub Heap:
IndcellHeap: 00690000(2000:1 000) Size: 0x1000(4096)byt es.
LookupHeap: 00696000(1000:1 000) Size: 0x1000(4096)byt es.
ResolveHeap: 0069a000(6000:5 000) Size: 0x5000(20480)by tes.
DispatchHeap: 00697000(3000:2 000) Size: 0x2000(8192)byt es.
CacheEntryHeap: 00692000(4000:1 000) Size: 0x1000(4096)byt es.
Total size: 0x144000(132710 4)bytes
--------------------------------------
Jit code heap:
LoaderCodeHeap: 05d30000(10000: 8000) Size: 0x8000(32768)by tes.
LoaderCodeHeap: 05cb0000(10000: 10000) Size: 0x10000(65536)b ytes.
LoaderCodeHeap: 050a0000(10000: 10000) Size: 0x10000(65536)b ytes.
LoaderCodeHeap: 06fe0000(10000: 10000) Size: 0x10000(65536)b ytes.
LoaderCodeHeap: 088b0000(10000: 10000) Size: 0x10000(65536)b ytes.
LoaderCodeHeap: 077e0000(10000: f000) Size: 0xf000(61440)by tes.
LoaderCodeHeap: 05290000(10000: 10000) Size: 0x10000(65536)b ytes.
LoaderCodeHeap: 00b50000(10000: f000) Size: 0xf000(61440)by tes.
LoaderCodeHeap: 00ba0000(10000: e000) Size: 0xe000(57344)by tes.
Total size: 0x84000(540672) bytes
--------------------------------------
Module Thunk heaps:
Module 790c2000: Size: 0x0(0)bytes.
Module 006a239c: Size: 0x0(0)bytes.
Module 006a2010: Size: 0x0(0)bytes.
Module 00682c3c: Size: 0x0(0)bytes.
Module 67a30000: Size: 0x0(0)bytes.
Module 7a726000: Size: 0x0(0)bytes.
Module 00683e94: Size: 0x0(0)bytes.
Module 006851d4: Size: 0x0(0)bytes.
Module 006862f4: Size: 0x0(0)bytes.
Module 7b454000: Size: 0x0(0)bytes.
Module 7ae74000: Size: 0x0(0)bytes.
Module 00d90084: Size: 0x0(0)bytes.
Module 00d9070c: Size: 0x0(0)bytes.
Module 00d90ea4: Size: 0x0(0)bytes.
Module 648ea000: Size: 0x0(0)bytes.
Module 639f8000: Size: 0x0(0)bytes.
Module 00d92568: Size: 0x0(0)bytes.
Module 653f2000: 03860000(10000: 1000) Size: 0x1000(4096)byt es.
Module 00d95f14: Size: 0x0(0)bytes.
Module 00d97404: Size: 0x0(0)bytes.
Module 00d983c0: Size: 0x0(0)bytes.
Module 00d9901c: Size: 0x0(0)bytes.
Module 00d995b8: Size: 0x0(0)bytes.
Module 00d9ab64: Size: 0x0(0)bytes.
Module 6638c000: Size: 0x0(0)bytes.
Module 67b2e000: Size: 0x0(0)bytes.
Module 67426000: Size: 0x0(0)bytes.
Module 04cf4000: 04d50000(10000: 2000) Size: 0x2000(8192)byt es.
Module 6037e000: 077a0000(10000: 2000) Size: 0x2000(8192)byt es.
Module 04e7a46c: Size: 0x0(0)bytes.
Module 65da0000: Size: 0x0(0)bytes.
Module 07ed601c: Size: 0x0(0)bytes.
Module 07ed6ca4: Size: 0x0(0)bytes.
Module 07f51f54: Size: 0x0(0)bytes.
Module 07f5fb04: Size: 0x0(0)bytes.
Module 055c341c: Size: 0x0(0)bytes.
Total size: 0x5000(20480)by tes
--------------------------------------
Module Lookup Table heaps:
Module 790c2000: Size: 0x0(0)bytes.
Module 006a239c: Size: 0x0(0)bytes.
Module 006a2010: Size: 0x0(0)bytes.
Module 00682c3c: Size: 0x0(0)bytes.
Module 67a30000: Size: 0x0(0)bytes.
Module 7a726000: Size: 0x0(0)bytes.
Module 00683e94: Size: 0x0(0)bytes.
Module 006851d4: Size: 0x0(0)bytes.
Module 006862f4: Size: 0x0(0)bytes.
Module 7b454000: Size: 0x0(0)bytes.
Module 7ae74000: Size: 0x0(0)bytes.
Module 00d90084: Size: 0x0(0)bytes.
Module 00d9070c: Size: 0x0(0)bytes.
Module 00d90ea4: Size: 0x0(0)bytes.
Module 648ea000: Size: 0x0(0)bytes.
Module 639f8000: Size: 0x0(0)bytes.
Module 00d92568: Size: 0x0(0)bytes.
Module 653f2000: Size: 0x0(0)bytes.
Module 00d95f14: Size: 0x0(0)bytes.
Module 00d97404: Size: 0x0(0)bytes.
Module 00d983c0: Size: 0x0(0)bytes.
Module 00d9901c: Size: 0x0(0)bytes.
Module 00d995b8: Size: 0x0(0)bytes.
Module 00d9ab64: Size: 0x0(0)bytes.
Module 6638c000: Size: 0x0(0)bytes.
Module 67b2e000: Size: 0x0(0)bytes.
Module 67426000: Size: 0x0(0)bytes.
Module 04cf4000: Size: 0x0(0)bytes.
Module 6037e000: Size: 0x0(0)bytes.
Module 04e7a46c: Size: 0x0(0)bytes.
Module 65da0000: Size: 0x0(0)bytes.
Module 07ed601c: Size: 0x0(0)bytes.
Module 07ed6ca4: Size: 0x0(0)bytes.
Module 07f51f54: Size: 0x0(0)bytes.
Module 07f5fb04: Size: 0x0(0)bytes.
Module 055c341c: Size: 0x0(0)bytes.
Total size: 0x0(0)bytes
--------------------------------------
Total LoaderHeap size: 0x1de000(195788 8)bytes
=============== =============== =========
Number of GC Heaps: 1
generation 0 starts at 0x1e7800f4
generation 1 starts at 0x1e770098
generation 2 starts at 0x00fd1000
ephemeral segment allocation context: none
segment begin allocated size
001960a0 7b463c40 7b47a744 0x00016b04(9293 2)
0017c2a8 7a733370 7a754b98 0x00021828(1372 56)
00170ec0 790d8620 790f7d8c 0x0001f76c(1288 76)
00fd0000 00fd1000 01e3aa38 0x00e69a38(1511 2760)
1e5e0000 1e5e1000 1e7bc100 0x001db100(1945 856)
Large object heap starts at 0x01fd1000
segment begin allocated size
01fd0000 01fd1000 0211c910 0x0014b910(1358 096)
Total Size 0x11e7ee0(18775 776)
------------------------------
GC Heap Size 0x11e7ee0(18775 776)

""Jeffrey Tan[MSFT]"" <jetan@online.m icrosoft.comwro te in message
news:W6G7F2W4IH A.1624@TK2MSFTN GHUB02.phx.gbl. ..

Hi Peter,
>
Thanks for your feedback.
>
The command output indicates that the largest object size on the GC heap
is
of type "System.Collect ions.Hashtable+ bucket[]". However, it only costs
less than 14M memory: "13689264". So, it should not be the culprit of the
memory leaking problem.
>
Can you issue command "!eeheap" in your application? This command will
dump
a summary report of all the managed heaps in the application. I suspect
the
GC heap is not leaking that much memory yet. You may paste the "!eeheap"
command output here for analysis. 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:
msdnmg@microsof t.com.
>
This posting is provided "AS IS" with no warranties, and confers no
rights.
>