Quantcast
Channel: Common Language Runtime Internals and Architecture forum
Viewing all articles
Browse latest Browse all 1710

Analyzing OutOfMemoryException from crashdump

$
0
0
Hello,

some users get an OutOfMemoryException after working several hours with our .NET 4.0 application. The application runs as a 32 bit process on 64 bit Windows.

I'm trying to analyze the problem using WinDBG and a crashdump provided by one of the users.

What I already have:

===

!address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
<unclassified>                        15397          6e2d1000 (   1.722 Gb)  88.18%   86.08%
Image                                  1498           ebc5000 ( 235.770 Mb)  11.79%   11.51%
Free                                    568           30cb000 (  48.793 Mb)            2.38%
TEB64                                    37             6f000 ( 444.000 kb)   0.02%    0.02%
ActivationContextData                    16             1f000 ( 124.000 kb)   0.01%    0.01%
PEB64                                     1              1000 (   4.000 kb)   0.00%    0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_MAPPED                            12781          388e7000 ( 904.902 Mb)  45.26%   44.19%
MEM_PRIVATE                            1244          2fe86000 ( 766.523 Mb)  38.34%   37.43%
MEM_IMAGE                              2847          13066000 ( 304.398 Mb)  15.23%   14.86%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT                            15892          7065d000 (   1.756 Gb)  89.96%   87.81%
MEM_RESERVE                             980           b176000 ( 177.461 Mb)   8.88%    8.67%
MEM_FREE                                645           481d000 (  72.113 Mb)            3.52%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE                        13807          587f0000 (   1.383 Gb)  70.83%   69.14%
PAGE_EXECUTE_READ                       389           f2da000 ( 242.852 Mb)  12.15%   11.86%
PAGE_READONLY                          1046           705b000 ( 112.355 Mb)   5.62%    5.49%
PAGE_EXECUTE_READWRITE                  254            cce000 (  12.805 Mb)   0.64%    0.63%
PAGE_WRITECOPY                          269            c81000 (  12.504 Mb)   0.63%    0.61%
PAGE_EXECUTE_WRITECOPY                   51            13e000 (   1.242 Mb)   0.06%    0.06%
PAGE_READWRITE|PAGE_GUARD                74             a9000 ( 676.000 kb)   0.03%    0.03%
<unknown>                                 2              2000 (   8.000 kb)   0.00%    0.00%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
<unclassified>                               2330000           2000000 (  32.000 Mb)
Image                                       70be4000            c8a000 (  12.539 Mb)
Free                                        7e9d0000            4c6000 (   4.773 Mb)
TEB64                                       7ee96000              3000 (  12.000 kb)
ActivationContextData                          50000              4000 (  16.000 kb)
PEB64                                       7efdf000              1000 (   4.000 kb)

===

The process has about 1.7 GB of committed memory, which is close to the 2 GB limit of x86 processes.
The largest free region is about 4 MB, so I guess that there was a request for a block greater than that, which could not be fulfilled.
Obviously, there seems to be some kind of memory leak.

What can I do to further analyze this using the crashdump?

Thank you.

Viewing all articles
Browse latest Browse all 1710

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>