I am trying to work out some memory leak issues in an application, and I am really hoping someone here can offer me some insights that will help. I’ve been tinkering with this all day and I am afraid I’m completely stuck.
The application I am troubleshooting works fine initially, but will become sluggish and perhaps even crash if it is used after sitting idle for a couple hours. I assume this is due to some sort of memory leak that is getting worse over time. As far as I know, there are no internal processes, such as Timers or endless loops, etc., that can account for the memory leak, but the symptoms are reproducible, so something is definitely going on.
In order to try to work this out, I downloaded and installed a trial version of .NET Memory Profiler. Unfortunately, though, I’m not really sure how to interpret the results I’m getting. As far as I can tell, the classes that seem to me to be the most problematic are system classes, such as System.Version and System.Object[]. I am thinking this based on an assumption that the “data to look for” is the number of unreachable instances and bytes reported by the profiler.
Here is some sample data, similar to what I’ve been seeing:
- Namespace: System
- Class Name: Version
- Live Instances…
- Total: 2
- Delta: 0
- Live Bytes…
- Total: 48
- New: 48
- Max: 24
- Delta: 0
- Unreachable…
- Instances: 15,556
- Bytes: 373,344
- Namespace: System
- Class Name: Object[]
- Live Instances…
- Total: 1,198
- Delta: 0
- Live Bytes…
- Total: 117,916
- New: 117,916
- Max: 7,016
- Delta: 0
- Unreachable…
- Instances: 3,054
- Bytes: 204,592
If I am reading this right, the two largest problems I am facing is that I have over 15,000 instances of assembly versions and over 3,000 objects that are “unreachable,” though admittedly I’m not exactly sure what is meant by “unreachable.”
So, my specific questions are these:
- Can anyone tell me if I’m reading the .Net Memory Profiler data correctly?
- If I am reading the data correctly, what could cause my application to generate more assembly version instances and more object instances while no end user is interacting with it?
There’s no real evidence of any kind of leak from what you’ve posted. The garbage collector hasn’t run for a while, that’s normal on an idle program. The 0.5 MB those uncollected objects take is peanuts.
What will happen when a program is idle for a while is that its virtual memory pages will get swapped out to the paging file. When it regains the focus, those pages need to be swapped back in. When the machine is old, that can take a while. Your real problem is more than likely disk fragmentation, especially on the paging file.
You should be able to tell from the hard disk drive access light, it ought to be furiously blinking. You can also tell from TaskMgr.exe, Process tab. View + Select Columns, tick Page Fault Delta. That number should go to zero in a second or less after restoring the program’s window.
Defrag your disk. Especially the paging file, which is hard to do. Ask questions about that at superuser.com