Crash Dump Analysis Patterns (Part 216)

Sometimes what looks like a memory leak when we install the new product version is not really a leak. With the previous version we had 400 MB typical memory usage but suddenly we get twice as more. We shouldn’t panic but collect a process memory dump to calmly inspect it offline. We may see Dry Weight increase: the size of all module images. For some products the new release may mean complete redesign with a new more powerful framework or incorporation of the significant number of new 3rd-party components (Module Variety). Additional sign against the memory leak hypothesis is simultaneous memory usage increase for many product processes. Although, this may be some shared module with leaking code. For example, in the example below 50% of all committed memory was image memory:

0:000> !address -summary

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
[...]
Image                                  1806        0`19031000 ( 402.535 Mb)   4.29%    0.00%
Heap                                     72        0`02865000 (  40.395 Mb)   0.44%    0.00%
[…]

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
[...]
MEM_IMAGE                              2281        0`19AA8000 ( 413.000 Mb)   4.40%    0.00%
[…]

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
[...]
MEM_COMMIT                             2477        0`326e8000 ( 806.906 Mb)   8.76%    0.00%
[…]

WinDbg lmt command shows almost 50 new .NET components.

- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -

Leave a Reply

You must be logged in to post a comment.