I have talked about a bunch of commands used to troubleshoot a managed memory problem in the past and given some situations of using them like:
There is another way that we could see a problem that involves fragmentation. Let’s consider the situation where we see the same situation we saw before, namely:
But we do see a bunch of files listed when we look in lm. So what should this tell us about the problem? Well, first off, since the files are showing up in lm, we know the problem isn’t the same as, Dynamic Assemblies and what to do about them. So next we would want to look and see specifically what the files are.
The first common problem that you will see is caused by either have debug=true, or batch=false is set. Batch is similar to debug, set in the same place and will tell the compiler to not create one DLL for the entire directory but rather create one DLL for each file we compile. Underneath, debug=true sets batch=false, so they do the same thing in this regard. If that is the problem, you will see a bunch of strangely named DLLs in the lm list. Names like:
Turning debug off, or batch on will resolve the problem in this situation.
The second common problem that will cause this is if you have a common framework that you are using in multiple applications. One common way to do this is the copy the framework files into the bin directory of each application. This will cause us to create a different in-memory file for each one. So instead of just having 5 files that make up your framework loaded in memory, you will have 5 * (# of AppDomains) loaded.
You can identify this problem because in the list of files, you will see the same filename repeated, only some will have some numbers after them:
This is just showing the different versions of the file by showing you the other copies with their base address (load address).
The easiest solution to this type of problem is to place the framework files into the GAC. Then you will only have one copy of the files which all the Applications will share.