title: How to analyze <unclassified> memory usage in windbg
body: <p>This is a .NET v4 windows service application running on a x64 machine. At some point after days of running steadily the windows service memory consumption spikes up like crazy until it crashes. I was able to catch it at 1.2 GB and capture a memory dump. Here is what i get</p>
  
  <p>If i run !address -summary in windbg on my dump file i get the follow result</p>
  
  <p>!address -summary</p>
  
  <pre><code>--- Usage Summary ------ RgnCount ------- Total Size -------- %ofBusy  %ofTotal
  Free                     821      7ff`7e834000 (   7.998 Tb)           99.98%
  &lt;unclassified&gt;           3696       0`6eece000 (   1.733 Gb)  85.67%   0.02%
  Image                    1851       0`0ea6f000 ( 234.434 Mb)  11.32%   0.00%
  Stack                    1881       0`03968000 (  57.406 Mb)  2.77%    0.00%
  TEB                      628        0`004e8000 (   4.906 Mb)  0.24%    0.00%
  NlsTables                1          0`00023000 ( 140.000 kb)  0.01%    0.00%
  ActivationContextData    3          0`00006000 (  24.000 kb)  0.00%    0.00%
  CsrSharedMemory          1          0`00005000 (  20.000 kb)  0.00%    0.00%
  PEB                      1          0`00001000 (   4.000 kb)  0.00%    0.00%
  -
  -
  -
  --- Type Summary (for busy) -- RgnCount ----- Total Size ----- %ofBusy %ofTotal
  MEM_PRIVATE                        5837 0`7115a000 (  1.767 Gb)  87.34%  0.02%
  MEM_IMAGE                          2185 0`0f131000 (241.191 Mb)  11.64%  0.00%
  MEM_MAPPED                           40 0`01531000 ( 21.191 Mb)   1.02%  0.00%
  -
  -
  --- State Summary ------------ RgnCount ------ Total Size ---- %ofBusy %ofTotal
  MEM_FREE                            821 7ff`7e834000 (  7.998 Tb)        99.98%
  MEM_COMMIT                         6127   0`4fd5e000 (  1.247 Gb) 61.66%  0.02%
  MEM_RESERVE                        1935   0`31a5e000 (794.367 Mb) 38.34%  0.01%
  -
  -
  --Protect Summary(for commit)- RgnCount ------ Total Size --- %ofBusy %ofTotal
  PAGE_READWRITE                     3412 0`3e862000 (1000.383 Mb) 48.29%   0.01%
  PAGE_EXECUTE_READ                   220 0`0b12f000 ( 177.184 Mb)  8.55%   0.00%
  PAGE_READONLY                       646 0`02fd0000 (  47.813 Mb)  2.31%   0.00%
  PAGE_WRITECOPY                      410 0`01781000 (  23.504 Mb)  1.13%   0.00%
  PAGE_READWRITE|PAGE_GUARD          1224 0`012f2000 (  18.945 Mb)  0.91%   0.00%
  PAGE_EXECUTE_READWRITE              144 0`007b9000 (   7.723 Mb)  0.37%   0.00%
  PAGE_EXECUTE_WRITECOPY               70 0`001cd000 (   1.801 Mb)  0.09%   0.00%
  PAGE_EXECUTE                          1 0`00004000 (  16.000 kb)  0.00%   0.00%
  -
  -
  --- Largest Region by Usage ----Base Address -------- Region Size ----------
  Free                            0`8fff0000        7fe`59050000 (   7.994 Tb)
  &lt;unclassified&gt;                  0`80d92000        0`0f25e000 ( 242.367 Mb)
  Image                           fe`f6255000       0`0125a000 (  18.352 Mb)
  Stack                           0`014d0000        0`000fc000 (1008.000 kb)
  TEB                             0`7ffde000        0`00002000 (   8.000 kb)
  NlsTables                       7ff`fffb0000      0`00023000 ( 140.000 kb)
  ActivationContextData           0`00030000        0`00004000 (  16.000 kb)
  CsrSharedMemory                 0`7efe0000        0`00005000 (  20.000 kb)
  PEB                             7ff`fffdd000      0`00001000 (   4.000 kb)
  </code></pre>
  
  <p>First, why would unclassified show up once as 1.73 GB and the other time as 242 MB. <em>(This has been answered. Thank you)</em></p>
  
  <p>Second, i understand that unclassified can mean managed code, however my heap size according to !eeheap is only 248 MB, which actually matches the 242 but not even close to the 1.73GB. The dump file size is 1.2 GB which is much higher than normal. Where do I go from here to find out what's using all the memory. Anything in the managed heap world is under 248 MB, but i'm using 1.2 GB. </p>
  
  <p>Thanks</p>
  
  <p><strong>EDIT</strong></p>
  
  <p>If i do !heap -s i get the following</p>
  
  <pre><code>LFH Key                   : 0x000000171fab7f20
  Termination on corruption : ENABLED
            Heap     Flags   Reserv  Commit  Virt   Free  List   UCR  Virt  Lock  Fast 
                              (k)     (k)    (k)     (k) length      blocks cont. heap 
  -------------------------------------------------------------------------------------
  Virtual block: 00000000017e0000 - 00000000017e0000 (size 0000000000000000)
  Virtual block: 0000000045bd0000 - 0000000045bd0000 (size 0000000000000000)
  Virtual block: 000000006fff0000 - 000000006fff0000 (size 0000000000000000)
  0000000000060000 00000002  113024 102028 113024  27343  1542    11    3    1c LFH
      External fragmentation  26 % (1542 free blocks)
  0000000000010000 00008000      64      4     64      1     1     1    0    0      
  0000000000480000 00001002    3136   1380   3136     20     8     3    0    0  LFH
  0000000000640000 00041002     512      8    512      3     1     1    0    0      
  0000000000800000 00001002    3136   1412   3136     15     7     3    0    0  LFH
  00000000009d0000 00001002    3136   1380   3136     19     7     3    0    0  LFH
  00000000008a0000 00041002     512     16    512      3     1     1    0    0      
  0000000000630000 00001002    7232   3628   7232     18    53     4    0    0  LFH
  0000000000da0000 00041002    1536    856   1536      1     1     2    0    0  LFH
  0000000000ef0000 00041002    1536    944   1536      4    12     2    0    0  LFH
  00000000034b0000 00001002    1536   1452   1536      6    17     2    0    0  LFH
  00000000019c0000 00001002    3136   1396   3136     16     6     3    0    0  LFH
  0000000003be0000 00001002    1536   1072   1536      5     7     2    0    3  LFH
  0000000003dc0000 00011002     512    220    512    100    60     1    0    2      
  0000000002520000 00001002     512      8    512      3     2     1    0    0      
  0000000003b60000 00001002  339712 168996 339712 151494   976   116    0   18  LFH
      External fragmentation  89 % (976 free blocks)
      Virtual address fragmentation  50 % (116 uncommited ranges)
  0000000003f20000 00001002      64      8     64      3     1     1    0      0      
  0000000003d90000 00001002      64      8     64      3     1     1    0      0      
  0000000003ee0000 00001002      64     16     64     11     1     1    0      0      
  -------------------------------------------------------------------------------------
  </code></pre>