none
Analyzing OutOfMemoryException from crashdump RRS feed

  • Question

  • 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.
    Thursday, October 2, 2014 9:08 AM

Answers

  • Please check with VMMap if your large memory mapped files come from 64 KB blocks. If yes then your Bitmaps are allocating too much address space due to a bug in Windows. I have reported this to MS and I have got them to fix Win 7 - 8 for this issue:

    http://geekswithblogs.net/akraus1/archive/2014/01/03/155056.aspx

    Yours,

       Alois Kraus

    Sunday, October 5, 2014 7:42 AM

All replies