System Memory Report (Compact 2013)
3/26/2014
The DevHealth system memory report provides a summary of the amount of RAM and non-volatile storage on the device and shows which consumers are using the physical RAM at the time that you run the DevHealth tool. There are three sections in the system memory report: a total storage section and two physical RAM sections:
- Total Storage: Provides the total number of pages of non-volatile storage space and the number of available and used pages of non-volatile storage space.
- Physical RAM (sources breakdown): Lists the sources of RAM that are on the device. This section always includes a Main Memory section, and may include one or more Extension DRAM sections.
- Physical RAM (consumers breakdown): Shows how the entire physical RAM of the device is being used at the moment of the report. This part of the report breaks the memory down into different sections such as program memory, object store, paging pool, Watson size, and so on. Within the Program Memory section, there is a summary for each type of page that is allocated, such as code, stack, heap, data, and so on.
The address ranges for the various sections of RAM correspond to the actual physical addresses that each virtual address range maps to. In this way, this report can account for the entire physical RAM on the device at any time.
In the system memory report, Unaccounted/Unknown indicates that there is a difference between the number of physical pages that are accounted for and the number of physical pages that are available. That is, there are some pages for which the usage is unknown. This is different from unknown in the system memory map report. In the system memory map report, unknown means that DevHealth found pages in use but cannot report their purpose. In the system memory report, unknown means that there are some pages that DevHealth did not even find.
One possible source of memory listed as Unaccounted/Unknown is by processes that have exited. If a process exits, but a program still has a handle to that process, the memory of the process is not freed, but the process will not show up in DevHealth report. As a result, a large amount of unknown memory could indicate a leak of process handles.
An example of a system memory report is shown in the following table.
.png "DevHealth System Memory Report")