Sometimes what looks like a memory leak when we install a 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 should not panic but collect a process memory dump to inspect it calmly 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, Volume 1, page 310). 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 Imt command shows almost 50 new .NET components.
18.190.217.139