"Matt Adamson" wrote:

>
> We have a .NET application which is obviously using nearly 500MB memory and
> we can't understand why. I created a dump for a different issue and the
> server ended up creating a process shutdown dump of this size.
>
> I have seen the DumpLargeObjectSegments command however I'm not sure what to
> look for next i.e. the output shows
>
> 0:000> !sos.dl
> Loaded Son of Strike data table version 5 from
> "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"
> Going to dump the Large Object Segments.
> Large object heap starts at 0x02071000
> segment begin allocated size
> 02070000 02071000 02fbbf98 0x00f4af98(16,035,736)
> 0bd80000 0bd81000 0cd6f7c8 0x00fee7c8(16,705,480)
> 294b0000 294b1000 2a414908 0x00f63908(16,136,456)
> 1d010000 1d011000 1df65518 0x00f54518(16,074,008)
> 1e010000 1e011000 1ef99320 0x00f88320(16,286,496)
> 1f010000 1f011000 1ffd67a0 0x00fc57a0(16,537,504)
> 21010000 21011000 21fb4d48 0x00fa3d48(16,399,688)
> 23010000 23011000 23fe4ed0 0x00fd3ed0(16,596,688)
> 25010000 25011000 25fe7440 0x00fd6440(16,606,272)
> 274b0000 274b1000 284a4b18 0x00ff3b18(16,726,808)
> 2c4b0000 2c4b1000 2d4ac560 0x00ffb560(16,758,112)
> 2e4b0000 2e4b1000 2f47ddd0 0x00fccdd0(16,567,760)
> 2f4b0000 2f4b1000 304a3970 0x00ff2970(16,722,288)
> 304b0000 304b1000 314ad208 0x00ffc208(16,761,352)
> 08ce0000 08ce1000 09cd6d18 0x00ff5d18(16,735,512)
> 09ce0000 09ce1000 0accb370 0x00fea370(16,687,984)
> 0ace0000 0ace1000 0bc63c70 0x00f82c70(16,264,304)
> 0cd80000 0cd81000 0dd7f908 0x00ffe908(16,771,336)
> 0dd80000 0dd81000 0eba3a50 0x00e22a50(14,821,968)
>
>
> 0:000> !dumpheap -stat
> total 141,545 objects
> Statistics:
>
> which produced a ton of objects in order of total size but the bottom part
> is most useful I suspect i.e.
>
> 3379620 32,539 390,468
> Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLStaticDataStore
> 3379c3c 32,537 780,888 Tranmit.Sprinter.XMLBatchRecord
> 337bfcc 32,537 1,561,776
> Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLXMLBatchRecordData
> 95236c 127 7,808,984 System.Char[]
> 1501c8 801 76,190,256 Free
> 9526b0 438 116,192,444 System.Byte[]
> 79b94638 36,369 251,137,772 System.String
> Total 141,545 objects
>
>
>
>

"Casey Kramer" <CaseyKra***@discussions.microsoft.com> wrote in message
news:51C4CFBA-6C90-4720-9588-FE9AEBA381AA@microsoft.com...
> I'm no good at figuring out memory dumps, but I have done my share of
> diagnostic work when it comes to memory issues.
>
> I highly recomment getting a memory profiler to help see the mamanged heap
> allocations.  You can use the free CLR Profiler
> (http://www.microsoft.com/downloads/details.aspx?familyid=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en)
> or you could use a commercial profiler (.Net Memory Profiler is one, and
> Red
> Gate has their Ants profiler).  With this you can see which object(s) are
> using the most memory at a given time.  There are also several Perf
> counters
> which you can use to see the allocation of the CLR managed heap (.Net CLR
> Memory Performance Object Category).  With these tools you can get an idea
> of
> what your application is doing.
>
> There are a nice series of posts discussing the GC and managed heap health
> at: http://blogs.msdn.com/maoni/default.aspx.
>
> Hope this helps.
>
> Casey
>
> "Matt Adamson" wrote:
>
>>
>> We have a .NET application which is obviously using nearly 500MB memory
>> and
>> we can't understand why. I created a dump for a different issue and the
>> server ended up creating a process shutdown dump of this size.
>>
>> I have seen the DumpLargeObjectSegments command however I'm not sure what
>> to
>> look for next i.e. the output shows
>>
>> 0:000> !sos.dl
>> Loaded Son of Strike data table version 5 from
>> "C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorwks.dll"
>> Going to dump the Large Object Segments.
>> Large object heap starts at 0x02071000
>> segment begin allocated size
>> 02070000 02071000 02fbbf98 0x00f4af98(16,035,736)
>> 0bd80000 0bd81000 0cd6f7c8 0x00fee7c8(16,705,480)
>> 294b0000 294b1000 2a414908 0x00f63908(16,136,456)
>> 1d010000 1d011000 1df65518 0x00f54518(16,074,008)
>> 1e010000 1e011000 1ef99320 0x00f88320(16,286,496)
>> 1f010000 1f011000 1ffd67a0 0x00fc57a0(16,537,504)
>> 21010000 21011000 21fb4d48 0x00fa3d48(16,399,688)
>> 23010000 23011000 23fe4ed0 0x00fd3ed0(16,596,688)
>> 25010000 25011000 25fe7440 0x00fd6440(16,606,272)
>> 274b0000 274b1000 284a4b18 0x00ff3b18(16,726,808)
>> 2c4b0000 2c4b1000 2d4ac560 0x00ffb560(16,758,112)
>> 2e4b0000 2e4b1000 2f47ddd0 0x00fccdd0(16,567,760)
>> 2f4b0000 2f4b1000 304a3970 0x00ff2970(16,722,288)
>> 304b0000 304b1000 314ad208 0x00ffc208(16,761,352)
>> 08ce0000 08ce1000 09cd6d18 0x00ff5d18(16,735,512)
>> 09ce0000 09ce1000 0accb370 0x00fea370(16,687,984)
>> 0ace0000 0ace1000 0bc63c70 0x00f82c70(16,264,304)
>> 0cd80000 0cd81000 0dd7f908 0x00ffe908(16,771,336)
>> 0dd80000 0dd81000 0eba3a50 0x00e22a50(14,821,968)
>>
>>
>> 0:000> !dumpheap -stat
>> total 141,545 objects
>> Statistics:
>>
>> which produced a ton of objects in order of total size but the bottom
>> part
>> is most useful I suspect i.e.
>>
>> 3379620 32,539 390,468
>> Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLStaticDataStore
>> 3379c3c 32,537 780,888 Tranmit.Sprinter.XMLBatchRecord
>> 337bfcc 32,537 1,561,776
>> Tranmit.Sprinter.DataAccess.SQLDataAccess.SQLXMLBatchRecordData
>> 95236c 127 7,808,984 System.Char[]
>> 1501c8 801 76,190,256 Free
>> 9526b0 438 116,192,444 System.Byte[]
>> 79b94638 36,369 251,137,772 System.String
>> Total 141,545 objects
>>
>>
>>
>>