{"id":23155,"date":"2004-11-08T23:03:00","date_gmt":"2004-11-08T23:03:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/maoni\/2004\/11\/08\/tools-that-help-diagnose-managed-memory-related-issues\/"},"modified":"2021-10-04T16:38:37","modified_gmt":"2021-10-04T23:38:37","slug":"tools-that-help-diagnose-managed-memory-related-issues","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/tools-that-help-diagnose-managed-memory-related-issues\/","title":{"rendered":"Tools that help diagnose managed memory related issues"},"content":{"rendered":"

I was writing an internal wiki page on performance and thought this info is useful to many external readers as well so here it goes.<\/span><\/p>\n

vadump<\/span><\/b> is a good start. It\u2019s an mstools tool \u2013 meaning you can find it on your NT CD under bin\\mstools. You can take a snapshot of the process and see if the GC heap is an issue or not. It was created a long time ago before managed code was popular so the GC heap is  part of “Other data” in the output of vadump (heh…:P). If it’s a small portion of your working set it’s better to look elsewhere. It shows a lot of useful info though and I’ve worked with many external customers that didn’t know about it so I thought it’d be useful to mention it.<\/span><\/font><\/p>\n

 <\/font><\/span><\/p>\n

Type vadump -? for help. Below is an example using vadump:<\/font><\/span><\/p>\n

 <\/font><\/span><\/b><\/p>\n

E:\\clr\\ndp\\clr\\src\\VM>tlist | findstr \/i devenv<\/font><\/font><\/span><\/p>\n

1812 devenv.exe        <\/span>Microsoft Development Environment [design] – gcpriv.h<\/font><\/span><\/p>\n

E:\\clr\\ndp\\clr\\src\\VM>vadump -so -p 1812<\/font><\/font><\/span><\/p>\n

Catagory                        <\/span>Total        <\/span>Private Shareable    <\/span>Shared<\/font><\/span><\/p>\n

                           <\/span>Pages    <\/span>KBytes    <\/span>KBytes    <\/span>KBytes    <\/span>KBytes<\/font><\/span><\/p>\n

      <\/span>Page Table Pages       <\/span>116       <\/span>464       <\/span>464         <\/span>0         <\/span>0<\/font><\/span><\/p>\n

      <\/span>Other System           <\/span>127     <\/span>  <\/span>508       <\/span>508         <\/span>0         <\/span>0<\/font><\/span><\/p>\n

      <\/span>Code\/StaticData       <\/span>3470     <\/span>13880      <\/span>1000      <\/span>7828      <\/span>5052<\/font><\/span><\/p>\n

      <\/span>Heap                  <\/span>6521     <\/span>26084     <\/span>26084         <\/span>0         <\/span>0<\/font><\/span><\/p>\n

      <\/span>Stack                   <\/span>51       <\/span>204       <\/span>204         <\/span>0         <\/span>0<\/font><\/span><\/p>\n

 <\/span>     <\/span>Teb                     <\/span>14        <\/span>56        <\/span>56         <\/span>0         <\/span>0<\/font><\/span><\/p>\n

      <\/span>Mapped Data            <\/span>943      <\/span>3772         <\/span>0       <\/span>444      <\/span>3328<\/font><\/span><\/p>\n

      <\/span>Other Data            <\/span>6595     <\/span>26380     <\/span>26376         <\/span>4         <\/span>0<\/font><\/span><\/p>\n

 <\/font><\/span><\/p>\n

      <\/span>Total Modules         <\/span>3470     <\/span>13880      <\/span>1000      <\/span>7828      <\/span>5052<\/font><\/span><\/p>\n

      <\/span>Total Dynamic Data   <\/span>14124     <\/span>56496     <\/span>52720       <\/span>448      <\/span>3328<\/font><\/span><\/p>\n

      <\/span>Total System           <\/span>243       <\/span>972       <\/span>972         <\/span>0         <\/span>0<\/font><\/span><\/p>\n

Grand Total Working Set    <\/span>17837     <\/span>71348     <\/span>54692      <\/span>8276      <\/span>8380<\/font><\/span><\/p>\n

 <\/font><\/span><\/p>\n

Module Working Set Contributions in pages<\/font><\/span><\/p>\n

    <\/span>Total   <\/span>Private Shareable    <\/span>Shared Module<\/font><\/span><\/p>\n

       <\/span>10         <\/span>4         <\/span>6         <\/span>0 devenv.exe<\/font><\/span><\/p>\n

       <\/span>75         <\/span>4         <\/span>0        <\/span>71 ntdll.dll<\/font><\/span><\/p>\n

       <\/span>64         <\/span>3         <\/span>5        <\/span>56 kernel32.dll<\/font><\/span><\/p>\n

\u2026 [more modules omitted]<\/font><\/span><\/p>\n

 <\/font><\/span><\/p>\n

       <\/span>20         <\/span>2         <\/span>0        <\/span>18 NETAPI32.dll<\/font><\/span><\/p>\n

 <\/font><\/span><\/p>\n

Heap Working Set Contributions<\/font><\/span><\/p>\n

2564 pages from Process Heap (class 0x00000000)<\/font><\/span><\/p>\n

       <\/span>0x00240000 – 0x00340000 242 pages<\/font><\/span><\/p>\n

       <\/span>0x02A80000 – 0x02B80000 153 pages<\/font><\/span><\/p>\n

       <\/span><\/span>0x02E10000 – 0x03010000 482 pages<\/span><\/font><\/p>\n

       <\/span>0x1AF10000 – 0x1B310000 911 pages<\/font><\/span><\/p>\n

       <\/span>0x207D0000 – 0x20FD0000 776 pages<\/font><\/span><\/p>\n

  <\/span><\/span>13 pages from Private Heap 0 (class 0x00001000)<\/span><\/font><\/p>\n

       <\/span>0x00350000 – 0x00360000 13 pages<\/font><\/span><\/p>\n

\u2026 [more heap data omitted]<\/font><\/span><\/p>\n

 <\/font><\/span><\/p>\n

Stack Working Set Contributions<\/font><\/span><\/p>\n

  <\/span>33 pages from stack for thread 00000DE8<\/font><\/span><\/p>\n

   <\/span>2 pages from stack for thread 0000071C<\/font><\/span><\/p>\n

   <\/span>0 pages from stack for thread 00000CEC<\/font><\/span><\/p>\n

   <\/span>1 pages from stack for thread 00000B3C<\/font><\/span><\/p>\n

\u2026 [more stack data omitted]<\/font><\/span><\/p>\n

 <\/font><\/span><\/p>\n

Usually when we investigate issues, a perfmon<\/b> log<\/b> is essential. It shows you the size of each generation in the GC heap, the number of collections done on each generation, the number of GC handles and etc. And most importantly it shows you a trend<\/i> so you know how your app behaves over a period of time which is often extremely important for discovering problems. See my <\/font>GC perf counter blog entry<\/font><\/a> for an explanation of these counters.<\/font><\/font><\/p>\n

 <\/font><\/p>\n

When people have trouble finding out what’s holding onto memory <\/font>CLRProfiler<\/font><\/a> is a great tool to help figure that out. The CLRProfiler is a visual tool that shows you a tremendous amount of info on the managed memory usage such as the types of the objects that were allocated and relocated, when GCs were triggered and how much memory is allocated by managed API calls.  <\/span>Since it comes with a great in-depth document I won\u2019t repeat stuff here.<\/font><\/font><\/p>\n

 <\/font><\/p>\n

The SoS<\/b>(Son of Strike) debugger extension is also a very useful and powerful tool. It gives you insights that are not easily found in other tools. It comes with the latest <\/font>Windows Debugger Package<\/font><\/a> (sos.dll in the clr10 directory). Michael Stanton has <\/font>a nice blog entry<\/font><\/a> about using it.<\/font><\/font><\/p>\n

 <\/font><\/p>\n

Abhi Khune has a blog entry that illustrates using some of the tools mentioned above to solve memory related problems. Please take a look at it <\/font>here<\/font><\/a>.<\/font><\/p>\n","protected":false},"excerpt":{"rendered":"

I was writing an internal wiki page on performance and thought this info is useful to many external readers as well so here it goes. vadump is a good start. It\u2019s an mstools tool \u2013 meaning you can find it on your NT CD under bin\\mstools. You can take a snapshot of the process and […]<\/p>\n","protected":false},"author":3542,"featured_media":58792,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[685],"tags":[322,3011,108],"class_list":["post-23155","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-dotnet","tag-debugging","tag-maoniposts","tag-performance"],"acf":[],"blog_post_summary":"

I was writing an internal wiki page on performance and thought this info is useful to many external readers as well so here it goes. vadump is a good start. It\u2019s an mstools tool \u2013 meaning you can find it on your NT CD under bin\\mstools. You can take a snapshot of the process and […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/23155","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/users\/3542"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/comments?post=23155"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/posts\/23155\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media\/58792"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/media?parent=23155"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/categories?post=23155"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/dotnet\/wp-json\/wp\/v2\/tags?post=23155"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}